1. January 15th
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Security protocol for Body area networks]
Date Submitted: [The date the document is contributed, in the format “21 May, 1999”]
Source: [Magnet Consortium] Company [Nokia]
Address []
Voice:[], FAX: [],
Re: [If this is a proposed revision, cite the original document.]
[If this is a response to a Call for Contributions, cite the name and date of the Call for Contributions to which this document responds, as well as the relevant item number in the Call for Contributions.]
[Note: Contributions that are not responsive to this section of the template, and contributions which do
not address the topic under which they are submitted, may be refused or consigned to the “General Contributions” area.]
Abstract: [security architecture for BAN devices. keying protocol for low power devices. Identity based on crypto signature. Encryption algorithms]
Purpose: [potential solution for body area network security.]
Notice: This document has been prepared to assist the IEEE P It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P
NOTE: Update all red fields replacing with your information; they are required. This is a manual update in appropriate
fields. All Blue fields are informational and are to be deleted. Black stays. After updating delete this box/paragraph.
<author>, <company>

2. A Security Protocol for BAN
January 15th
A Security Protocol for BAN
H. Afifi, S. Mirzadeh, F. Amretcht, K. Masmoudi
<author>, <company>

3. Security procedures in this presentation
January 15th
Security procedures in this presentation
Keying
Unique identity
Group management
Encryption
<author>, <company>

4. January 15th
Requirements
A security architecture that can be implemented on lightweight devices
A security architecture that is strong enough to protect individuals
The architecture respects all the known security requirements (confidentiality, integrity, PFS, etc…)
<author>, <company>

5. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
January 15th
Keying Assumptions
The initiation of security is based on imprinting
The user is in full control of the imprinting procedure, i.e. the user determines when and how a new device will be imprinted.
Imprinting uses a proximity channel and
We use a specific node that plays the role of initiation node.
<author>, <company>
<author>, <company>

6. January 15th
Imprinting
<author>, <company>

7. A channel that ensures a set of security properties
January 15th
The proximity channel
A channel that ensures a set of security properties
We have two kinds of channels
Public : not totally secure
Private : completely secure %M
<author>, <company>

8. Two options First option: Diffie Helman on the proximity channel
January 15th
Two options
First option:
Diffie Helman on the proximity channel
Enter PINs (variable length that depends on the hardware) on master and device
Derive a permanent bilateral key
Derive a session key that can be refreshed periodically
Use the session key for encryption
<author>, <company>

9. First option continued
January 15th
First option continued
We use transitive imprinting to extend to other nodes
Resulting key
<author>, <company>

10. January 15th
Second option
Use elliptic curves to send a master node key to all the BAN
The BAN devices can be revocated easily
No need to transitive imprinting
The BAN nodes communicate together as they share the public master node key
<author>, <company>

11. Unique crypto-based ID
January 15th
Unique crypto-based ID
Simply hash the nodes public key and the master node to have hierarchical crypto based ID.
An id is truncated to the required BAN size (memory/CPU constrains)
<author>, <company>

12. Group management January 15th BAN2 BAN1
<author>, <company>

13. Group management A simple algorithm sends access control tokens
January 15th
Group management
A simple algorithm sends access control tokens
We assure forward and backward security
Revocation works also on group keys
<author>, <company>

14. Encryption Any lightweight acceptable algorithm can be used
January 15th
Encryption
Any lightweight acceptable algorithm can be used
AES starts to be deployable on RFiDs
We can select also an alternative stream cypher algorithm
<author>, <company>

15. January 15th
Complexity
Diffie Helman takes on a Crossbow a few seconds to calculate the keys
Elliptic Curves should take almost same time and they reduce the key size
S. Fouladgar et al. A Trust Delegation Protocol For Wireless Sensor Networks
Third European Workshop on Security and Privacy in Ad hoc and Sensor Networks
<author>, <company>

16. January 15th
Conclusion
The Keying protocol is comparable to all the rest of keying algorithms but it is newer…
Crypto Identity is a way to solve the problem of addressing/identity
Additional group keys can provide very flexible dynamic group communications
<author>, <company>