Le protocole SecRoute est un protocole de routage hiérarchique sécurisé. Le réseau est organisé en clusters ayant chacun un chef. Le noeud collecteur est supposé connaître cette organisation du réseau, et doit maintenir localement une table contenant une clé secrète de chaque capteur. Cette clé est supposée pré-chargée dans chaque noeud. De plus, chaque cluster doit posséder une clé permettant de sécuriser les échanges intra-cluster. Cette clé doit être connue par le cluster-head et tous les noeuds du groupe. Le protocole SecRoute ne spécifie pas l'algorithme de construction de clusters, et suppose que les clusters ainsi que leurs clés sont établis par un autre protocole, comme LEAP.
Le protocole possède les propriétés suivantes:
Les paquets de routage ne sont pas volumineux, car ils ne contiennent qu'une information partielle sur le chemin parcouru.
Le protocole utilise une architecture à deux niveaux, dans laquelle les chefs agrègent les données des membres puis les transmettent au noeud collecteur.
Le protocole emploie seulement des méthodes de chiffrement symétrique.
Pour des raisons de sécurité, le protocole remplace les unicasts par des broadcasts locaux ciblés. En effet, en évitant les unicasts, un message émis est reçu par tous les voisins. Donc, cela permet de vérifier, lors du relais, l'intégrité du message émis par le prochain saut.
Chaque capteur stocke une table de routage ayant le format suivant :
La table est organisée suivant l'adresse des sources. Le champ Pre (respectivement Next) indique les deux prochains sauts vers la SB (respectivement source) sur le chemin entre la source et la SB.
Le noeud source initie une découverte des chemins en émettant vers ses voisins directs un paquet de requête RREQ contenant les informations suivantes:
IDsource|IDsink|IDRREQ|Nsource MAC(Ksource, IDsource|IDsink|IDRREQ|Nsource) avec :
IDsource, IDsink, IDRREQ: les identificateurs de la source, du collecteur et de la requête.
Nsource : un nonce généré par la source.
Lorsqu'un noeud reçoit une requête, elle n'est acceptée qu'avec l'unicité de son identificateur IDREQQ. Il met à jour par la suite sa table de routage en utilisant l'information des deux sauts précédents vers la source. Avant de relayer la requête, le noeud remplace les valeurs de IDpre et IDthis par, respectivement, IDthis et son identificateur :
IDthis|IDpre|IDsource|IDsink|IDRREQ|Nsource MAC (Ksource, IDsource|IDsink|IDRREQ|Nsource)
Lorsque le collecteur reçoit la première requête, il vérifie le MAC construit par la source en utilisant la clé relative à son identificateur IDsource, sauvegardée dans la table locale. Si le MAC est correct, le collecteur met à jour sa table de routage en utilisant les champs IDpre et IDthis. Il génère ensuite une réponse RREP ayant le format suivant :
IDpre|IDthis|IDnext|IDsink|IDRREQ|Nsink MAC (Ksource, IDsource|IDsink|IDRREQ|Nsink)
La requête est émise en broadast local, ciblé à l'aide du champs IDnext. Lorsque le capteur voisin ayant l'identificateur IDnext reçoit cette réponse, il met à jour sa table de routage en conséquence, puis remplace les champs IDpre et IDthis par IDthis et son identificateur. Il doit aussi modifier le champ IDnext par l'identificateur connus lors de la phase de découverte de chemins. Si le noeud ne reçoit pas la réponse émise par IDnext après un certain temps, il ignore toutes les requêtes émises pendant la prochaine phase de découverte. Le noeud de relais doit aussi vérifier que la réponse émise par le prochain saut est valide, en s'assurant qu'elle est bien destinée au noeud à deux sauts contenu dans le chemin vers la source (i.e. le champ IDpre2 de la table de routage). Lorsque la source reçoit la première réponse, elle vérifie le MAC généré par le collecteur et met à jour sa table de routage en ajoutant IDthis et IDpre comme prochains sauts vers le collecteur.
Le relais des données est effectué en deux étapes. Les noeuds membres émettent leurs données vers le chef du groupe, qui va par la suite envoyer le résumé vers le collecteur. L'établissement du chemin entre le chef et le collecteur s'effectue grâce au procédé décrit précédemment, i.e. : le chef représente la source de son groupe. Pour les communications intra-groupe, le protocole utilise la clé de cluster CK établie lors de sa création. Chaque donnée D d'un capteur est émise vers le clusterhead ID, encapsulée comme suit :
ID|{D}CK|MAC(CK, ID|{D}CK)
Le chef agrège les données des membres après vérification des MAC de chaque paquet, puis émet le résumé vers le collecteur. Pour cela, le chef opère comme étant la source de la donnée. Si aucune route vers le collecteur n'est connue, le procédé de découverte de chemins doit être effectué. En utilisant le chemin construit, le chef émet la donnée dans le paquet suivant :
IDthis|IDnext|IDsource|IDsink|QID|{D}Ksource MAC (Ksource, IDsource|IDsink|QID|{D}Ksource)
Un noeud intermédiaire avec le même identificateur que IDnext relaie le paquet en remplaçant IDthis et IDnext. Si un noeud de relais ne reçoit pas le paquet émis par le prochain saut, une maintenance de la route doit être effectuée. Pour cela, il doit émettre vers la source un message d'erreur permettant d'enclencher à nouveau la procédure de découverte de routes. De plus, le prochain saut est ajouté à la liste noire (black list). Cette liste contient les identificateurs dont le noeud doit ignorer leurs paquets de réponse. Lorsque le paquet atteint le collecteur, il vérifie le MAC en utilisant la clé de la source et peut donc décrypter la donnée et l'utiliser.