answer to your question (quoted at the end of this message) t= hat does not

take into account the specifics of IEEE 802.15.6 but only the question of h= ow

to use a block cipher in CMAC mode to process a DH key (the details = of

IEEE 802.15.6 may or may not interfere with this advise).

There are two obvious problems with inputting the DH key directly as CMAC k= ey:

(1) the DH key is likely to be of a different size than the CMAC key= ,

(2) the DH key is not a uniformly distributed string (but rather a un= iformly

distributed element in some algebraic group -- more precisely, assuming the=

Decisional Diffie-Hellman assumption, the distribution of DH keys is

computationally indistinguishable from the uniform distribution on the DH<= br> group).

A trivial way to resolve the first issue (assuming the DH ke= y is longer than the

CMAC one) is to truncate the DH key to the number o= f CMAC key bits. There are

theoretical reasons (though not necessarily a= n attack) NOT to do so (e.g., since

the DH key is not a uniform string of bits, a subset of it may not be unifo= rm

either). A better way would be to apply an extractor to the DH key an= d use the output

as the CMAC key (much as in the HKDF design). Since you= do not want to use a

hash function then you need to do the extraction using the block cipher its= elf.

I only know of one work that analyzes such a scheme and it is the

the block cipher acts as a family of random permutations then you can use C= MAC

with that block cipher as an extractor. The security bounds guarante= ed by that

analysis are not great (and the random permutation assumption= is an idealized

one), yet it is the best analysis we have for such a beast.

NOTE: Ou= r revised analysis of the CBC case replaces the expression e(L,K)

in th= e proceedings version of the paper with L^4/K^2 which is worse than the

original bound but of little consequence in the application below where L i= s a

very small number (i.e., L=3D the number of blocks in the represent= ation of DHK,

where the length of a block is determined by the underlyi= ng block cipher).

The available version of the paper (with the old bound) is

http://cs.nyu.edu/~dodis/ps/hmac.ps= .

If you want to buy that analysis as an indication of security then= I can suggest

the following. Let DHK be the DH key that is output by your protocol and le= t CK

be the CMAC key that you want to generate.

(a) Assuming that= you are running an authenticated Diffie-Hellman protocol

between the pa= rties to generate the DH key DHK, add to the protocol the

generation of a nonce that is exchanged and AUTHENTICATED by the parties.

independent of the DH key DHK).

(b) Apply CMAC with N as t= he key and DHK as the input (i.e., DHK acts as the

message, or plaintext, for the CMAC function and N acts as the key).

(c) Use the value output by (b) as the key CK (this assumes that the outpu= t

length from CMAC is the same as the length of a CMAC key -- this is th= e case

for AES-128 but not for AES-256).

IMPORTANT: If your protocol cannot= exchange a nonce, or can exchange it but

cannot authenticate it (in whi= ch case the nonce can be chosen by an attacker)

then replace N with a fi= xed value that is defined and wired it into the protocol

as a constant. Choose N to be any "random" string of the length o= f a CMAC key.

(I prefer to use a random-looking N rather than something = like all-zero string

in case that such a structured key may turn to be a= "weak key" of the underlying

cipher).

Hugo

> Hugo,

>

> In the proposed IEE= E 802.15.6 standard, an ECDH derived key is expanded via CMAC

> to pr= oduce the actual keying material.=C2=A0 No cryptographic hash is used in th= is

> protocol.

>

> This seems to go contrary to the recommenda= tion in

> http://www.ietf.org/id/draft-irtf-cfrg-kdf-uses-00.txt that DH = derived keys are

> NOT uniformly distributed and MUST be passed through an extract phase = (eg as in

> HKDF).

>

> Can you please point me to a refe= rence to the nature of the attack in this

> usage.=C2=A0 This method = will end up in medical devices like Insulin pumps,

> Pacemakers, etc and I am looking for hard references to get the author= s to make

> needed changes.

--000e0cd3291cab5b10048b4f3615-- From rgm-sec@htt-consult.com Tue Jul 13 19:59:32 2010 Return-Path:

Fantastic analysis, I my very limited, but appreciative opinion.

I can 'run' with this.

On 07/13/2010 06:50 PM, Hugo Krawczyk wrote:

Bob, I cannot give an assessment of protocols or standards that I am not

familiar with, and IEEE 802.15.6 is one of them. So let me give you a generic

answer to your question (quoted at the end of this message) that does not

take into account the specifics of IEEE 802.15.6 but only the question of how

to use a block cipher in CMAC mode to process a DH key (the details of

IEEE 802.15.6 may or may not interfere with this advise).

There are two obvious problems with inputting the DH key directly as CMAC key:

(1) the DH key is likely to be of a different size than the CMAC key,

(2) the DH key is not a uniformly distributed string (but rather a uniformly

distributed element in some algebraic group -- more precisely, assuming the

Decisional Diffie-Hellman assumption, the distribution of DH keys is

computationally indistinguishable from the uniform distribution on the DH

group).

A trivial way to resolve the first issue (assuming the DH key is longer than the

CMAC one) is to truncate the DH key to the number of CMAC key bits. There are

