## 7 ECC-based Key Agreement Protocol
### Key Agreement Protocol  
In our scheme, each base station has a private key \(q\) and a public key \(Q=qG\), where \(G\) is a chosen base point on the elliptic curve. The public key \(Q\) is pre-configured in the motes. As mentioned before, motes do not have their own public/private keys. To securely derive symmetric keys between a mote and a base station (called _session keys_), we use the following protocol involving three messages (Figure 6). Figure 5: The elliptic curve integrated encryption scheme (ECIES). When a more is first attached to a patient, the patient uses the biometric scanner on the more to activate the key agreement protocol. For illustration, we assume that a fingerprint reader is used to obtain a biometric signature, but other types of biometric information would also work. Once the more obtains the patient's fingerprint (\(FP\)), which includes a set of features extracted from the raw fingerprint image, it generates a master key \(K_{m}\) that will be used to derive the session keys for end-to-end query/data encryption. It also generates a session number \(SN\) that uniquely identifies this particular communication session, and a nonce \(n_{1}\) for deriving the session keys. The note then sends a _KeyGenStart_ message _securely_ to the base station using ECIES. This message contains the more's ID (\(NID\)), the patient's \(FP\), the master key \(K_{m}\), the session number \(SN\), and the nonce \(n_{1}\). Appended to _KeyGenStart_ is the unencrypted point \(R\) needed for ECIES. The base station decrypts _KeyGenStart_ and verifies the authenticity of this patient using the fingerprint. Then the base station generates a nonce \(n_{2}\), and it uses \(K_{m}\), \(n_{1}\), and \(n_{2}\) to derive the session keys that will be shared with the more -- the symmetric encryption key \(K_{s}\) and the MAC key \(K_{mac}\) for data/query transfer. The nonces \(n_{1}\) and \(n_{2}\) not only allow frequent update of the session keys, but also protect the protocol from replay attacks. Note that our protocol is also secure against man-in-the-middle attacks because the attacker would need the base station's private key and the patient's \(FP\) to launch such an attack. After processing the _KeyGenStart_ message, the base station sends back a _KeyGenAck_ message to the more containing \(SN\), \(n_{2}\), and a one-way hash of \(n_{1}\), encrypted and integrity-protected using the transient keys derived from ECIES. We opt to use a hash of \(n_{1}\) rather than \(n_{1}\) directly to reduce the information that an attacker will have even if the attacker is able to decrypt this message. The more decrypts _KeyGenAck_ and verifies \(SN\) and the hash of \(n_{1}\) to prevent replay attacks. Afterwards, the note uses \(K_{m}\), \(n_{1}\), and \(n_{2}\) to derive the session keys \(K_{s}\) and \(K_{mac}\), which should match those generated by the base station. For the base station to verify that the more has received the _KeyGenAck_ message and that the more generated the session keys \(K_{s}\) and \(K_{mac}\) correctly, the more sends a _KeyGenVerify_ message to the base station containing \(SN\) and a hash of \(n_{2}\). This message is encrypted with  
Figure 6: ECC-based key agreement protocol. \(K_{s}\) and integrity-protected with \(K_{mac}\). The base station decrypts _KeyGenVerify_ and verifies that all the values are correct. If so, data transfer may commence using \(K_{s}\) to encrypt/decrypt messages and \(K_{mac}\) to compute a keyed MAC for each message.