March 2007 Slide 1 doc.: IEEE 802.11-07/0293r0 Submission TGr Key Derivation Functions Notice: This document has been prepared to assist IEEE 802.11. 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 grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < http:// ieee802.org/guides/bylaws/sb-bylaws.pdf >, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <[email protected]> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If Date: 2007-02-26 N am e C om pany A ddress Phone em ail Lily Chen NIST 100 Bureau D r,G aithersburg M D 29841 +1 301 975 6974 [email protected]N ancy Cam -W inget Cisco 190 W estTasm an D r San Jose, Ca 95134 +1-408-853-0532 ncam wing@ cisco.com Authors:
Transcript
March 2007
Slide 1
doc.: IEEE 802.11-07/0293r0
Submission
TGr Key Derivation Functions
Notice: This document has been prepared to assist IEEE 802.11. 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 grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <[email protected]> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <[email protected]>.
Date: 2007-02-26
Name Company Address Phone email Lily Chen NIST 100 Bureau Dr, Gaithersburg
This submission considers:– use of CMAC AES-128 vs. HMAC-SHA256 based KDF– use of string PRF (sPRF) vs. vector PRF (vPRF)
Motivation based on 11-07-0087-03
March 2007
Slide 3
doc.: IEEE 802.11-07/0293r0
Submission
Current KDF in 802.11r
Y1 Y2 Yk
i = 1 i = 2 i = k
L-bits
HMAC
i A B C
K
HMAC HMAC
K K
• Uses HMAC-SHA256 as a PRF with a counter mode:
PRF = HMAC-SHA256(K, M)• M = A||B||C, where A, B, C are data
fields. • KDF executes the PRF repeatedly
with the same string but different counter until the required number of bits are generated.
March 2007
Slide 4
doc.: IEEE 802.11-07/0293r0
Submission
CMAC-AES-128 vs. HMAC-SHA256
HMAC-SHA256 CMAC-AES-128
22.230 MB/second* 55.447 MB/second*
51.71 MB/second** 75.001 MB/second**
Y
256-bits
HMAC
K
X
Y
CMAC
K
128-bits
X
*http://www.cryptopp.com/benchmarks.html
**Courtesy of Jouni Malinen
CMAC-AES-128 is roughly twice as fast as HMAC-SHA256.
However, each execution of HMAC-SHA256 produces twice keying data as each CMAC-AES -128.
Given low bandwidth requirements: Replacing HMAC-SHA-256 with AES-128-CMAC may only improve little (if any) efficiency.
These numbers also do not consider the key schedule setup time.
March 2007
Slide 5
doc.: IEEE 802.11-07/0293r0
Submission
Why consider AES-128-CMAC vs. HMAC-SHA256?
• There are some slight performance advantages but not significant (e.g. < 5x improvement)
• However, reducing the number of ciphers used in TGr may be perceived as better simplification
March 2007
Slide 6
doc.: IEEE 802.11-07/0293r0
Submission
String PRF vs. Vector PRF
• Beyond the efficiency of the underlying cipher algorithm, is there merit in using a vPRF*
construction?
* We use CMAC as the underling PRF.
March 2007
Slide 7
doc.: IEEE 802.11-07/0293r0
Submission
Single String PRF fK (A || B || C)
EK is one or more basic operations, like AES.
EK
A
CMACK(X’)
B C’
EK EK
EK
A
CMACK(X)
B C
EK EK
padding
padding
Issues raised (by Rogaway & Shrimpton)
1. Prevents from parallel processing
2. Prevents from reusing.
B has to wait A to be processed.
A || B part must be re-processed for the second message.
March 2007
Slide 8
doc.: IEEE 802.11-07/0293r0
Submission
Vector PRF fK([22fK(A)⊕2fK(B)]⊞C)
CMACK
A B
CMACK
CMACK(X)
C
CMACK
U V
22U ⊕ 2V
CMACK(X’)
C’
CMACK
⊞
⊞
A and B can be processed in parallel. (But padded separately as well! Here the function is not EK anymore but a full CMACK )
The intermediate result can be reused to compute another. Need memory and data fetching.
⊞ is Xor with the rightmost n bits, where n is the output length of PRF.
March 2007
Slide 9
doc.: IEEE 802.11-07/0293r0
Submission
Questions to 11r
• Can TGr take advantage of vPRF?– Are the gains from parallelization significant enough?
• If the components are not long, it may not worth the cost of re-scheduling for parallel processing. Especially for CMAC, it implies padding each data field separately and make the subkey available for each AES engine.
• How many AES engines do we have in an end user device?• For PMK-R0, PMK-R1s, and PTK, how long each component will be?
Do we really need to split the input data in order to allow parallel processing.
– Are the gains from cacheing significant enough?• How many PMK-R1’s do we expect to generate per PMK-R0?• How many PTK’s do we expect to generate per PMK-R1?
With vPRF, the first 6 AES blocks will be processed once and then used for each counter.
Y1
SPA
CMACK
⊞
i=1
384 bits
SPA
CMACK
⊞
i=2
Y2
SPA
CMACK
⊞
i=3
Y3
6 AES blocks 1 AES block 1 AES block 1 AES block
March 2007
Slide 11
doc.: IEEE 802.11-07/0293r0
Submission
How much we can save in PMK-R0 derivation with vPRF?
sCMAC vCMAC
AES Operations 21 blocks 6+1+1+1 = 9 blocks
Memory None 128 bits
CMAC function call* 3 4
*Each CMAC operation takes one AES operation to generate a sub-key.
• For each STA, only one PMK-R0 is generated. Therefore, re-using intermediate result does not add much efficiency to PMK-R0 derivation (save 11 AES operations). • For 7 AES message blocks, parallel processing is not necessary.
March 2007
Slide 12
doc.: IEEE 802.11-07/0293r0
Submission
Mapping PMK-R1 KDF to vPRF
CMACK
“R1 Key Derivation” SPA
U
2U Y1
CMACK
⊞
Y2
R1KH-ID
CMACK
⊞
i=2
256 bitsPre-computed and reused for all.
i=1 R1KH-ID
2 AES blocks 1 AES block 1 AES block
•For PMK-R1 derivation, each PRF needs to process about 3 AES blocks. The counter will go from 1 to 2 (2 iterations.)
March 2007
Slide 13
doc.: IEEE 802.11-07/0293r0
Submission
How much we can save in PMK-R1 derivation with vPRF?
sCMAC vCMAC
AES Operations 6 blocks 2+1+1 = 4 blocks
Memory None 128 bits
CMAC function call* 2 3
• For PMK-R1 derivation, each PRF needs to process about 3 AES blocks. Do we really need to process 3 blocks in parallel?
• For intermediate result reuse: lets discount the price of first PMK-R1 computation cost. Subsequent PMK-R1’s require 4 more AES blocks in sPRF over vPRF….if 1k keys are generated, this savings is at most .0008sec.
March 2007
Slide 14
doc.: IEEE 802.11-07/0293r0
Submission
Mapping PTK KDF to vPRF
CMACK
“PTK Key Derivation” SPA
U
2U Y1
CMACK
⊞
Y4
CMACK
⊞
i=4
512 bitsPre-computed and reused for all.
i=1X1
NOTE: to gain vector benefit, concatenation order is modified!
• For each PMK-R1 and one handshake, i.e. one pair of Anonce and Snonce, only one PTK is generated. Therefore, re-using intermediate result does not add much efficiency to PTK derivation (save 24 AES operations). • For 8 AES message blocks, parallel processing is not necessary.
March 2007
Slide 16
doc.: IEEE 802.11-07/0293r0
Submission
HMAC-SHA256 sPRF vs. AES-128-CMAC vPRF**
• Measurements for a single key derivation:– Generation of PMK-R0: 2.8X– Generation of PMK-R1: 1.5X
• Optimizations over multiple KDF operations (same PMK-R0 and SPA, R1KH-ID changes):
– 10 x PMK-R1: 3.0 X– 20 x PMK-R1: 3.2 X – 100 x PMK-R1: 3.3 X
• Must also consider setup costs if keys are not generated all at the same time:
**All measurements taken on Pentium M, C implementation built with gcc; courtesy Jouni Malinen
March 2007
Slide 17
doc.: IEEE 802.11-07/0293r0
Submission
Summary
Key PMK-R0 PMK-R1 PTK
vCMAC 9 AES ops
128 bits memory
4 CMAC calls
4 AES ops
128 bits memory
3 CMAC calls
12 AES ops
128 bits memory
5 CMAC calls
sCMAC 21 AES ops
0 bit memory
3 CMAC calls
6 AES ops
0 bit memory
2 CMAC calls
36 AES ops
0 bit memory
4 CMAC calls
Save 11 AES ops
< 2-17 second
1 AES op
< 2-20 second
23 AES ops
<2-16 second
•Using the max throughput AES-CMAC of 75 Megabytes/second*. Each AES operation processes 16 = 24 bytes data.
March 2007
Slide 18
doc.: IEEE 802.11-07/0293r0
Submission
In order to use vPRF for 802.11r KDF …
• vPRF requires at least 128 bits memory for intermediate results.
• The input data must be vectorized in an unambiguous way.
• It takes at least one more CMAC call compared with string CMAC.
March 2007
Slide 19
doc.: IEEE 802.11-07/0293r0
Submission
Do we really need vPRF for 802.11r KDF?
• vPRF designed to improve efficiency for a process that require many AES operations.
• For 802.11 KDF, at most 9 AES blocks are processed for each PRF execution. – Parallelism is not necessary.
– Intermediate result reuse only applies to PMK-R1 derivation: to amortize gain, at best ~.0008sec is saved if 1000 PMK-R1’s are generated from the same PMK-R0
• It is not clear vector CMAC gains 11r any significant performance efficiency.
March 2007
Slide 20
doc.: IEEE 802.11-07/0293r0
Submission
How about single string CMAC?
• CMAC-AES-128 or CMAC-AES-256?– Currently all the input keys, MSK, PMK-R0 and PMK-R1, are all
256 bits.
– Using CMAC-AES-128 will reduce the entropy for the derived keying material to 128 bits. Is this acceptable for 11r?
– Using CMAC-AES-256 will maintain 256 bits key strength. But it will make the efficiency reduce to barely 2 times of HMAC-SHA-256. (Notice that the output length of AES-256 is still 128 bits).
• We still need a Hash Function for Key Names.
March 2007
Slide 21
doc.: IEEE 802.11-07/0293r0
Submission
Replacing HMAC-SHA256 with AES-128-CMAC
• Changes to Clause 8.5a.3 to replace HMAC-SHA256 with AES-128-CMAC is required
• Consideration for changing how Keynames are generated should be imposed.
March 2007
Slide 22
doc.: IEEE 802.11-07/0293r0
Submission
Use CMAC to generate key name
• We can use CMAC to generate key names. That is, replace non-keyed hash with keyed hash**.
– PMK-R0 Name = CMAC(PMK-R0Name-Salt, “R0 Key Name”). That is, using PMK-R0Name-Salt as a key. Here we assume that CMAC-AES-128 is used.
– PMK-R1 Name = CMAC(PMK-R1Name-Salt, “R1 Key Name” || R1KH-ID || S1KH-ID), where PMK-R1Name-Salt will be the extra bits of PMK-R1.
– PTKName = CMAC(PTK-Name-Salt, “PTKName”, SNonce ||ANonce||BSSID||SPA). Similarly, PTK-Name-Salt will be the extra bits of PTK.
• For each Key, only one PMK-R0 is derived. Therefore, re-using intermediate result does not apply to PMK-R0 derivation. (The counter will go from 1 to 3.)
• For PMK-R0 derivation, each PRF needs to process about 7 AES blocks. Do we really need to process 7 blocks in parallel?
• For PMK-R1 derivation, each PRF needs to process about 3 AES blocks. Do we really need to process 3 blocks in parallel?
• For intermediate result reuse, we are talking processing 2 AES blocks as intermediate result and then another 1 or 2 AES blocks for each PMK-R1. Is this worth the trouble? For PMK-R1, the counter goes from 1 to 2.
• For PMK-R1 derivation, each PRF needs to process about 7 AES blocks. Do we really have a need to process 7 blocks in parallel?
• For each PMK-R1, and each 4-way handshake to exchange new ANonce and Snonce, only one PTK is derived. Therefore, intermediate result reuse does not apply to PTK derivation.
• For different handshakes, the large portion of data, Anonce and Snonce (plus counter, 5 blocks), must be processed each time. The reuse part is only on about the data in 3 blocks. Therefore, it is not meaningful.
