The security of Ariadne relies on the secrecy and authenticity of keys stored in nodes. Ariadne relies on the following keys to be set up, depending on which authentication mechanism is used:
To set up shared secret keys, we can use a variety of mechanisms: a key distribution center shares a secret key with each node and sets up shared secret keys with communicating nodes, such as in Kerberos [33] or SPINS [45]; bootstrap shared secret keys from a Public Key Infrastructure (PKI) using protocols such as TLS [14]; or pre-load shared secret keys at initialization, possibly through physical contact [52]. Menezes et aldiscuss several key setup protocols [38]. To set up authentic public keys, we can either embed all public keys at initialization in each node, or assume a PKI and embed the trusted Certification Authority's public key in each node and then use that key to authenticate the public keys of other nodes. Another approach proposed by Hubaux et al [23] bootstraps trust relationships based on PGP-like certificates. Ariadne also requires that each node have an authentic element from the Route Discovery chain (Section 6.6) of every node initiating Route Discoveries. These keys can be set up in the same way as a public key. Key setup is an expensive operation. Setting up shared secret keys requires authenticity and confidentiality, whereas setting up public keys only requires authenticity. Furthermore, fewer public keys are generally needed, because in a network with n nodes only n public keys are needed, and can potentially be broadcast, whereas n(n+1)/2 secret keys need to be set up in the case of pairwise shared secret keys. We outline here a mechanism to set up these keys without relying on Ariadne, thus avoiding the circular dependency between key setup and a routing protocol. We assume for this a trusted Key Distribution Center (KDC) that either shares a secret key with each node, or uses its private or TESLA key to broadcast authenticated public keys of nodes. In either case, a star-based routing protocol that allows routing between nodes and the trusted entity suffices. To bootstrap authenticated keys between pairs of nodes, the KDC node initiates a Route Discovery with a special, reserved address (not the address of any actual node) as the target of the Discovery. The Route Discovery is processed as in Ariadne (Section 6), except that each node receiving the ROUTE REQUEST for the first time also returns a ROUTE REPLY. The KDC can then use each returned route to send encrypted, authenticated keys to each node in the network.
To set up authentic public keys, we can either embed all public keys at initialization in each node, or assume a PKI and embed the trusted Certification Authority's public key in each node and then use that key to authenticate the public keys of other nodes. Another approach proposed by Hubaux et al [23] bootstraps trust relationships based on PGP-like certificates.
Ariadne also requires that each node have an authentic element from the Route Discovery chain (Section 6.6) of every node initiating Route Discoveries. These keys can be set up in the same way as a public key.
Key setup is an expensive operation. Setting up shared secret keys requires authenticity and confidentiality, whereas setting up public keys only requires authenticity. Furthermore, fewer public keys are generally needed, because in a network with n nodes only n public keys are needed, and can potentially be broadcast, whereas n(n+1)/2 secret keys need to be set up in the case of pairwise shared secret keys.
We outline here a mechanism to set up these keys without relying on Ariadne, thus avoiding the circular dependency between key setup and a routing protocol. We assume for this a trusted Key Distribution Center (KDC) that either shares a secret key with each node, or uses its private or TESLA key to broadcast authenticated public keys of nodes. In either case, a star-based routing protocol that allows routing between nodes and the trusted entity suffices. To bootstrap authenticated keys between pairs of nodes, the KDC node initiates a Route Discovery with a special, reserved address (not the address of any actual node) as the target of the Discovery. The Route Discovery is processed as in Ariadne (Section 6), except that each node receiving the ROUTE REQUEST for the first time also returns a ROUTE REPLY. The KDC can then use each returned route to send encrypted, authenticated keys to each node in the network.
