doc.: ieee 802.15-10-0273-01-0006 submission slide 1 project: ieee p802.15 working group for...

doc.: IEEE 802.15-10-0273-01-0006

Submission

<May 2010>

Slide 1

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Submission Title: [Generalizaed secure services to accommodate cryptos]Date Submitted: [15 May, 2010]Source: [Masayuki Kanda, Shin’ichiro Matsuo, Masahiro Kuroda, Grace Sung, Ryuji Kohno, Toshinori Fukunaga] Company [IPA,NICT, NTT]Address [4-2-1 Nukui-Kitamachi, Koganei, Tokyo, Japan(NICT) ]Phone:[+81-42-327-6886], FAX: [+81-42-327-5519], E-Mail:[[email protected], [email protected], [email protected], [email protected], [email protected], [email protected]]

Abstract: [This document explains the updates for security services in the TG6 Draft (revision 4) 15-10-0245-04-0006-tg6-draft.doc to the TG6 group. The proposal normative text is 15-10-272-02-0006-generalized-security-services.doc. ]

Purpose: [Discussion in 802.15.6 Task Group ]

Notice: This document has been prepared to assist the IEEE P802.15. 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 P802.15.

<M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

doc.: IEEE 802.15-10-0273-01-0006

Submission

Generalized secure services to accommodate cryptos

Masayuki Kanda [IPA]

Shin’ichiro Matsuo, Masahiro Kuroda, Grace Sung, Ryuji Kohno [NICT]

Toshinori Fukunaga [NTT]

<May 2010>

Slide 2 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

doc.: IEEE 802.15-10-0273-01-0006

Submission

Outline• Addition of Security services using Camellia cipher

– Our normative text describes details of the security services process in chapter 8 that can use AES and Camellia ciphers

– Camellia is assigned to the field value “1” in the message security protocol field

• Amendment of Security association frames– Frame payload format for security disassociation frames are revised to

add security suit selector

• Other points– Technical Comment

• The length of MIC should be extended to enhance collision resistance

– Editorial Comments• Security association frame is corrected because of mistakes• KMAC calculations in 8.1.5 and 8.1.6 are corrected because of mistakes• Improper references and other mistakes are revised• Explanation of Camellia-CCM are added in Chapter 3 – Definitions

<May 2010>


doc.: IEEE 802.15-10-0273-01-0006

Submission

• For AES and Camellia, all modes of operation described in this document can be shared without any modifications

– SP800-38B/C (also ISO/IEC 19772) only specifies “Prerequisites: block cipher CIPH (with block size b)”, not “AES”

– AES and Camellia have perfectly convertible interface

Addition of Security services using Camellia cipher<May 2010>


< Ref > SP800-38B CMAC Generation <Ref> SP800-38C CCM Generation-Encryption Process

doc.: IEEE 802.15-10-0273-01-0006

Submission

Addition of Security services using Camellia cipher• Implementation outline for CCM

<May 2010>


B1 B2B0 BmB3

ctr1

ctr2

ctr0

ctrm

ctr3

Unencrypted Frame Payload

CIPHK

CIPHK

CIPHK

CIPHK

CIPHK

CIPHK

B1 B2MIC BmB3

Encrypted Frame Payload

CIPHK

CIPHK

CIPHK

CIPHK

Counter(Unencrypted)

AES Camellia

AES-CCM Camellia-CCM

CCM Process(Independence of ciphers)

Cipher(CIPHK)

Key (K)

message security protocol is “0”

message security protocol is “1”

Cipher is selected, depending on the message security protocol field in the Security_suite_selector (Ref: in 6.3.2.3.4 Table 7)

doc.: IEEE 802.15-10-0273-01-0006

Submission

Addition of Security services using Camellia cipher

8. Security Services Proposal• All present descriptions of chapter 8 can be duplicated only

except algorithm name and reference

<May 2010>


