rpsec Working Group | J. Huang |
Internet-Draft | Southeast University |
Intended status: Informational | August 25, 2011 |
Expires: February 26, 2012 |
Security Routing Service based on Public Key for Low-Power Wireless Networks
draft-huang-routing-security-00
This memo specifies a security protocol based on public key matrix for Internet of Things. All public keys MUST be generated by only one public key seed and the corresponding private key MUST be secret information for adversary. Each node can indirectly authenticate the identity of other nodes without digital signature. This protocol is REQUESTED Public/Private Key Pre-distribution service, Initial Session Key Establishment service, Session Key Update service and Data Encryption Service.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 26, 2012.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Low-power wireless networks are composed of a large number of tiny, low cost devices that conform to the IEEE 802.15.4 standard by the IEEE [IEEE802.15.4] . These devices are characterized by short range, low bit rate, low power. Their computational capabilities, memory and energy will be limited. In RFC 3775, RFC 4919 and RFC 5673, IPv6 routing protocol is perceived as a key technology to provide the scalability and interoperability[RFC3775] [RFC4919][RFC5673], but the protocol need to consume much more energy during exchanging data between devices. Therefore it shortens the lifetime of the low-power networks. The AODV routing protocol is intended to use for mobile devices in an ad hoc network [RFC3561], but it does not consider the low-power of mobile device and security.
This profile is intended to provide a range of functional capabilities for security routing of low-power wireless networks. The most complete services should use the public/private key and symmetric key to distribute session keys among all devices, and then use session keys encrypt exchanged messages among devices. The basic mechanism may be used when all public/private keys are offline generated and assigned to each device at an administrative entity. The main goals of this profile are outlined below:
(1) Network resilience. It refers to the capability against physical capture, that is, low-power wireless networks cannot be compromised by physical attack, or the compromised devices cannot compromise other non-captured devices. This memo provides a method for the latter.
(2) Scalability. Low-power wireless networks are dynamic networks. This profile can support adding fresh devices to extend the network size and evicting compromised devices without significant overheads.
(3) Low resource consumption. This protocol will cost extra memory and computational capability. When a security scheme is designed, low memory overhead, and computational complexity are required.
(4) Low energy consumption. The energy computation for the security mechanism of low-power networks MUST be kept to a minimum. In this network, the largest energy consumer is radio transmission. Therefore, this protocol requires the communication overhead between devices MUST be minimum as possible as it can.
All public/private keys are offline generated and offline assigned to each devices at an enclosed entity. The entity can randomly generate a public key seed and a pair-wise public/private key for itself at first. And then the public seed is used to construct an initial public key set by one-way hash function. The first public key is generated by the public seed, and next public key is generated by the last public key. Next, the entity computes all public key used in the low-power wireless networks by one-way hash function and the initial public key set to construct a public key matrix, that is, every element of the initial public key set can generate a row of elements of the public key matrix. Then the entity computes the corresponding private keys of the public key matrix.
Last, the entity offline randomly distributes different elements from the public/private matrix to differently devices. In this phase, it is unnecessary for entity to use its private key to sign public keys of the devices in this protocol, which has two following reasons: (a) the procedure above is offline executed at an enclosed entity and the entity is security. An intruder cannot compromise this secret information; (b) all public keys are generated by a public key seed and all private keys are unable to be derived from these public keys and cryptographic algorithm.
The pairwise public/private key is used to verify the identity of the devices in the low-power wireless networks. In order to protect the confidentiality of transmitted data between devices, session keys are established and different communication links uses different session keys. Each device only establishes a session key with its one-hop-neighbor. The session key establishment procedure is describes below:
(1) A sender device first chooses symmetric key. And then it broadcasts its identity number to its one-hop-neighbors.
(2) Its one-hop-neighbor receives the device’s identity. It first estimates the position of the sender device’s public key in the public key matrix and then computers the public key of the device. After that, it sends a decrypted message by the public key of the sender device, not only including its identity number and one symmetric key to the device.
(3) The sender device decrypts and receives the symmetric key. After that, it computes the session key between the two devices by XOR two symmetric keys. Then, sends a encrypted message by receiver device’s public key, not only including a symmetric key.
(4) The receiver device decrypts and receives the symmetric key. Then it computes the session key between two devices by XOR two symmetric keys.
Each device establishes a unique secure communication link with its one-hop-neighbors and any of two devices are able to authenticate their identities each other without digital signature. The protocol is secure against a man-in-the-middle attack. Suppose that two devices wish to establish a secure communication link. Although an intruder can intercept and tamper the exchanged message between two devices, it cannot generate a correctly private key belonging to the public key matrix. Therefore, the intruder is not able to compute the correctly session key between the two devices.
If a new device is added in the low-power wireless networks, the procedures of the session key establishment between the new device and its one-hop-neighbor is similar to that of the session key establishment.
The session key is a provisional key in this protocol, and therefore, the key must be periodically updated. A new session key is established by the previous session key. In other words, each device sends a message authentication code (MAC) using the previous session key to the other device. The session key update produce is described as follow:
(1) When a sender device wants to establish a new session key with a receiver device, the former computes MAC by their session key, not only including its identity number. And then it sends the MAC to the receiver device.
(2) The receiver device verifies the integrality of the message. If the verification is right, the two devices update session key. Otherwise, the receivers reject the message and send the request message again.
After the session key is established between any of two devices, they can exchange secret messages each other. The delivery information is as follow:
(1) If sender device wants to transmit an encrypted message to a receiver device. The sender computes the encrypted message of plaintext by their session key and generates a message authentication code.
(2) The receiver device verifies the integrity and freshness of the encrypted message. If the verification is right, the receiver will receive the message. Otherwise, the receivers reject the message. At last, receiver decrypts the message to receive the plaintext.
In this protocol, the security performance MUST be analysized, but the likelihood of non-captured devices compromised by captured ones is only considered. In the public/private key pre-distribution service, the enclosed entity generates the public/private matrix and offline assigns them to all devices in the low-power wireless networks. And in session key establishment service, the sender device verifies the identity of the receiver device without digital signature, since private keys are unable to be derived from these public keys and cryptographic algorithm. An intruder node can be verified through disguising as valid device. The communication link between the intruder and its valid neighbors can be established. But the captured node cannot compromise other non-captured sensors and their communication links because different communication links has different pairwise public/private keys. In data encryption service, transmitted data confidentiality and devices’ identity are ensured by a shared session key between two devices. In order to prevent the shared session key from attack, it MUST be periodically updated in session key update service. This profile provides the message integrity by encrypted message and MAC.
In the low-power wireless networks, the largest energy consumer is the radio transmission that consumes much more energies than other process in devices. But in order to improve network security, the communication overhead between devices must increase. Therefore, the strength of security mechanism is REQUIRED a tradeoff with its communication overhead. RFC 4944 describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses [RFC4944]. However, the packet head length is too long to transmit in the low-power wireless networks.
In this profile, each device establishes a shared session keys with its one-hop neighbors and all devices can verify their identities each other without digital signature.
In this profile, each device is required very low cost, so the storage capability of each device MUST be severely limited.
In this profile, network connectivity is one of significant problems. If any of two devices can share a session key, the low-power wireless networks can implement perfect connectivity. If the low-power wireless networks cannot realize perfectly network connectivity, this profile MUST assure that the network connected probability exceeds 0.99999.
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
[RFC3561] | Perkins, C., Belding-Royer, E. and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. |
[RFC4919] | Kushalnagar, N., Montenegro, G. and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, August 2007. |
[RFC4944] | Montenegro, G., Kushalnagar, N., Hui, J. and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. |
[RFC5673] | Pister, K., Thubert, P., Dwars, S. and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. |