1. May 16, 2018
doc.: IEEE r0
May, 2002
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [MAC Distributed Security Proposal]
Date Submitted: [9 May, 2002]
Source: [René Struik] Company [Certicom Corp.]
Address [5520 Explorer Drive, 4th Floor, Mississauga, ON Canada L4W 5L1]
Voice:[+1 (905) ], FAX: [+1 (905) ],
Re: []
Abstract: [This document describes elements of the security architectural framework for the Wireless Personal Area Network (WPAN), based on the characteristics of this network and its intended operational usage.]
Purpose: [Highlight issues that need to be addressed to flexibly facilitate WPAN 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
Rene Struik, Certicom Corp.
Rene Struik, Certicom Corp.

2. MAC Distributed Security Proposal for IEEE 802.15.4 Low-Rate WPANs
May, 2002
MAC Distributed Security Proposal for IEEE Low-Rate WPANs
Gregg Rasor, Motorola
René Struik, Certicom Research
Scott Vanstone, Certicom Research
Rene Struik, Certicom Corp.

3. Security Architecture Cryptographic Building Blocks MAC Commands
May 16, 2018
doc.: IEEE r0
May, 2002
Outline
Security Concepts
PANs and Clusters
Scalable Security
Security Policy
Security Architecture
Cryptographic Building Blocks
MAC Commands
Performance Issues
Implementation Issues
Rene Struik, Certicom Corp.
Rene Struik, Certicom Corp.

4. Security Concepts – A Short Introduction
May, 2002
Security Concepts – A Short Introduction
Rene Struik, Certicom Corp.

5. Basic Security Services
May 16, 2018
doc.: IEEE r0
May, 2002
Basic Security Services
Authenticity
Evidence as to the true source of information or the true identity of entities:
- Message authentication.
Evidence regarding the true source of information:
(1) No undetectable modifications, deletions, and injections of messages by external parties (data integrity);
(2) No confusion about who originated the message (source authenticity).
- Entity authentication.
Evidence regarding the true identity of entities and on their active involvement:
(1) No confusion about whom an entity is really communicating with (authenticity);
(2) Proof that entity is actively participating in communications (i.e., is ‘alive’).
Secrecy
Prevention of external parties from learning the contents of information
exchanges:
(1) Logical separation of information between parties that may have access to info
and those that do not.
(2) No confusion about whom those privileged parties are (authenticity).
Rene Struik, Certicom Corp.
Rene Struik, Certicom Corp.

6. Cryptographic Building Blocks - Authentication (1)
May 16, 2018
doc.: IEEE r0
May, 2002
Cryptographic Building Blocks - Authentication (1)
Message authentication
Evidence regarding the true source of information:
(1) No undetectable modifications, deletions, and injections of messages by external parties (data integrity);
(2) No confusion about who originated the message (source authenticity).
Realizations:
- Keyed hash function (or Message Authentication Code (MAC)).
Mapping of arbitrary messages (of any length) to compact representative image
hereof, using a secret key.
(1) Data integrity, since difficult to find distinct messages with same MAC value.
(2) Source authentication, since only parties that share the secret key can produce
MAC-value (assuming there is no confusion about who has access to this key).
- Un-keyed hash function.
hereof (digital fingerprint, or message digest), without secret key.
(1) Data integrity, since difficult to find distinct messages with same hash value.
(2) Source authentication, only if message digest is communicated authentically.
Rene Struik, Certicom Corp.
Rene Struik, Certicom Corp.

7. Cryptographic Building Blocks - Authentication (2)
May 16, 2018
doc.: IEEE r0
May, 2002
Cryptographic Building Blocks - Authentication (2)
Entity authentication
Evidence regarding the true identity of entities and on their active involvement:
(1) No confusion about whom an entity is really communicating with (authenticity);
(2) Proof that entity is actively participating in communications (i.e., is ‘alive’).
Realizations:
- Entity authentication protocol (challenge response protocol).
(1) Source authentication, since only parties that share the secret key can produce
proper responses to unpredictable challenges (assuming there is no confusion
about who has access to this key).
(2) Aliveness, since challenge messages are unpredictable and never repeated.
(Hence, replaying previously recorded protocol messages does not leak info.)
Rene Struik, Certicom Corp.
Rene Struik, Certicom Corp.

8. Cryptographic Building Blocks - Secrecy
May 16, 2018
doc.: IEEE r0
May, 2002
Cryptographic Building Blocks - Secrecy
Secrecy
Prevention of external parties from learning the contents of information
exchanges:
(1) Logical separation of messages between parties that may have access to info
and those that do not.
(2) No confusion about who those privileged parties are (authenticity).
Realizations:
- Symmetric key algorithm.
(1) Logical separation of information, since only parties that share the secret key can learn the contents hereof (assuming there is no confusion about who has access to this key).
- Public key algorithm.
(1) Logical separation of information, since only parties that share the private decryption key can learn the content of encrypted messages (assuming there is no confusion about who has access to this private key).
{Note: this is always the case if public key set-up is arranged properly.}
Rene Struik, Certicom Corp.
Rene Struik, Certicom Corp.

9. Cryptographic building blocks – Authenticity and Secrecy (1)
May 16, 2018
doc.: IEEE r0
May, 2002
Cryptographic building blocks – Authenticity and Secrecy (1)
Symmetric-key cryptography
Security services based on exchange of secret and authentic keys:
(1) Logical separation of messages, by exchanging secret keys between privileged parties only;
(2) Authenticity of privileged parties by checking credentials of each party, by
non-cryptographic means (certified mail, courier, face-to-face, etc.)
Public-key cryptography
Security services based on exchange of authentic public keys:
(1) Logical separation of messages, by restricting access to each private key to the privileged party only (in practice, there is only 1 privileged entity);
(2) Authenticity of privileged parties, by checking credentials of each party by
non-cryptographic means and (if successful) by subsequently binding the public key to this party (certification of public keys).
Certification is done by a so-called Trusted Third Party, who vouches for the
authenticity of the binding between an entity and its public key.
Rene Struik, Certicom Corp.
Rene Struik, Certicom Corp.

10. Cryptographic building blocks – Authenticity and Secrecy (2)
May 16, 2018
doc.: IEEE r0
May, 2002
Cryptographic building blocks – Authenticity and Secrecy (2)
Public-key cryptography (cont’d)
Certification of public keys depends on appropriately checking the credentials
of a party and constitutes the following:
Check, by cryptographic means, that the entity A that claims to have access to the public key PA, has access to the corresponding private key SA;
Check, by non-cryptographic means, the claimed identity IdA of A.
Certification is done by a so-called trusted third party:
- Digital certificates (cryptographic binding).
Authenticity of binding, via signature over the pair (IdA,PA) by trusted party;
Verification of authenticity of public keys by any party, by verifying signature of trusted party in the digital certificate (assuming the authentic storage of trusted party’s signature verification string on each verifying device);
Unrestricted transfer of certificates possible (hence, off-line certification possible).
- Manual ‘certificates’(non-cryptographic, e.g. pre-installed or via user interface).
No cryptographic verification of the authenticity of public keys possible.
No transfer of certificates possible (hence, on-line ‘certification’ only).
Rene Struik, Certicom Corp.
Rene Struik, Certicom Corp.

11. A Distributed Security Architecture
May, 2002
A Distributed Security Architecture
for
IEEE Low-Rate WPANs
Rene Struik, Certicom Corp.

12. Outline IEEE 802.15.4 WPAN Technology
May 16, 2018
doc.: IEEE r0
May, 2002
Outline
IEEE WPAN Technology
IEEE WPAN Security Objectives
Modes of Operation of the Piconet
Devices and their Roles
Security Policy
Access Control to the Piconet
The Need for a Distributed Security Model
Protection of Messages
Mutual Authenticated Key Agreement Protocol
Mutual Symmetric Entity Authentication Protocol
Combined Key Agreement and Entity Authentication Protocol
ECC-Based Public Key Cryptography
The WPAN at Work
Inter-Piconet Communications
Operational Description of the WPAN
Rene Struik, Certicom Corp.
Rene Struik, Certicom Corp.

13. IEEE 802.15.4 WPAN Technology Communication technology
May 16, 2018
doc.: IEEE r0
May, 2002
IEEE WPAN Technology
Communication technology
Radio transmissions at unlicensed 2.4 GHz frequency band (10 channels), but also at European
868MHz (1 ISDN channel) and US 915MHz (10 ISDN channels) frequency band;
- Low data rates: 20kbps, 40kbps, 250 kbps;
Hearing range: roughly 10 meters between static and moving devices;
Very low power, very low cost, very low complexity devices;
Beacon and beacon-less communication.
Devices
- Home networking; - Interactive toys;
- Automotive networks; - Industrial networks;
Remote metering.
Personal Area Networks (networks)
- Star networks and peer-to-peer networks (including cluster networks);
- Communication patterns include peer-to-peer and broadcast;
Full Function Devices (FFDs), Reduced Function Devices (RFDs);
Network coordinators and cluster heads;
Clusters allow more wide-ranged communications, via routing.
Interaction with outside world
via node that communicates MAC service data units back and forth.
Rene Struik, Certicom Corp.
Rene Struik, Certicom Corp.

14. (Potential) IEEE 802.15.4 WPAN Security Objectives
May, 2002
(Potential) IEEE WPAN Security Objectives
Access control to the PAN.
Restriction of access to scarce network resources to authorized devices only, to
ensure objectives including the following:
- proper bandwidth allocation;
- protection of radio-related commands;
- power drain savings.
Control of access to message traffic between PAN devices.
Restriction of access to information secured between members of a group of PAN
devices to precisely these group members. This includes any of the following
objectives:
- Confidentiality.
Prevent external parties from learning the content of exchanged messages.
- Data integrity.
Prevent external parties from modifying or injecting messages in undetected way.
Rene Struik, Certicom Corp.

15. Security Framework for Low-Rate WPANs (1)
May, 2002
Security Framework for Low-Rate WPANs (1)
Level 1: Low Security
No cryptography
No cost
Access controlled by device IDs
Examples: kid’s games, entertainment systems (e.g., remote controls)
Level 2: Medium Security
Symmetric-key cryptography (includes encryption/authentication)
Low cost
Access controlled by shared secret key(s)
Examples: telephones, light switches, heating/air conditioning systems
Level 3: High Security
Public-key cryptography for authentication
Symmetric-key cryptography for encryption and data integrity
Higher cost
Access controlled by public-key infrastructure
Examples: industrial applications, home security, safety-critical systems
Rene Struik, Certicom Corp.

16. Security Framework for Low-Rate WPANs (2) - Alternative Formulation
May, 2002
Security Framework for Low-Rate WPANs (2)
- Alternative Formulation
Level 1: Low Security
- Non-cryptographic access control, only via Access Control Lists;
- No data protection.
Level 2: Medium Security
- Cryptographic access control, via symmetric-key techniques;
- Data protection via shared symmetric keys;
- No cryptographic update mechanism for long-term symmetric keys
(keys pre-established or established via user interface).
Level 3: High Security
- Cryptographic access control, via public key techniques;
- Cryptographic update mechanism for long-term symmetric keys
(seamless, flexible updates of symmetric keys via public-key methods).
Rene Struik, Certicom Corp.

17. Level 1: Low Security Many applications need only low security
May, 2002
Level 1: Low Security
Play games
Send pictures to your printer
Control entertainment system
Many applications need only low security
Devices are added to a network by simple means:
Placing a device in a cradle (e.g., a cordless phone)
Pressing a button while devices are in close proximity or contact
A controller device (e.g., a PDA controls which devices are in a network)
Devices that are not recognized are not allowed access
Rene Struik, Certicom Corp.

18. Level 2: Medium Security
May, 2002
Level 2: Medium Security
Thermostat control
Cordless phones
Light switches
All devices in a (sub)network share the same key
Symmetric-key cryptography prevents access by unauthorized devices
Simple symmetric algorithms provide message integrity and encryption
Devices are added to a network by installing the shared key
Rene Struik, Certicom Corp.

19. Industrial Application
May, 2002
Level 3: High Security
Industrial Application
Home Security
Safety Critical
Public and symmetric-key cryptography
Each device has a unique, secure, private key and certificate that it can use to prove its identity
Each device has a root key it can use to authenticate other devices
A centralized authority/device may be used to control configuration
Distribute private keys/certificates
Establish trust relationships
Rene Struik, Certicom Corp.

20. Devices and their Roles (1)
May, 2002
Devices and their Roles (1)
Role model
Security Manager. Sole source of local trust management.
-Facilitates establishment of symmetric keying material between ordinary devices;
-Facilitates maintenance of keying relationships;
-Enforces security policy.
Ordinary device. Part of PAN or could become part hereof.
- Responsible for secure processing and storage of keying material;
- Responsible for maintenance of its own Access Control List (ACL).
Coordinator. Potential source of local message control (in PAN/Cluster).
-Facilitates admission of ordinary devices to the PAN;
-Allocates time slots for message exchanges between devices;
-No security responsibilities (apart from access control to the PAN/Cluster).
External trusted party. Sole source of global trust management.
-Facilitates establishment of public keying material between ordinary devices;
-Facilitates maintenance of public keying relationships;
For discussion’s sake, we assume that the PAN coordinator and Cluster Heads
always perform access control to the PAN, resp. to the Cluster.
(not implemented if not needed)
Rene Struik, Certicom Corp.

21. Devices and their Roles (2)
May, 2002
Devices and their Roles (2)
Mapping of roles to devices
Devices need way to recognize which role(s) other devices play or should play.
- Static mapping. Mapping may be defined at initialization.
Dynamic mapping. Mapping must be realized by securely associating roles to
devices, allowing dynamic verification (e.g., via attribute certificates).
‘Permanent’ mappings of roles to devices
The following mapping of roles to devices are always in effect:
Each device assumes the role of ordinary device (for all devices);
The PAN coordinator device assumes the role of coordinator (for all PAN devices);
The Cluster Heads may assume the role of coordinator (for all cluster devices);
Each full function device may assume the role of (alternate) coordinator;
Each device may assume the role of security manager (for any subset of
devices that include itself).
Rene Struik, Certicom Corp.

22. Devices and their Roles (3)
May, 2002
Devices and their Roles (3)
The role of the external trusted party includes facilitating the generation of authentic public keying material for each device. As such, it includes
- (facilitating) the generation of a public/private key pair for each device, if needed;
- generation of certificates for each device’s public key;
- (facilitating) the storage of an authentic copy of the trusted party’s own public key signature verification key in each device, prior to its operational deployment.
There is (conceptually) only 1 entity that assumes the role of external trusted party (for all devices).
(If there is actually more than 1 external trusted party, each device is assumed to have access to the other external trusted party’s ‘root’ key, either directly or via cross-certification techniques.)
The role of the external trusted party is implemented outside the network (CA functionality).
Rene Struik, Certicom Corp.

23. Devices and their Roles (4)
May, 2002
Devices and their Roles (4)
Actual mapping of roles to devices
The actual mapping of the Coordinator and Security Manager role to a device might change over time.
EXAMPLES
I. Centralized security model (master/slave model)
There is 1 single device that assumes the role of Security Manager (for all devices).
II. Distributed security model (Our proposed mapping of roles to devices)
Each device assumes the role of Security Manager (for itself only).
Note (Hybrid Security Model)
If desired, one can ‘relax’ this mapping by postulating that each device assumes the role of Security Manager for himself and for all other devices that trust him (‘friendship’ scenario).
A detailed discussion of properties to follow later.
Rene Struik, Certicom Corp.

24. May, 2002
Security Policy (1)
The security policy specifies rules that must be adhered to to keep security properties of system
invariant, in the event of security events.
Discussions are relative to a specific set of PAN devices (group).
Security events
1. Change of group structure.
(a) Exclusion of an old group member from the group:
- Expiration of group membership. Disassociation due to time-out.
- Cancellation of group membership. Disassociation due to cancellation request.
- Denial of access. Disassociation due to enforcement of security policy.
(b) Introduction of a new group member to the group:
- Subscription of the member. Authentication of newly associated device.
2. Change of (security relevant) role.
(a) Hand over of coordinator;
(b) Changes to list of devices that are trusted as Security Manager for specific device;
Simultaneous changes to the group structure and to the security relevant role are conceptually
thought of as to occur subsequently (in any order).
Rene Struik, Certicom Corp.

25. May, 2002
Security Policy (2)
I. Effect of security events - change of group structure
Scenario where information shared between group members is secured via a
common (symmetric) group key.
Security invariant
At any given moment of time, access to information shared between members of a group is
restricted to precisely these group members. As such, this includes access to integrity
information.
Security rule
Changes to the group structure shall invoke a change to the common group keys.
Rationale
This prevents a new group member from gaining access to secured information
communicated prior to the moment he obtained access to the key-sharing group.
2. This prevents an old group member from gaining access to secured information
communicated after the moment he was denied access to the key-sharing group.
Rene Struik, Certicom Corp.

26. May, 2002
Security Policy (3)
I. Effect of security events - change of group structure (cont’d)
Key storage invariant
At any given moment of time, devices maintain symmetric keying relationships with groups to
which they belong only.
Key storage rule
Changes to the group structure shall invoke the secure destruction of the old group key(s) and
the secure and authentic storage of the new group key(s).
Rationale
This limits the impact of the potential compromise of symmetric keying material to exposure of
information to which the device already has access as a legitimate group member.
Rene Struik, Certicom Corp.

27. May, 2002
Security Policy (4)
II. Effect of security events - change of security relevant role
Scenario where information shared between group members is secured via a common
(symmetric) group key.
Changes between a group member’s role as coordinator and as ordinary device have no
impact on the group structure, hence these do not impact the group key(s).
Changes to the list of devices that are trusted to assume the Security Manager role of the device have no impact on the group structure, hence these do not impact the group key(s).
Note: exclusion of a security manager from a device’s list of trusted security managers
does have an impact on key usage, as follows:
Key usage rule
(a) If a device excludes a security manager (i.e., does not trust it any more), it stops
using any keying material that originated or will originate from this security
manager, for encryption purposes (use for decryption purposes may still occur, though).
(b) If a device includes a security manager (i.e., it trusts it as key distribution source),
it starts using any keying material that will originate from this security manager
from that instance in time onwards, both for encryption and decryption purposes.
Rene Struik, Certicom Corp.

28. Access Control to a PAN/Cluster (1)
May, 2002
Access Control to a PAN/Cluster (1)
The access control policy specifies how devices shall communicate in a piconet.
Discussions are relative to a particular PAN/Cluster and do assume this (sub)network to
operate in one of its secure modes.
I. Admission to a PAN/Cluster
Admission to a PAN/Cluster is based on the outcome of the following protocols between the
prospective joining device and the Coordinator/Cluster Head (in order):
1. Mutual entity authentication protocol.
The device and the Coordinator/Cluster Head engage in a mutual entity authentication
protocol based on public-key or symmetric-key techniques. This protocol provides evidence
regarding the true device identity of both the joining device and the Coordinator/Cluster
Head, based on authentic public or symmetric keys.
2. (optional) Authorization techniques between both devices, based on, e.g.,
Access Control Lists (ACLs).
If devices have been positively authenticated and have been authorized, these are admitted to the
PAN/Cluster. Addressing of these devices may take place using their local Id (of 8 bits), rather
than their global Id (IEEE MAC Address of 64 bits). For this an unused local Id is assigned to the
joining device.
Rene Struik, Certicom Corp.

29. Access Control to a PAN/Cluster (2)
May, 2002
Access Control to a PAN/Cluster (2)
Remark
Devices in the piconet fully depend on information provided by the Coordinator/Cluster
Head regarding which devices have been admitted to the piconet (since admission is
based on communication between the Coordinator/Cluster Head and a joining device only).
Corollary (Effect of improper device list in broadcast scenario)
Assume the following scenario:
All devices in the PAN/Cluster share a common broadcast key;
The list of admitted devices to this network is
L:={(local 8-bit device Id, global 64-bit device Id)}.
Then failure to obtain the complete and authentic list of admitted devices has the
following consequences:
‘Fly on the wall’ problem.
‘Switchboard’ problem.
Remark (generalization of threat scenario)
This property also holds in other settings where a key-generating party does not
share complete and authentic information on the composition of the key-sharing group
itself with the other members of this group.
Rene Struik, Certicom Corp.

30. Access Control to a PAN/Cluster (2a)
May, 2002
Access Control to a PAN/Cluster (2a)
Corollary (Effect of improper device list in broadcast scenario)
Assume the following scenario:
All devices in the piconet share a common broadcast key;
The list of admitted devices to the piconet is L:={(local 8-bit device Id, global 64-bit device Id)}.
Then failure to obtain the complete and authentic list of admitted devices has the following consequences:
‘Fly on the wall’ problem.
If a device obtains an incomplete list L’  L (L’ L) of admitted devices, all devices in the
complementary set L\ L’ are ‘invisible’ to the device. Hence, the device might mistakenly think to share
secured information only with devices from the list L’, whereas actually it is with other devices of the
set L as well, and unknowingly so. This obviously violates sound security practice.
Coordinator list
Intended behavior: to A, Coordinator
Actual behavior: to A, B, Coordinator
Global Id Local Id
A 0x x01
B 0x x02
C 0x x03
C’s local list
0 1 3
Coord A
C B
3 2 C
C wants to
broadcast info
based on
his local
address book
Rene Struik, Certicom Corp.

31. Access Control to a PAN/Cluster (2b)
May, 2002
Access Control to a PAN/Cluster (2b)
Corollary (Effect of improper device list in broadcast scenario)
Assume the following scenario:
All devices in the piconet share a common broadcast key;
The list of admitted devices to the piconet is L:={(local 8-bit device Id, global 64-bit device Id)}.
Then failure to obtain the complete and authentic list of admitted devices has the following consequences:
‘Switchboard problem’.
If the binding between the local device Id and the global device Id is incorrectly received (e.g., 2 entries
are interchanged) a device might direct information to the improper device and so compromise the
intended security.
Global Id Local Id
A 0x x01
B 0x x02
C 0x x03
Coordinator list
A 0x x02
B 0x x01
C’s local list
0 1
3 2
PNC A
C B
Intended behavior: to A
Actual behavior: to B
C wants to
send info to
A, based on
his local
address book
Rene Struik, Certicom Corp.

32. Access Control to a PAN/Cluster (3)
May, 2002
Access Control to a PAN/Cluster (3)
Consequences (Effect of improper device lists on security policy)
According to the security policy,
“changes to the group structure shall invoke a change to the common group keys.”
This rule can only be enforced if each device takes one of the following two stands:
Completely rely on the PAN Coordinator/Cluster Head and on all key generating devices for
key-sharing groups to which he belongs, to provide up-to-date and authentic information on the
current group composition. This requires a complete dependency on the key generating devices
and on the Coordinator/Cluster Head.
Maintain up-to-date and authentic information on ‘aliveness’ of devices with whom the device
shares keying material himself. This requires no reliance on the key generating devices, nor on
the Coordinator/Cluster Head. It does, however, require regular re-authentication of all
key-sharing devices (the so-called ‘heartbeat’ scenario, where two devices verify each other’s
‘aliveness’).
Solution
Since complete trust in a PAN Coordinator/Cluster Head is not realistic in all usage scenarios,
this threat can only be diverted properly as follows:
Each device generates its own keys for its intended audience;
Each device regularly performs a ‘heartbeat’ function, to obtain semi-continuous authentication
information.
Rene Struik, Certicom Corp.

33. The Need for a Distributed Security Model
May, 2002
The Need for a Distributed Security Model
A centralized security model is completely unacceptable from a security perspective, except for the most
simple usage scenarios (fixed star network).
I. Centralized security model (Master/Slave model)
The Security Manager role is identified with one single device for all devices, hence one has the following:
Concentration of all trust in 1 device:
- each device must trust the same Security Manager;
- each device must trust each subsequent Security Manager (in case the security manager moves).
Change of Security Manager:
- potentially expensive re-establishment of keying relationship between devices and the Security
Manager.
At any given moment in time, the PAN Coordinator/Cluster Head must provide each PAN device with
complete and authentic information on the current composition of the PAN/Cluster membership (in reality:
at regular time intervals).
II. Distributed security model (Our proposed mapping of roles to devices)
The Security Manager role is identified with each individual device, hence one has the following:
No reliance on other devices for trust functionality:
- each device need only trust himself as Security Manager.
Change of Security Manager does not have a major impact on individual keying relationships (‘smoothness’).
At any given moment in time, each device must re-authenticate with each of its key sharing parties, to obtain
‘aliveness’ guarantees (in reality: at regular time intervals).
Rene Struik, Certicom Corp.

34. Cryptographic Primitives for the distributed security architecture
May, 2002
Cryptographic Primitives
for
the distributed security architecture
IEEE Low-Rate WPANs
Rene Struik, Certicom Corp.

35. Protection of Messages (1)
May, 2002
Protection of Messages (1)
Unsecured transport:
Initial set-up: none
Message: A  B: msg
Security services: none
Secure transport:
Initial set-up: Establishment of shared data encryption key key between A and B
Message: A  B: Encryptkey (msg)
Security services: Secure transfer of message msg
Authentic transport:
Initial set-up: Establishment of shared data integrity key key between A and B
Message: A  B: msg, hashkey (msg)
Security services: Authentic transfer of message msg
Secure and authentic transport:
Initial set-up: Establishment of shared encryption key key1 between A and B
Establishment of shared data integrity key key2 between A and B
Message: A  B: msg1 || Encryptkey1 (msg2 || hashkey2 (msg1 || msg2))
Security services: Authentic transfer of messages msg1 and msg2
Secure transfer of message msg2
Encryptkey: encryption function
hashkey: keyed hash function
Rene Struik, Certicom Corp.

36. Protection of Messages (2)
May, 2002
Protection of Messages (2)
Assumptions on capabilities:
Sender A should be able to encrypt messages and to compute keyed hash functions hereover.
Recipient B should be able to decrypt messages and to verify keyed hash values.
Header info can be bound to message to be authenticated if needed, e.g.,
Algorithm Ids: specifies the particular cryptographic primitives used;
Key Ids: prevents use of improper data keys;
Sequence No.: prevents undetected reordering (or replay) of message frames;
Message length: prevents misalignment in decryption and verification process.
Rene Struik, Certicom Corp.

37. Mutual Public-Key Authenticated Key Agreement Protocol (1)
May, 2002
Mutual Public-Key Authenticated Key Agreement Protocol (1)
Initial Set-up
Publication of system parameters of public key systems A and B
Publication of keyed hash function hk
Distribution of authentic public keys PA and PB
Constraints
RNDA and RNDB random
SA and SB private to Party A, resp. Party B
Public keys PA and PB valid and authentic during execution of protocol
Security Services (see 2a)
Key agreement on the shared key K
Mutual entity authentication of A and B
Mutual explicit key authentication (if hk is secure)
Known-key resilience
Perfect forward secrecy
No key control by either party A B
authentic channel PB PA
secret and authentic channel A B
KAB
Rene Struik, Certicom Corp.

38. Mutual Public-Key Authenticated Key Agreement Protocol (2)
May, 2002
Mutual Public-Key Authenticated Key Agreement Protocol (2)
X, CertT(IdA ,WA)
hashB,,Y, CertT(IdB PB)
(1) generate random number x
(2) compute ‘exponent’ X = x P
K= f(GA,RNDB, WA,SB)=sA sB P
= f(RNDA,GB, SA, WB)=sB sA P
Public key party A: WA= wAP
Public key party B: WB= wBP
(1) generate random number y
(2) compute ‘exponent’ Y = y P
(4) compute hash over the string
(Y || X || IdA)
using keyed hash function hK with key key2, to
yield string hashB
(3) compute key K= sAsB P and (key1|| key2)=kdf(K)
(3a) Verify the authenticity of (WA, , IdA) binding
hashA
(1) compute key K=sBsA P and (key1|| key2)=kdf(K)
(2) compute hash over the string (Y || X || IdA)
yield string hashverifyB
(3) verify whether hashB=hashverifyB
(3a) Verify the authenticity of (WB , IdB) binding
( X|| Y|| IdB)
yield string hashA
(1) compute hash over the string (X || Y ||IdB)
yield string hashverifyA
(2) verify whether hashA=hashverifyA
LOCAL ADDRESSING DELETED
Rene Struik, Certicom Corp.

39. Mutual Symmetric-Key Authenticated Key Agreement Protocol (1)
May, 2002
Mutual Symmetric-Key Authenticated Key Agreement Protocol (1)
Initial Set-up
Publication of keyed hash function hk
Establishment of shared symmetric key KAB between A and B
Constraints
RNDA and RNDB random
KAB secret to Party A, resp. Party B
Security Services (see 2a)
Key agreement on the shared key k
Mutual entity authentication of A and B
Mutual explicit key authentication A B
KAB
secret and authentic channel A B k
secret and authentic channel
Rene Struik, Certicom Corp.

40. Mutual Symmetric-Key Authenticated Key Agreement Protocol (2)
May, 2002
Mutual Symmetric-Key Authenticated Key Agreement Protocol (2) X
hashB,,Y
(1)
(2) generate random ‘exponent’ X
(2) Generate random ‘exponent’ Y
(4) compute hash over the string
(Y || X || IdA)
using keyed hash function hK with key k, to
yield string hashB
(3) Compute shared key k=hK (X ||Y) with key K
hashA
(1) Compute shared key k=hK (X ||Y) with key K
(2) compute hash over the string (Y || X || IdA)
yield string hashverifyB
(3) verify whether hashB=hashverifyB
( X|| Y|| IdB)
yield string hashA
(1) compute hash over the string (X || Y ||IdB)
yield string hashverifyA
(2) verify whether hashA=hashverifyA
LOCAL ADDRESSING DELETED
Rene Struik, Certicom Corp.

41. Mutual Symmetric-Key Entity Authentication Protocol (1)
May, 2002
Mutual Symmetric-Key Entity Authentication Protocol (1)
Initial Set-up
Publication of keyed hash function hk
Establishment of shared symmetric key KAB between A and B
Constraints
RNDA and RNDB random
KAB secret to Party A, resp. Party B
Security Services (see 2a)
Mutual entity authentication of A and B A B
KAB
secret and authentic channel
authentic channel A B
IdB
IdA
Rene Struik, Certicom Corp.

42. Mutual Symmetric-Key Entity Authentication Protocol (2)
May, 2002
Mutual Symmetric-Key Entity Authentication Protocol (2)
(1)
(2) generate random ‘exponent’ GA GA
(1)
(2) generate random ‘exponent’ GB
(4) compute hash over the string
(GB ||GA ||IdA)
using keyed hash function hK with key K, to
yield string hashB
(3) [retrieve shared key K]
LOCAL ADDRESSING DELETED
hashB,,GB
(1) [retrieve shared key K]
(2) compute hash over the string (GB||GA ||IdA)
using keyed hash function hK with key K, to
yield string hashverifyB
(3) verify whether hashB=hashverifyB
(4) compute hash over the string
(GA||GB ||IdB)
yield string hashA
(1) compute hash over the string (GA ||GB ||IdB)
using keyed hash function hK with key K, to
yield string hashverifyA
(2) verify whether hashA=hashverifyA
hashA
Rene Struik, Certicom Corp.

43. Combined Key Agreement and Entity Authentication Protocol
May, 2002
Combined Key Agreement and Entity Authentication Protocol
Implementation issues
Efficient implementation possible (for public key system)
No usage constraints
Channel should be simplex channel both ways
Flexibility
No restrictions between cryptographic building blocks (in particular, good fit for ECC)
Full scalability (PKI-like)
Survivability, since no status information maintained
Alternative uses using same implementation (!)
Mutual Public Key Authenticated Key Agreement Protocol
Unilateral Public Key Authenticated Key Agreement Protocol
One-Pass Public Key Authenticated Key Agreement Protocol (in DL Scenario)
Mutual Symmetric-Key Authenticated Key Agreement Protocol
Unilateral Symmetric-Key Authenticated Key Agreement Protocol
One-Pass Symmetric-Key Authenticated Key Agreement Protocol (in DL Scenario)
Mutual Symmetric Key Entity Authentication Protocol
Unilateral Symmetric Key Entity Authentication Protocol
Example (uses of protocols in WPAN setting)
Authenticated association: Mutual Public Key Authenticated Key Agreement Protocol
‘Heartbeat’ functionality: Unilateral or Mutual Symmetric Key Entity Authentication Protocol
Rene Struik, Certicom Corp.

44. Operational Description - Informational Elements (1)
May, 2002
Operational Description - Informational Elements (1)
Informational elements (provided by device itself)
(1) Global device Ids.
Each device has own static global device Id (64-bit IEEE MAC address).
(2) Public keys (in high security level).
Each device has its own public/private key pair (PA, SA).
{The public key PA need not to be stored on the device itself.}
(3) TrustSets (in medium/high security level).
Each device has own set of devices it trusts to assume the role of security manager.
(4) Access control lists (ACLs) (in each security level)
Each device has own set of devices it may establish a secure peer-to-peer link with.
Informational elements (provided by other devices)
Each device may have access to static global device Ids (64-bit IEEE MAC Address) of other devices.
(2) Public keys (in high security level)
Each device may have access to public keys of other devices.
Rene Struik, Certicom Corp.

45. Operational Description - Informational Elements (2)
May, 2002
Operational Description - Informational Elements (2)
Informational elements (provided by PAN/Cluster in which device partakes)
(1) Local device Ids.
Each device has dynamic local device Id (8-bit local piconet address); assigned by piconet
(controller), upon admittance to piconet.
(2) PAN/Cluster Id.
Each device has access to a piconet Id (16-bit random PNID); assigned by PAN/Cluster
(controller).
(3) PAN/Cluster DeviceList.
Each device has set of admitted devices to the PAN/Cluster (obtained from PAN
Coordinator/Cluster Head).
DeviceList:={(local 8-bit device Id, global 64-bit device Id)}.
Informational elements (provided by trusted party of device)
(1) Public key certificates (in high security level)
Each device may have access to certificates, provided by a trusted third party T:
(a) Digital certificates.
Certificate CertT(IdB, PB), together with signature verification key PT.
{Two choices: ordinary certificate, implicit certificate.}
(b) Manual certificates.
Certificate UserT(IdB, PB), together with info on way binding was established.
{pushing button, pre-installed, etc.}.
Rene Struik, Certicom Corp.

46. The 802.15.4 WPAN at Work (1) DeviceList :={A,B,C,D,E,F,G,H}
May, 2002
The WPAN at Work (1)
DeviceList :={A,B,C,D,E,F,G,H}
TrustSet(A):={A,B,C}
Groups in which A participates:
A B C D E F G H
Group1’ x x x Key source: C encryption/decryption
Group2’ x x Key Source: D decryption
Fig 1. Group structures as seen by A
Key Usage Rules:
(1) A accepts all keys transferred to him by others, for decryption purposes:
(2) A only accepts keys transferred to him by devices DEV  TrustSet(A), for encryption purposes
Consequences:
A uses Group1’ group key for encryption/decryption; Group2’ group key for decryption only.
If A wants to communicate to Group2’ members, he should generate a new group key and
distribute these to the members of Group2’: {ED(key) || Ekey(msg)}
Group x x x Key source: C encryption/decryption
Group x x $ Key Source: D decryption
Group x x Key source: A encryption/decryption
Fig 2. Group structures, as actually realized
Rene Struik, Certicom Corp.

47. The 802.15.4 WPAN at Work (2) DeviceList :={A,B,C,D,E,F,G,H}
May, 2002
The WPAN at Work (2)
DeviceList :={A,B,C,D,E,F,G,H}
TrustSet(A):=Universe (since A is an altruistic device) {Centralized model}
TrustSet(D):={D} (since D is an egocentric device) {Decentralized model}
Groups in which A participates:
A B C D E F G H A D
Group1’ x x x Key source: C encryption/decryption
Group2’ x x x Key Source: G encryption/decryption decrypt
Group3’ x x Key Source: E decrypt
Fig 1. Group structures as seen by A and D
Consequences:
A uses all group keys for encryption/decryption (since A is an altruistic device)
D uses group keys for decryption purposes only (since B did not generate these himself)
Group x x x Key source: C encryption/decryption
Group x x $ x Key Source: G wrong view of group! does not matter
Group3’ x x Key Source: E does not matter
Fig 2. Group structures, as actually realized
$: hidden node (‘fly on the wall’)
Rene Struik, Certicom Corp.

48. The 802.15.4 WPAN at Work (3) Distributed Security Model
May, 2002
The WPAN at Work (3)
Distributed Security Model
(1) Admission to the PAN/Cluster.
PAN Coordinator/Cluster Head regulates access of device to the network, based on
- proper device Id;
- other info (e.g., from access control list).
(2) Access to actual information.
Security manager regulates access of group of devices to information, based on
User scenario (Starbucks):
1. Admission to the piconet based on charging airtime/bandwidth fee (similar to that for cell phones).
2. Admission to information based on charging for content:
a. Fixed PAN Coordinator/Cluster Head in ceiling:
- multicast to subscribing devices only;
- logical separation of content in different subscription packages.
b. Devices to devices:
- up to local devices.
Note: separation of the role of PAN Coordinator/Cluster Head and that of security manager allows
charging models that differentiate between airtime/bandwidth cost & content/subscription cost.
These charging models might be operated by different entities.
Similar: piconet in fitness club, movie theatre, casino
Rene Struik, Certicom Corp.

49. The 802.15.4 WPAN at Work (4) A Router 1 B Router 2 Router n May, 2002
Relay channel
(high bandwidth pipe)
clusters
Relay
network
(high bandwidth
pipe)
router
The WPAN at Work (4)
Rene Struik, Certicom Corp.

50. May, 2002
Efficiency
Considerations
Rene Struik, Certicom Corp.

51. Mutual Public Key Authenticated Key Agreement Protocol (1)
May, 2002
Mutual Public Key Authenticated Key Agreement Protocol (1)
(1) generate random number x
(2) compute ‘exponent’ X = x P
X, CertT(IdA ,WA)
(1) generate random number y
(2) compute ‘exponent’ Y = y P
(4) compute hash over the string
(Y || X || IdA)
using keyed hash function hK with key key2, to
yield string hashB
(3) compute key K= sAsB P and (key1|| key2)=kdf(K)
(3a) Verify the authenticity of (WA, , IdA) binding
LOCAL ADDRESSING DELETED
hashB,,Y, CertT(IdB PB)
(1) compute key K=sBsA P and (key1|| key2)=kdf(K)
(2) compute hash over the string (Y || X || IdA)
using keyed hash function hK with key key2, to
yield string hashverifyB
(3) verify whether hashB=hashverifyB
(3a) Verify the authenticity of (WB , IdB) binding
(4) compute hash over the string
( X|| Y|| IdB)
yield string hashA
K= f(GA,RNDB, WA,SB)=sA sB P
= f(RNDA,GB, SA, WB)=sB sA P
Public key party A: WA= wAP
Public key party B: WB= wBP
(1) compute hash over the string (X || Y ||IdB)
using keyed hash function hK with key key2, to
yield string hashverifyA
(2) verify whether hashA=hashverifyA
hashA
Rene Struik, Certicom Corp.

52. Mutual Public Key Authenticated Key Agreement Protocol (2)
May, 2002
Mutual Public Key Authenticated Key Agreement Protocol (2)
Implicit Certificates
Public key derived from publicly available information, i.e.,
- Reconstruction data DA of party A involved;
- Identity IdA of the device A;
- Authentic public key WT of trusted party (who issued implicit certificate).
Formula: WA=g(IdA,DA,WT)= rDA +WT, where r=hash(IdA||DA)
MQV Implicit Key Agreement
K= sA sB P
= (x + a · map(X)) (y + b · map(Y))P
= (x + a · map(X)) (Y + map(Y)WB)
= (y + b · map(Y)) (X + map(X)WA)
System-wide parameters
P is a fixed point on the shared elliptic curve E
map converts an elliptic curve point to an integer
Rene Struik, Certicom Corp.

53. Mutual Public-Key Authenticated Key Agreement Protocol (1)
May, 2002
Mutual Public-Key Authenticated Key Agreement Protocol (1)
Communicated messages
Step 1 (A B): X || CertT(IdA ,WA)
Step 2 (A B): hashB || Y || CertT(IdB ,WB)
Step 3 (A B): hashA
Communications bandwidth
Binary NIST-curve K-163 (80-bit security) Hash RND Cert Total
ECC Point: 22 bytes Step 1: = 56
Certificate: = 34 bytes Step 2: = 66
Hash string: 20 bytes Step 3: = 10
total bytes:
Binary NIST-curve K-283 (128-bit security)
ECC Point: 37 bytes Step 1: = 86
Certificate: = 49 bytes Step 2: = 102
Hash string: 32 bytes Step 3: = 16
total bytes:
Rene Struik, Certicom Corp.

54. Mutual Public Key Authenticated Key Agreement Protocol (2)
May, 2002
Mutual Public Key Authenticated Key Agreement Protocol (2)
(80-bit security) Computational cost for device A (similar for B):
30 MHz MHz
Step 1 (A B): B: 19.5/16/12.5 ms B: 214/174/135 ms
Step 2 (A B): A: /17/13.5 ms A: 222/182/143 ms
Step 3 (A B): B: ms B: 8 ms
Critical path: 5 superframes +1ms /8/7 (all split) superframes + 8ms
(each superframe: 65 ms)
(Without parallel hardware) MQV and cert separate/combined/ MQV without cert
Computational cost
Binary NIST-curve K-163 (80-bit security) 30MHz MHz
Point multiplication: ms ms
MQV key computation: ms ms
Public key reconstruction: 7 ms ms
MQV key with implicit certificates: 14 ms ms
Key derivation function: <1 ms ms
SHA-1 computation: < 1 ms ms
Rene Struik, Certicom Corp.

55. Mutual Public Key Authenticated Key Agreement Protocol (3)
May, 2002
Mutual Public Key Authenticated Key Agreement Protocol (3)
(128-bit security) Computational cost for device A (similar for B):
30 MHz MHz
Step 1 (A B): B: 54.5/44/33.5 ms B: 610/490/373 ms
Step 2 (A B): A: /45/34.5 ms A: 618/498/381 ms
Step 3 (A B): B: ms B: 8 ms
Critical path: 5 superframes + 1ms /13/11 (all split) superframes +8ms
(each superframe: 65 ms)
(Without parallel hardware) MQV and cert separate/combined/ MQV without cert
Computational cost
Binary NIST-curve K-283 (128-bit security)30MHz MHz
Point multiplication: ms ms
MQV key computation: ms ms
Public key reconstruction: ms ms
MQV key with implicit certificates: 42 ms ms
Key derivation function: <1 ms ms
SHA-2 computation: < 1 ms ms
Rene Struik, Certicom Corp.

56. Block-Cipher Modes of Operation: CTR Mode (1)
May, 2002
Block-Cipher Modes of Operation: CTR Mode (1)
Encryption: EK t1 c1 x1 t2 c2 x2 t3 c3 x3
tm-1
cm-1
xm-1 tm cm xm
counters
Encryption algorithm:
cj:=EK(tj) xj for all j>0.
Decryption: EK t1 x1 c1 t2 x2 c2 t3 x3 c3
tm-1
xm-1
cm-1 tm xm cm
counters
Decryption algorithm:
xj:=DK(tj) cj for all j>0.
Rene Struik, Certicom Corp.

57. Block-Cipher Modes of Operation: CTR Mode (2)
May, 2002
Block-Cipher Modes of Operation: CTR Mode (2)
Security requirement:
-Counters t1, t2, t3, … shall all be distinct over
lifetime key K.
Encryption computation:
-Full parallelization of computation possible;
-No access to plaintext required for computation;
-Access to t1, t2, t3, … needed for computation.
Decryption computation:
-No access to ciphertext required for computation;
Message size:
-No plaintext expansion needed!
(ciphertext can be truncated to plaintext length).
Implementation:
-Only encryption function EK needs to be
implemented.
Encryption algorithm:
cj:=EK(tj) xj for all j>0.
Decryption algorithm:
xj:=DK(tj) xj for all j>0.
Rene Struik, Certicom Corp.

58. Block-Cipher Modes of Operation: CTR Mode (3)
May, 2002
Block-Cipher Modes of Operation: CTR Mode (3)
Example: Use of CTR-mode of operation in IEEE High-Rate WPAN.
Block-cipher: AES-128 {block-cipher length: 128 bits}.
counter value=(IdA || Nonce || j), where
IdA: identifier of sender (64-bits field, right-adjusted);
Nonce: inter-frame sequence number (48-bits field, right-adjusted);
j: intra-frame sequence number (16-bits field, right-adjusted).
Motivation:
IdA is included to ensure logical separation between senders who have same key
(no re-use of same IV value between different senders; no synchronization required);
Nonce and j are included to ensure no re-use of same IV between different data
frames (via increment of Nonce-value) and within blocks in a frame (via increment of j-value).
Combinatorial freedom:
Maximum size of data frame= max. #blocks  encryption block size = 216 * 27= 223 = 1Mbytes;
Maximum #data frames = max. #Nonce values = 248 data frames.
(At 256 kbps data rate, roughly 236 encryption blocks per year if 100% active; 224 encryption blocks
if 0.25% of time active)
NB: current max. frame length: <210 bits = 128 bytes; at 256 kbps data rate, exhaustion after 212 years.
Rene Struik, Certicom Corp.

59. Block-Cipher Modes of Operation: CTR Mode (4)
May, 2002
Block-Cipher Modes of Operation: CTR Mode (4)
Example (cont’d): Use of CTR-mode of operation in IEEE High-Rate WPAN.
Status information:
Nonce and j are included to ensure no re-use of same IV between different data
frames (via increment of Nonce-value) and within blocks in a frame (via increment of j-value).
Trade-off between amount proportion of (Nonce,j) information that is communicated and proportion
that is kept synchronized between sending device and recipient(s).
(1) Full dependency on status information: no communication overhead, but unstable if
transmission errors occur.
(2) No dependency on status information: full communication overhead, but stable if transmission
errors occur.
Some data expansion seems desirable to compensate for transmission errors.
Choice (up to discussion):
Communication overhead counter: 1 byte;
Synchronization overhead counter: remainder.
Note: The proper choice depends on the noise characteristics of the channel.
Rene Struik, Certicom Corp.

60. MACs Based on Block-Ciphers : CBC-MAC (1)
May, 2002
MACs Based on Block-Ciphers : CBC-MAC (1)
CBC-MAC: x1 EK x3
xm-1 xm cm
IV:=0
CBC-MAC algorithm:
cj:=EK(xj cj-1) for j=1,…,m;
c0:=IV:=0;
MAC:=cm. x2
Strengthened CBC-MAC: EK x1 x2 x3
xm-1 xm
IV:=0
DK’
MAC
Strengthened CBC-MAC algorithm:
cj:=EK(xj cj-1) for j=1,…,m;
c0:=IV:=0;
MAC:=EK(DK’(cm)).
(Bellare, Kilian, Rogaway)
Rene Struik, Certicom Corp.

61. MACs Based on Block-Ciphers: CBC-MAC (2)
May, 2002
MACs Based on Block-Ciphers: CBC-MAC (2)
Security requirement:
-Keys K and K’ should be independent;
{This prevents chosen-text existential forgery attacks.}
- If K=K’, then
Strengthened CBC-MAC=CBC-MAC.
(Strengthened) CBC-MAC computation:
-No parallelization of computation possible;
-Management of two keys, K and K’, required.
Data integrity field size:
-MAC value has size equal to encryption block length
(truncated outputs possible, in exchange for reduced security level).
Implementation:
-Both encryption function EK and decryption function DK’
need to be implemented.
Rene Struik, Certicom Corp.

62. Implementation Issues
May, 2002
Implementation Issues
Block-Cipher: AES-128 in CTR mode.
Un-keyed hash function: SHA-256 {block length: 512 bits}.
Keyed hash function: CBC-MAC function.
Public key system: ECC, based on binary Koblitz curves
Key Agreement Protocol: Full MQV with Key Confirmation
Certificates: Short ECC certificates
AES-128 implementation:
CTR Mode: implement AES-128 encryption only.
Gate count estimate: 4.5 k, including registers [around 10k if decryption also implemented]
SHA-256 cost during key agreement (if implemented in software):
Full MQV with Key Confirmation: additional 15% workload compared to hardware only.
MAC implementation (in hardware):
CBC-MAC: implement both AES-128 encryption and AES-128 decryption.
*AES-OCB with Authentic Side Information: implement both AES-128 encryption and decryption
(Note: Attractive if 55 Mbps 500 Mbps, since encr + auth computations carried out in parallel.)
ECC Implementation:
Binary field multiplier: Gate count estimate: 6-7k, including registers
Rene Struik, Certicom Corp.

63. May, 2002
MAC Frame
Formats
Rene Struik, Certicom Corp.

64. Frame Formats (1) Existing data frame format:
May, 2002
Frame Formats (1)
Existing data frame format:
octets: 2
0/2
0/1/8 1
variable 2
Frame Control
Destination
PAN Id
Destination Address
Source
Source Address
Sequence
number
Payload
CRC value
Secure data frame format:
octets: 2
0/2
0/1/8 1
variable
0/2/4/8/16 2
Frame Control
Destination
PAN Id
Destination Address
Source
Source Address
Sequence
number
Algorithm Id
Payload
“MAC
value”
CRC value
Applications: message transport in any of the following ways: unsecured, secure, authentic, secure and
authentic.
Rene Struik, Certicom Corp.

65. Frame Formats (2) Existing command format: Secure command format:
May, 2002
Frame Formats (2)
Existing command format:
octets: 2
(See ) 1
variable 2
Frame Control
Destination
PAN Id/Address
and/or Source
Sequence
number
Command
type
Command Payload
CRC value
Secure command format:
octets: 2
(See ) 1
variable 2
Frame Control
Destination
PAN Id/Address
and/or Source
Sequence
number
Command
type
Algorithm Id
Key Info
Challenge
Response
Text
CRC value
Applications: authenticated key agreement (both public key and symmetric key), entity authentication,
unilateral and mutual support, general challenge response protocols
Rene Struik, Certicom Corp.