Full paper: Postscript, PS.GZ, PDF

SNEP: Data Confidentiality, Authentication, Integrity, and Freshness

 

SNEPprovides a number of unique advantages. First, it has low communication overhead since it only adds $8$ bytes per message. Second, like many cryptographic protocols it uses a counter, but we avoid transmitting the counter value by keeping state at both end points. Third, SNEPachieves even semantic security, a strong security property which prevents eavesdroppers from inferring the message content from the encrypted message. Finally, the same simple and efficient protocol also gives us data authentication, replay protection, and weak message freshness.

Data confidentiality is one of the most basic security primitives and it is used in almost every security protocol. A simple form of confidentiality can be achieved through encryption, but pure encryption is not sufficient. Another important security property is semantic security, which ensures that an eavesdropper has no information about the plaintext, even if it sees multiple encryptions of the same plaintext [12]. For example, even if an attacker has an encryption of a $0$ bit and an encryption of a $1$ bit, it will not help it distinguish whether a new encryption is an encryption of $0$ or $1$. The basic technique to achieve this is randomization: Before encrypting the message with a chaining encryption function (i.e. DES-CBC), the sender precedes the message with a random bit string. This prevents the attacker from inferring the plaintext of encrypted messages if it knows plaintext-ciphertext pairs encrypted with the same key.

However, sending the randomized data over the RF channel requires more energy. So we construct another cryptographic mechanism that achieves semantic security with no additional transmission overhead. Instead, we rely on a shared counter between the sender and the receiver for the block cipher in counter mode (CTR) (as we discuss in Section 6). Since the communicating parties share the counter and increment it after each block, the counter does not need to be sent with the message. To achieve two-party authentication and data integrity, we use a message authentication code (MAC).

The combination of these mechanisms form our Sensor Network Encryption Protocol SNEP. The encrypted data has the following format: $E\; =\; \{D\}$ K_encr,C , where $D$ is the data, the encryption key is $K$_encr, and the counter is $C$. The MAC is $M\; =\; MAC(K$_mac, C | E ). We derive the keys $K$_encr and $K$_mac from the master secret key $K$ as we show in Section 6. The complete message that $A$ sends to $B$ is:

SNEPoffers the following nice properties:

• Semantic security: Since the counter value is incremented after each message, the same message is encrypted differently each time. The counter value is long enough that it never repeats within the lifetime of the node.
• Data authentication: If the MAC verifies correctly, a receiver can be assured that the message originated from the claimed sender.
• Replay protection: The counter value in the MAC prevents replaying old messages. Note that if the counter were not present in the MAC, an adversary could easily replay messages.
• Weak freshness: If the message verified correctly, a receiver knows that the message must have been sent after the previous message it received correctly (that had a lower counter value). This enforces a message ordering and yields weak freshness.
• Low communication overhead: The counter state is kept at each end point and does not need to be sent in each message.

Plain SNEPprovides weak data freshness only, because it only enforces a sending order on the messages within node $B$, but no absolute assurance to node $A$ that a message was created by $B$ in response to an event in node $A$.

Node $A$ achieves strong data freshness for a response from node $B$ through a nonce $N$_A (which is a random number sufficiently long such that it is unpredictable). Node $A$ generates $N$_A randomly and sends it along with a request message $R$_A to node $B$. The simplest way to achieve strong freshness is for $B$ to return the nonce with the response message $R$_B in an authenticated protocol. However, instead of returning the nonce to the sender, we can optimize the process by using the nonce implicitly in the MAC computation. The entire SNEPprotocol providing strong freshness for $B$'s response is:

If the MAC verifies correctly, node $A$ knows that node $B$ generated the response after it sent the request. The first message can also use plain SNEP if confidentiality and data authentication are needed.