theoretical reasons (though not necessarily an attack) NOT to do so (e.g., since

the DH key is not a uniform string of bits, a subset of it may not be uniform

either). A better way would be to apply an extractor to the DH key and use the output

as the CMAC key (much as in the HKDF design). Since you do not want to use a

hash function then you need to do the extraction using the block cipher itself.

I only know of one work that analyzes such a scheme and it is the

Dodis-Gennaro-Hastad-Krawczyk-Rabin paper from Crypto'04.

I had this 'handed' to me this afternoon by one person here at the 802 meeting that just happened to have this buried in his archive of interesting papers and remembered it. Lots more reading for me.

There we show that if--------------020400080801090601080905-- From rgm-sec@htt-consult.com Tue Jul 13 20:05:16 2010 Return-Path:

the block cipher acts as a family of random permutations then you can use CMAC

with that block cipher as an extractor. The security bounds guaranteed by that

analysis are not great (and the random permutation assumption is an idealized

one), yet it is the best analysis we have for such a beast.

NOTE: Our revised analysis of the CBC case replaces the expression e(L,K)

in the proceedings version of the paper with L^4/K^2 which is worse than the

original bound but of little consequence in the application below where L is a

very small number (i.e., L= the number of blocks in the representation of DHK,

where the length of a block is determined by the underlying block cipher).

The available version of the paper (with the old bound) is

http://cs.nyu.edu/~dodis/ps/hmac.ps.

If you want to buy that analysis as an indication of security then I can suggest

the following. Let DHK be the DH key that is output by your protocol and let CK

be the CMAC key that you want to generate.

(a) Assuming that you are running an authenticated Diffie-Hellman protocol

between the parties to generate the DH key DHK, add to the protocol the

generation of a nonce that is exchanged and AUTHENTICATED by the parties.

This nonce, call it N, is to be of the length of the CMAC key (and it should be

independent of the DH key DHK).

(b) Apply CMAC with N as the key and DHK as the input (i.e., DHK acts as the

message, or plaintext, for the CMAC function and N acts as the key).

(c) Use the value output by (b) as the key CK (this assumes that the output

length from CMAC is the same as the length of a CMAC key -- this is the case

for AES-128 but not for AES-256).

IMPORTANT: If your protocol cannot exchange a nonce, or can exchange it but

cannot authenticate it (in which case the nonce can be chosen by an attacker)

then replace N with a fixed value that is defined and wired it into the protocol

as a constant. Choose N to be any "random" string of the length of a CMAC key.

(I prefer to use a random-looking N rather than something like all-zero string

in case that such a structured key may turn to be a "weak key" of the underlying

cipher).

Hugo

> Hugo,

>

> In the proposed IEEE 802.15.6 standard, an ECDH derived key is expanded via CMAC

> to produce the actual keying material. No cryptographic hash is used in this

> protocol.

>

> This seems to go contrary to the recommendation in

> http://www.ietf.org/id/draft-irtf-cfrg-kdf-uses-00.txt that DH derived keys are

> NOT uniformly distributed and MUST be passed through an extract phase (eg as in

> HKDF).

>

> Can you please point me to a reference to the nature of the attack in this

> usage. This method will end up in medical devices like Insulin pumps,

> Pacemakers, etc and I am looking for hard references to get the authors to make

> needed changes.

_______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg

On 07/13/2010 06:50 PM, Hugo Krawczyk wrote:

Bob, I cannot give an assessment of protocols or standards that I am not--------------090502090309000308070709-- From mcgrew@cisco.com Fri Jul 23 12:40:44 2010 Return-Path:

familiar with, and IEEE 802.15.6 is one of them. So let me give you a generic

answer to your question (quoted at the end of this message) that does not

take into account the specifics of IEEE 802.15.6 but only the question of how

to use a block cipher in CMAC mode to process a DH key (the details of

IEEE 802.15.6 may or may not interfere with this advise).

There are two obvious problems with inputting the DH key directly as CMAC key:

(1) the DH key is likely to be of a different size than the CMAC key,

(2) the DH key is not a uniformly distributed string (but rather a uniformly

distributed element in some algebraic group -- more precisely, assuming the

Decisional Diffie-Hellman assumption, the distribution of DH keys is

computationally indistinguishable from the uniform distribution on the DH

group).

A trivial way to resolve the first issue (assuming the DH key is longer than the

CMAC one) is to truncate the DH key to the number of CMAC key bits. There are

theoretical reasons (though not necessarily an attack) NOT to do so (e.g., since

the DH key is not a uniform string of bits, a subset of it may not be uniform

either). A better way would be to apply an extractor to the DH key and use the output

as the CMAC key (much as in the HKDF design). Since you do not want to use a

hash function then you need to do the extraction using the block cipher itself.

I only know of one work that analyzes such a scheme and it is the

Dodis-Gennaro-Hastad-Krawczyk-Rabin paper from Crypto'04. There we show that if

the block cipher acts as a family of random permutations then you can use CMAC

with that block cipher as an extractor. The security bounds guaranteed by that

analysis are not great (and the random permutation assumption is an idealized

one), yet it is the best analysis we have for such a beast.

NOTE: Our revised analysis of the CBC case replaces the expression e(L,K)