(Chap. 8.3.1) Secured frames shall be authenticated, and encrypted/decrypted when required, based on AES-128 CCM, i.e., the CCM mode as specified in the NIST Special Publication 800-38C, with the AES forward cipher function for 128-bit keys as specified in FIPS Pub 197 applied as the underlying block cipher algorithm.

Secured frames shall be authenticated, and encrypted/decrypted when required, based on Camellia-128 CCM, i.e., the CCM mode as specified in ISO/IEC 19772, with the Camellia forward cipher function for 128-bit keys as specified in ISO/IEC 18033-3 applied as the underlying block cipher algorithm.

Using AES-CCM Using Camellia-CCM

Example:

(Chap. 8.1) In these association protocols, the cipher-based message authentication code (CMAC) algorithm as specified in the NIST Special Publication 800-38B, with the AES forward cipher function under a 128-bit key as specified in FIPS Pub 197, is used to compute key message authentication codes (KMAC) and the desired shared master key. Specifically, the functional notation CMAC(K, M) represents the 128-bit output of the CMAC applied under key K to message M based on the AES forward cipher function.

In these association protocols, the cipher-based message authentication code (CMAC) algorithm as specified in the NIST Special Publication 800-38B, with the Camellia forward cipher function under a 128-bit key as specified in ISO/IEC 18033-3, is used to compute key message authentication codes (KMAC) and the desired shared master key. Specifically, the functional notation CMAC(K, M) represents the 128-bit output of the CMAC applied under key K to message M based on the Camellia forward cipher function.

Using AES-CMAC Using Camellia-CMAC

doc.: IEEE 802.15-10-0273-01-0006

Submission

Addition of Security services using Camellia cipher• Our proposal for revision: Merger of both descriptions

– Algorithm name: change “AES” to “128-bit block cipher(-based)”

– Reference: change “NIST SP” to “ISO/IEC standard”

– Clarification for algorithm selection; i.e., Message Security Protocol

<May 2010>


(Chap. 8.3.1) Secured frames shall be authenticated, and encrypted/decrypted when required, based on 128-bit block cipher-based CCM, i.e., the CCM mode as specified in ISO/IEC 19772, with the 128-bit block cipher-based forward cipher function for 128-bit keys as specified in ISO/IEC 18033-3 applied as the underlying block cipher algorithm, depending on the message security protocol in the security suite selector of the frame payload of the first Security Association frame.

Proposal - Generalized version

(Chap. 8.1) In these association protocols, depending on the message security protocol in the security suite selector of the frame payload of the first Security Association frame or the Security Disassociation frame, the cipher-based message authentication code (CMAC) algorithm as specified in the NIST Special Publication 800-38B, with the 128-bit block cipher-based forward cipher function under a 128-bit key as specified in ISO/IEC 18033-3, is used to compute key message authentication codes (KMAC) and the desired shared master key. Specifically, the functional notation CMAC(K, M) represents the 128-bit output of the CMAC applied under key K to message M based on the 128-bit block cipher-based forward cipher function.

Using CMAC

Using CCM

doc.: IEEE 802.15-10-0273-01-0006

Submission

Amendments of Security association frames• Frame payload format for security disassociation frames

are revised to add security suit selector

– 8.1.6 Disassociation

<May 2010>


RecipientAddress

SenderAddress

SenderNonce

DA_KMACRecipientAddress

SenderAddress

SecuritySuite

Selector

SenderNonce

DA_KMAC

Octets:Octet order:

(TG6 Draft rev.4)

0-5 0-5 0-1 0-15 0-76 6 2 16 8

(Proposal)Octets:

Octet order: 0-5 0-5 0-15 0-76 6 16 8

The node and the hub shall compute DA_KMAC, depending on the message security protocol in the Security_Suite_Selector, as follows: P = CMAC(MK, Address_A || Address_B || Nonce_A || Security_Suite_Seletor) DA_KMAC = LMB_64(P)

The node and the hub shall compute DA_KMAC as follows: P = CMAC(MK, Address_A ||

Address_B || Nonce_A) DA_KMAC = LMB_64(P)

