Internet DRAFT - draft-huang-routing-security
draft-huang-routing-security
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
Abstract
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.
Requirements Language
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].
Status of this Memo
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 Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Huang Expires February 26, 2012 [Page 1]
Internet-Draft SRSPk August 2011
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Complete Service . . . . . . . . . . . . . . . . . . . . . 4
3.1. Public/Private Key Pre-distribution . . . . . . . . . . . . 4
3.2. Initial Session Key Establishment . . . . . . . . . . . . . 4
3.3. Session Key Update . . . . . . . . . . . . . . . . . . . . 5
3.4. Data Encryption Service . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Communication Overhead Considerations . . . . . . . . . . . . . 6
6. Storage Overhead Considerations . . . . . . . . . . . . . . . . 7
7. Connectivity Considerations . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Huang Expires February 26, 2012 [Page 2]
Internet-Draft SRSPk August 2011
1. Introduction
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.
2. Design Goals
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.
Huang Expires February 26, 2012 [Page 3]
Internet-Draft SRSPk August 2011
3. The Complete Service
3.1. Public/Private Key Pre-distribution
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.
3.2. Initial Session Key Establishment
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
Huang Expires February 26, 2012 [Page 4]
Internet-Draft SRSPk August 2011
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.
3.3. Session Key Update
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.
3.4. Data Encryption Service
After the session key is established between any of two devices, they
can exchange secret messages each other. The delivery information is
as follow:
Huang Expires February 26, 2012 [Page 5]
Internet-Draft SRSPk August 2011
(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.
4. Security Considerations
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.
5. Communication Overhead Considerations
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
Huang Expires February 26, 2012 [Page 6]
Internet-Draft SRSPk August 2011
each other without digital signature.
6. Storage Overhead Considerations
In this profile, each device is required very low cost, so the
storage capability of each device MUST be severely limited.
7. Connectivity Considerations
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.
8. References
8.1. Normative References
[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.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[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.
Huang Expires February 26, 2012 [Page 7]
Internet-Draft SRSPk August 2011
8.2. Informative References
[IEEE802.15.4]
"Telecommunications and Information Exchange between
Systems -- Local and Metropolitan Area Networks - Specific
requirements Part 15.4: Wireless Medium Access Control
(MAC) and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks (WPANS)", 2006.
Author's Address
Jie Huang
Southeast University
No.2, Si Pailou, School of Information Science and Engineering
Nan Jing, Jiang Su Province 210096
RPC China
Phone: +86 25 83795822-803
Email: jhuang@seu.edu.cn
Huang Expires February 26, 2012 [Page 8]
