IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: On padding method of AES-CBC Date Submitted: January, 17th, 2013 Presented at IEEE session #55 in Orland Authors or Source(s): Yoshikazu Hanatani, Toru Kambayashi (Toshiba) Abstract: This is a material to discuss that m should specify a padding method of AES-CBC or not

IEEE presentation release statements This document has been prepared to assist the IEEE Working Group. 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. 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 The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual and in Understanding Patent Issues During IEEE Standards Development Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3 IEEE presentation release statements This document has been prepared to assist the IEEE Working Group. 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. 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 The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws and in Understanding Patent Issues During IEEE Standards Development Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6-7.html#

AES-CBC AES Enc P1P1 P2P2 P3P3 C1C1 C2C2 C3C3 A length of plaintext must be a multiple of 16 octets. If a plaintext is not a multiple of 16 octets, we cannot encrypt the plaintext without a padding method. IV

Plaintext Various Padding Method ZeroByte padding PKCS#5 padding (RFC1423) ISO10126 padding SSL3 padding Sender and Receiver need to share a padding method, but the padding method is not secret information. Padding Ciphertext Plaintext Padding Decryption using a symmetric key Remove padding part

Padding methods in IEEE a AES-CCM CCM mode provides a padding method. AES-CBC CBC mode in 21a does not clearly specify a padding method : Encapsulation “b) Pad the plaintext, P, to a length of a multiple of 16 octets (128 bits) so that the padded plaintext can be represented as in n blocks P0, P1,.., Pn-1, each of which is 16 octets.” “d) … Here padding may be needed to make the input message length to be a multiple 64 octets (512 bits). The most significant 12 octets of the output of HMAC-SHA1 is the MIC.” : Decapsulation “c) …Here padding may be needed to make the input message length a multiple 64 octets (512 bits)….” “e) Remove the padding if it is applied to obtain the plaintext, P.” Should we specify a padding method for AES-CBC?

On Reply attack resistance AES-CCM in IEEE a An initial vector (IV) is generated from a sequence number of SA and a part of MIH header. We can prevent a reply attack by checking the sequence number. AES-CBC in IEEE a The IV is randomly chosen. (Sec ) To prevent a reply attack, MN should hold all used IVs, and check them Can we achieve the reply attack resistance using AES-CBC? Some textbook denotes “CBC-mode is insecure if IVs are a constant number or counter numbers.”

Typo? ASCII code in “9.2.2 Key derivation and key hierarchy” is failed. ASCII code of “MISK” is described as “0x4D495354”, but it should be “0x4D49534B”