* CMAC means AES-CMAC definitively

(TG6 Draft rev.4) (Proposal)

doc.: IEEE 802.15-10-0273-01-0006

Submission

Other points – Technical Comment• The length of MIC should be extended to enhance collision

resistance– 32-bit MIC is too short to achieve collision resistance from the aspect of

cryptology

– SP800-38C also states “value of Tlen that is less than 64 shall not be used without a careful analysis of the risks of accepting inauthentic data as authentic”

– If you can, should extend to 64-bit (8-octets) or more

(Chap. 8.3.1 & 8.3.1.5) The length of what is referred to as the Message Authentication Code (MAC) for message (frame) authentication in NIST Special Publication 800-38C but as the Message Integrity Code (MIC) in this standard—to be distinguished from another accustomed standing of the term MAC for medium access control—shall be four octets. That is, in the NIST Special Publication 800-38C, t = 8.

<May 2010>


doc.: IEEE 802.15-10-0273-01-0006

Submission

Other points – Editorial Comments • Security association frame (Fig. 17) is corrected

• KMAC calculations in 8.1.5 and 8.1.6 are corrected– The length of resultant KMAC is 128-bit, while the length of KMAC

field is 64-bit

– Need to add the “LMB_64” truncation

• Improper references– FIPS 186-2 is changed to FIPS 186-3

– FIPS 180-2 is changed to FIPS 180-3

<May 2010>


RecipientAddress

SenderAddress

SecuritySuite

Selector

AssociationSequenceNumber

SecurityAssociation

Data

(TG6 Draft rev.4)

0-5 0-5 0-1 0 L-R6 6 2 1 72

(Correction)

RecipientAddress

SenderAddress

SecuritySuite

Selector

AssociationSequenceNumber

SecurityAssociation

Data

0-5 0-5 0 0 L-R6 6 1 1 72

doc.: IEEE 802.15-10-0273-01-0006

Submission

Why should ready to multiple cipher suites?• Even when one of algorithms in the cipher suites is

compromised, it is easy to change to more secure one– This kind of concept, “algorithm agility,” comes common recent years

• At least two kinds of cipher should be working to achieve risk hedging

– It probably takes long time - over 18 months - to provide “new” products equipped with alternative cipher

– It is difficult to replace current products to secure ones in a short time if alternative products are not ready

• Cipher selection policy is greatly influenced by governmental security policy

<May 2010>


doc.: IEEE 802.15-10-0273-01-0006

Submission

Proposal on Selection Criteria for Cipher Suites1. Security

Selected algorithms must be resistant to cryptanalytic attacks

2. Performance on a variety of typical platformsThis includes time and space efficiency on both software and hardware

3. EndorsementThe nature of any evaluations is also of great importance, especially those conducted

by widely recognized evaluation organizations and cryptographic community

4. Number of ciphersThe number of ciphers to be standardized should be as small as possibleTwo conditions to this principle exist(a) Selected algorithms should be selected as standard or recommendation

by various well-known organizations and region in the world(b) It is desirable to have available selected algorithms based on different

fundamental principles, such that if one becomes vulnerable to cryptanalytic attack, the another has a good chance of remaining secure

<May 2010>


doc.: IEEE 802.15-10-0273-01-0006

Submission

What’s Camellia• 128-bit block cipher (allowing key sizes of 128, 192, and 256

bits), jointly developed in 2000 by NTT & Mitsubishi– Compatible interface with AES

• World’s highest security and efficiency – technically comparable to AES

• Ready for easy usage circumstance

– Camellia essential patents can be used at no charge by any user without concluding royalty-free licensing agreement

– Already adopted to various international standards & recommendations

– Already supported into various major open source software, e.g., Mozilla, OpenSSL, Linux, FreeBSD and Kerberos

– NTT’s open source codes of Camellia free of charge through multiple OSS licenses (GPL, LGPL, BSD, MPL, OpenSSL)

• Began to collaborate with MIT and Kerberos Consortium

<May 2010>


doc.: IEEE 802.15-10-0273-01-0006