in the proceedings version of the paper with L^4/K^2 which is worse than the

original bound but of little consequence in the application below where L is a

very small number (i.e., L= the number of blocks in the representation of DHK,

where the length of a block is determined by the underlying block cipher).

The available version of the paper (with the old bound) is

http://cs.nyu.edu/~dodis/ps/hmac.ps.

If you want to buy that analysis as an indication of security then I can suggest

the following. Let DHK be the DH key that is output by your protocol and let CK

be the CMAC key that you want to generate.

(a) Assuming that you are running an authenticated Diffie-Hellman protocol

between the parties to generate the DH key DHK, add to the protocol the

generation of a nonce that is exchanged and AUTHENTICATED by the parties.

This nonce, call it N, is to be of the length of the CMAC key (and it should be

independent of the DH key DHK).

(b) Apply CMAC with N as the key and DHK as the input (i.e., DHK acts as the

message, or plaintext, for the CMAC function and N acts as the key).

(c) Use the value output by (b) as the key CK (this assumes that the output

length from CMAC is the same as the length of a CMAC key -- this is the case

for AES-128 but not for AES-256).

IMPORTANT: If your protocol cannot exchange a nonce, or can exchange it but

cannot authenticate it (in which case the nonce can be chosen by an attacker)

then replace N with a fixed value that is defined and wired it into the protocol

as a constant. Choose N to be any "random" string of the length of a CMAC key.

(I prefer to use a random-looking N rather than something like all-zero string

in case that such a structured key may turn to be a "weak key" of the underlying

cipher).

Hugo

> Hugo,

>

> In the proposed IEEE 802.15.6 standard, an ECDH derived key is expanded via CMAC

> to produce the actual keying material. No cryptographic hash is used in this

> protocol.

>

> This seems to go contrary to the recommendation in

> http://www.ietf.org/id/draft-irtf-cfrg-kdf-uses-00.txt that DH derived keys are

> NOT uniformly distributed and MUST be passed through an extract phase (eg as in

> HKDF).

>

> Can you please point me to a reference to the nature of the attack in this

> usage. This method will end up in medical devices like Insulin pumps,

> Pacemakers, etc and I am looking for hard references to get the authors to make

> needed changes.

_______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg

there was a detailed discussion about EAX' =
(that's pronounced "EAX prime") and the C12.22 encryption requirements =
on the csctgcrypto@nist.gov mail =
list May-June. ANSI C12.22 uses EAX', which is slightly different =
from (and not interoperable with) EAX. In an appendix of the ANSI =
standard, there is an analysis of CCM and why it is not sufficient and =
why a new AEAD method is needed. That appendix was recently =
revised (Tom Phinney, who I've copied on this message, sent the revision =
to the NIST SG crypto mail list) in order to correct a wrong assumption =
and add the justification of why GCM is not sufficient. Perhaps =
Tom could forward the new justification to the =
list.

I personally did not =
find the justification for EAX' compelling, in part because it seemed to =
me that if the protocol had adequate key management, then an existing =
mode of operation would be sufficient. Apparently it uses a =
group-key model, which imposes restrictions on key usage and nonces/IVs. =
I suspect that there are better ways to solve this problem, such =
as using something like Encrypted Key Transport along with GCM or CCM, =
or using AES SIV for that matter. At any rate, it would be =
useful to have more review of the EAX' issues (and the key management =
used in C12.22), and people should form their own opinions. =

David

=
--Apple-Mail-23-959148852--
On Jul 13, =
2010, at 9:09 AM, Sean Turner wrote:

Has = anybody reviewed ANSI C12.22 and it's use of = AES-EAX?

sptFrom:Internet-Drafts@ietf.org

<= /span>Date:July 9, 2010 4:45:01 PM PDTSubject: =I-D Action:draft-c1222-transport-over-ip-04.txt =Reply-To:internet-drafts@ietf.org

<= /span>

A New Internet-Draft is available from the on-line = Internet-Drafts directories.

Title = : ANSI = C12.22, IEEE 1703 and MC12.22 Transport Over IP

Author(s) = : A. Moise, J. Brodkin

Filename = : = draft-c1222-transport-over-ip-04.txt

Pages = : = 23

= Date = : = 2010-07-09

This RFC provides a framework for transporting ANSI = C12.22/IEEE 1703/

MC12.22 Advanced Metering Infrastructure (AMI) = Application-Layer

Messages on an IP network.

A URL for this = Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-c1222-transport-over-ip-= 04.txt

Internet-Drafts are also available by anonymous FTP = at:

ftp://ftp.ietf.org/internet-d= rafts/

Below is the data which will enable a MIME compliant = mail reader

implementation to automatically retrieve the ASCII = version of = the

Internet-Draft.

<mime-attachment>____________= ___________________________________

I-D-Announce mailing = list

I-D-Announce@ietf.org

https://www.ietf.org/mailman/listinfo/i-d= -announce

Internet-Draft directories: = http://www.ietf.org/shadow.html

or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_____________________= __________________________

Cfrg mailing = list

Cfrg@irtf.org

http://www.irtf.org/mailman/listinfo/cfrg