1 / 24

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]

shira
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Generalizaed secure services to accommodate cryptos] Date Submitted: [15May, 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:[ma-kanda@ipa.go.jp, smatsuo@nict.go.jp, marsh@nict.go.jp, grace.sung@nict.go.jp, kohno@nict.go.jp, fukunaga.toshinori@lab.ntt.co.jp] 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>

  2. Generalized secure services to accommodate cryptos Masayuki Kanda [IPA] Shin’ichiro Matsuo, Masahiro Kuroda, Grace Sung, Ryuji Kohno [NICT] Toshinori Fukunaga [NTT] <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  3. 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 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  4. Addition of Security services using Camellia cipher • 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 < Ref > SP800-38B CMAC Generation <Ref> SP800-38C CCM Generation-Encryption Process <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  5. Addition of Security services using Camellia cipher Unencrypted Frame Payload Encrypted Frame Payload Counter (Unencrypted) • Implementation outline for CCM B0 B1 B2 B3 Bm MIC B1 B2 B3 Bm CIPHK ctr0 CIPHK CIPHK ctr1 CIPHK ctr2 CIPHK CIPHK ctr3 CCM Process (Independence of ciphers) CIPHK CIPHK CIPHK ctrm CIPHK message security protocol is “0” message security protocol is “1” Cipher is selected, depending on the message security protocol fieldin the Security_suite_selector (Ref: in 6.3.2.3.4 Table 7) Cipher (CIPHK) AES Camellia Key (K) AES-CCM Camellia-CCM <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  6. 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 Example: Using AES-CMAC Using Camellia-CMAC (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-CCM Using Camellia-CCM (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. <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  7. 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 Proposal - Generalized version Using CMAC (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 CCM (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. <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  8. Amendments of Security association frames • Frame payload format for security disassociation frames are revised to add security suit selector • 8.1.6 Disassociation (Proposal) (TG6 Draft rev.4) Octets: 6 6 16 8 Octets: 6 6 2 16 8 Octet order: 0-5 0-5 0-15 0-7 Octet order: 0-5 0-5 0-1 0-15 0-7 Recipient Address Sender Address Sender Nonce DA_KMAC Recipient Address Sender Address Security Suite Selector Sender Nonce DA_KMAC (TG6 Draft rev.4) (Proposal) 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 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) <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  9. 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. <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  10. Other points – Editorial Comments (Correction) (TG6 Draft rev.4) • 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 6 6 1 1 72 6 6 2 1 72 0-5 0-5 0 0 L-R 0-5 0-5 0 L-R 0-1 Recipient Address Sender Address Security Suite Selector Association Sequence Number Security Association Data Recipient Address Sender Address Security Suite Selector Association Sequence Number Security Association Data <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  11. 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 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  12. Proposal on Selection Criteria for Cipher Suites • Security Selected algorithms must be resistant to cryptanalytic attacks • Performance on a variety of typical platforms This includes time and space efficiency on both software and hardware • Endorsement The nature of any evaluations is also of great importance, especially those conducted by widely recognized evaluation organizations and cryptographic community • Number of ciphers The number of ciphers to be standardized should be as small as possible Two conditions to this principle exist • Selected algorithms should be selected as standard or recommendation by various well-known organizations and region in the world • 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 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  13. 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 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  14. 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) (2009.9 at the present time) Ｂｒｅａｋ <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  15. 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 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  16. 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 (128-bit key ASIC) 2728Mbps/20.0KGs 1908Mbps/20.8KGs 2155Mbps/29.8KGs 2024Mbps/13.2KGs 1881Mbps/44.3KGs 1051Mbps/11.9KGs 1422Mbps/31.1KGs 971.2Mbps/7.8KGs 325.8Mbps/6.5KGs 969.7Mbps/14.2KGs 204.6Mbps/6.3KGs 567.3Mbps/9.1KGs 71.6Mbps/6.4KGs <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  17. 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 Specification available from Camellia website <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  18. Performance and Flexibility • Comparison between AES and Camellia (by Satoh, et al.) <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  19. 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 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  20. 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 website http://www.aoki.ecei.tohoku.ac.jp/crypto/web/cores.html • Camellia sample hardware core exists <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  21. 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 processthrough industry-academic-government collaboration • Only “Camellia” was selected from 10 submission algorithms • “AES” was added by NESSIE secretariat <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  22. 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 <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  23. Status on Standardization of Camellia <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

  24. Status on Standardization of Camellia (Ongoing) <M. Kanda, S.Matsuo, M. Kuroda. G. Sung, R.Kohno, T. Fukunaga>

More Related