Submission

Security• Achievement of the world’s highest resistant security against

state-of-the-art attacks and future unknown attacks– NO vulnerabilities of Camellia with any size of keys are found against

state-of-the-art attacks by world’s top-class researchers (over 40 papers) – World’s top-class resistant security (security margin) against unknown

attacks in the future

[FYI] In 2009, AES-192/256 can be theoretically broken using related-key attack proposed by Alex Biryukov, et al.

• Suitable to backup; based on different structure from AES– Adoption of Feistel structure (like DES), Not SPN structure (like AES)

<May 2010>


Breakable rounds 7 8 9 10 11 12 13 14 15 Original

128-bit keysSuccessful

attacksSuccessful

attacksBest Known

attacksUnknown attacks

Unknown attacks

Unknown attacks

Unknown attacks

Unknown attacks

Unknown attacks

Unknown attacks up to 18 rounds


attacksSuccessful

attacksSuccessful

attacksSuccessful

attacksBest Known


Unknown attacks

Unknown attacks

Unknown attacks

Unknown attacks up to 24 rounds

(2009.9 at the present time)

Breakable rounds for AES 6 7 8 9 10 11 12 13 14 15


attacksBest Known


Unknown attacks

Unknown attacks


attacksSuccessful

attacksSuccessful

attacksSuccessful

attacksSuccessful

attacksSuccessful

attacksSuccessful

attacksSuccessful

attacksBest Known

attacks

Ｂｒｅａｋ

doc.: IEEE 802.15-10-0273-01-0006

Submission

Performance and Flexibility• Achievement of high-speed software without dependence on

platform such as PCs or smart cards– For PCs: Performance is achieved by using many registers, pre-

computed large tables and powerful instruction sets

– For smart cards: Containment of memory usage is achieved using small tables and on-the-fly subkey generation

• Achievement of world's smallest hardware implementation with world top-class efficiency

– Substitution tables can be implemented using an inversion function over GF(28) and affine transformations

– F function can be shared between data randomization block and key scheduler

– On-the-fly subkey generation technique can be used with secret key and intermediate keys

<May 2010>


doc.: IEEE 802.15-10-0273-01-0006

Submission

Performance and Flexibility• Performance of Camellia is comparable to that of AES on

any platform– Designed world’s smallest circuit for 128-bit block ciphers (smaller

than 10 Kgates) with world top-class efficiency

<May 2010>


71.6Mbps/6.4KGs

204.6Mbps/6.3KGs

325.8Mbps/6.5KGs

1908Mbps/20.8KGs

1051Mbps/11.9KGs

567.3Mbps/9.1KGs

969.7Mbps/14.2KGs

2155Mbps/29.8KGs1881Mbps/

44.3KGs

1422Mbps/31.1KGs

(128-bit key ASIC)

971.2Mbps/7.8KGs

2024Mbps/13.2KGs

2728Mbps/20.0KGs

doc.: IEEE 802.15-10-0273-01-0006

Submission

Performance and Flexibility• Anyone can implement Camellia using open documents

Quote: “Hardware-Focused Performance Comparison for the Standard Block Ciphers AES, Camellia, and Triple-DES,”by Akashi Satoh, et al. (IBM Japan Ltd)

http://www.hpl.hp.com/conferences/isc03/pdfs/IBM%20Japan.pdf

<May 2010>


Specification available from Camellia website

doc.: IEEE 802.15-10-0273-01-0006

Submission

Performance and Flexibility• Comparison between AES and Camellia (by Satoh, et al.)

<May 2010>


doc.: IEEE 802.15-10-0273-01-0006

Submission

Performance and Flexibility• AES & Camellia Combination Hardware

Quote: “Unified Hardware Architecture for 128-bit Block Ciphers AES and Camellia ,” by Akashi Satoh (IBM Japan Ltd)

http://www.iacr.org/workshops/ches/ches2003/presentations/SatohMorioka_2003.pdf

<May 2010>


doc.: IEEE 802.15-10-0273-01-0006

Submission

For More Detail …• Please see the Camellia website

http://info.isl.ntt.co.jp/crypt/eng/camellia/– Introduction handout– Specifications– Technical Information– Open Source codes– Test Vectors

• Also see Cryptographic Hardware Project websitehttp://www.aoki.ecei.tohoku.ac.jp/crypto/web/cores.html

– Camellia sample hardware core exists

<May 2010>


doc.: IEEE 802.15-10-0273-01-0006

Submission

Endorsement – Open Evaluation Activity• AES project sponsored by USA

– US standard encryption “AES” was produced after an open call and four-year evaluation using a transparent and open process through industry-academic-government collaboration

– One winner “Rijndael” was selected from 15 submission algorithms

• CRYPTREC activity sponsored by Japan– “The e-Government Recommended Ciphers List” for Japanese

government systems was produced after an open call and three-year evaluation through industry-academic-government collaboration

– “Camellia” has been confirmed to be secure

• NESSIE project sponsored by European Commission– “The NESSIE portfolio of strong cryptographic primitives” was

produced after an open call and three-year evaluation using a transparent and open process through industry-academic-government collaboration

– Only “Camellia” was selected from 10 submission algorithms

– “AES” was added by NESSIE secretariat

<May 2010>


doc.: IEEE 802.15-10-0273-01-0006

Submission

Security Evaluation Results by CRYPTREC• No major defect is reported for Camellia

– Despite many analysis of security, Camellia is still secure against known attacks– Related key attack is not reported, though the same attack is reported for AES

• Secure against current known attacks– Linear cryptanalysis– Differential cryptanalysis– Truncated linear cryptanalysis– Truncated differential cryptanalysis– Higher order differential cryptanalysis– Impossible differential cryptanalysis– Interporation Cryptanalysis– Linear sum cryptanalysis– Slide cryptanalysis

• Timing attack on cache memory is reported.However, this is NOT issue of the algorithm and fixed by other implementation techniques

<May 2010>


doc.: IEEE 802.15-10-0273-01-0006

Submission

<May 2010>


Slide 23

Organization Years Standard

ISO/IEC JTC1 2005 18033-3 (Block Cipher)

ITU-T 2010 Y.2704 (NGN)

NESSIE 2003 European Recommendation

CRYPTREC 2003 e-Government Recommended Ciphers List

IETF 2004 RFC 3657 (S/MIME)

2005 RFC 4051 (XML)RFC 4132 (SSL)RFC 4312 (IPsec)

2009 RFC 5528 (CTR, CCM)RFC 5529 CTR,CCM for IPsecRFC 5581 (PGP)

RSA Lab. 2006 PKCS #11

TV-Anytime Forum 2003 Bi-directional Metadata Delivery Protection

2004 TV-Anytime Rights Management and Protection Information for Broadcast Applications

Status on Standardization of Camellia

doc.: IEEE 802.15-10-0273-01-0006

Submission

<May 2010>


Slide 24

Organization Standard Status

IETF tls-rfc4132bis (TLS) Finalizing

ipsec-camellia-cmac96and128 (CMAC in IPsec) In discussion

ipsec-camellia-gcm (GCM in IPsec) In discussion

tls-camellia-ecc-sha (ECC and SHA-2 in TLS) In discussion

tls-camellia-psk (PSK in TLS) In discussion

tls-camellia-gcm (GCM in TLS) In discussion

srtp-camellia (SRTP) In discussion

krb-wg-kanno-camellia (Kerberos 5) In discussion

keyprov-pskc (PSKC) In discussion

smime-cms-rsa-kem (RSA-KEM in S/MIME) Finalizing

RSA Lab. GCM in PKCS #11 In discussion

W3C XML Security (Encryption) In discussion

XML Security （ Cross-Reference) In discussion

Status on Standardization of Camellia (Ongoing)

doc.: ieee 802.15-10-0273-01-0006 submission slide 1 project: ieee p802.15 working group for...

Documents