1. 해쉬함수(Hash functions)

해쉬함수의 성질

v 해쉬함수:�임의의 비트열을 고정된 짧은 길이로 변환하여 출력하는 알고리즘

Ø Cryptographic�Hash�function�=�Hash�function�+�Cryptographic�properties

101010101010101010101010101010110101010101010010101010101101001001001001010101110100010101110100100001001011100010010001000101101001010111010001010100010100010100101010101010101010101010000000000011111110110101011010101010101010010110101010101010101111110000101010101010100101010101010011101010100110101010101010101010101010101010101010101010010111100001110101110000111010001100011110011101010110101010101010101011001010001010101000010001010111000101110010100000101001110010101010101011101010101010101010101010101010110101010101010010101010101101001001001001010101110100010101110100100001001011100010010001000101101001010111010001010100010100010100101010101010101010101010000000000011111110110101011010101010101010010110101010101010101111110000101010101010100101010101010011101010100110101010101010101010101010101010101010101010010111100001110101110000111010001100011110011101010110101010101010101011001010001010101000010001010111000101110010100000101001110010101010101011101010101010101010101010101010110101010101010010101010101101001001001001010101110100010101110100100001001011100010010001000101101001010111010001010100010100010100101010101010101010101010000000000011111110110101011010101010101010010110101010101010101111110000101010101010100101010101010011101010100110101010101010101010101010101010101010101010010111100001110101110000111010001100011110011101010110101010101010101011001010001010101000010001010111000101110010100000101001110010101010101011101010101010101010101010101010110101010101010010101010101101001001001001010101110100010101110100100001001011100010010001000101101001010111010001010100010100010100101010101010101010101010000000000011111110110101011010101010101010010110101010101010101111110000101010101010100101010101010011101010100110101010101010101010101010101010101010101010010111100001110101110000111010001100011110011101010110101010101010101011001010001010101000010001010111000101110010100000101001110010101010101011···················01010101010101010101010101011010101010101001010101011010101011101110110101010101010010101010101010111

1101000101010001010001010010101010101010101010101000000000001111111011

HAS-160, SHA-1 의경우 160 비트출력

해쉬함수의 안전성 목표

v 역상 저항성(one-wayness)

Ø 임의의 z가 주어질 때,�H(x)=z�인 x�를 찾는 것이 어려워야 함

v 제2역상 저항성(2nd preimage�resistance)

Ø 임의의 x가 주어질 때,�H(y)=H(x)�인 y�(≠�x)를 찾는 것이 어려워야 함

v 충돌 저항성(collision�resistance)

Ø H(x)=H�(y)인 x,�y�(x�≠�y)를 찾는 것이 어려워야 함

v 안전성 성질 사이의 관계

Ø 충돌 저항성 ⇒�제2역상 저항성

Ø 충돌 저항성이 역상 저항성을 함축하는 것은 아님

충돌쌍 공격: 생일 역설

충돌쌍 공격: 생일 역설

v

안전성 목표치

Hash�type Design�goal Ideal Str. Adv. goal

OWHF 역상 저항성제2 역상 저항성

2n 역상 출력제2 역상 출력

CRHF 충돌 저항성 2n/2 충돌쌍 출력

해쉬함수 응용

v 데이터 무결성 체크

v 전자서명:�신원 확인 또는 거래를 증명할 때 주민등록증,�인감,��서명 등이 필요

하듯 전자거래에서 신원을 확인해 주는 증명 수단

v 메시지 인증 (HMAC)

v 난수열 생성

v 키 생성:�마스터키에서 세션키 유도

v APOP�(email�protocol)�:�패스워드 공유

원본

=?0101010101010100000001 0101010101110100100000

해쉬

변조

해쉬

Nonce

Hash(Nonce||Pwd)

ServerClient

일반적인 해쉬함수 구성 방식

v MD(Merkle-Damgard)�방식

Ø 1989년 Crypto에서 Merkle과 Damgard에 의해 제안됨

Ø 고정된 입출력 크기를 갖는 함수를 이용하여 임의의 길이의 입력값을다루는 해쉬 함수를 구성하는 방법

Ø 고정된 입출력 크기를 갖는 함수 :�압축함수(Compression�function)

f f fh0 hl

m1 m2 ml

일반적인 해쉬함수 구성 방식

Arbitrary length input (padded)

Iteratedcompression

functionFixed length outputOptional

transformation

Output

일반적인 해쉬함수 구성 방식

Append padding bits

Append length block

ƒ

g

hih0=IV

mi

Preprocessing

hthi-1

Original input x

Formattedinput m1, m2... mt Iterated

processingCompressionfunction f

Output H(m)=g(ht)

MD 방식의 주요 성질

v 압축 함수가 충돌 저항성을 가지면,�MD�방식으로 구성된 해쉬 함수도 충돌 저항성을 가짐 (단,�적절한 패딩을 사용해야 함)

v 압축 함수가 역상 저항성을 가지면,�MD�방식으로 구성된 해쉬 함수도 역상 저항성을 가짐

v MD-strengthening (for�SHA-1)

Ø 일반적으로 메시지 맨 끝에 (반드시)�1을 붙인 후,�0을 계속 연접하여,�전체 블록이 압축 함수의 메시지 블록 길이의 배수 ­ 64 가 되도록 함

Ø 64 비트는 메시지의 길이로 채움 (따라서, SHA-1은 264-1 비트 메시지까지만 압축할 수 있음.)

압축함수 설계 방식

v 압축 함수만 설계하면,�MD�방식으로 해쉬함수를 구성할 수 있음

Ø 원점에서부터 설계하는 방식과 기존의 블록암호를 사용하는 방식

Ø 전자의 경우도,�일정한 블록암호 논리를 사용하여 설계함

v 블록암호 사용시 유리한 점

Ø 잘 알려진 블록암호에 기반하므로, 이에 맞먹는 안전성을 확보할 수 있음

Ø 압축함수 설계를 따로 할 필요가 없음

Ø 블록암호,�해쉬함수를 동시에 사용하는 환경에서,�블록암호만 구현하면 됨

Ø 단,�전용 해쉬함수(dedicated�hash�function)에 비해 속도가 낮음

v 70년대말~90년대초:�DES�사용

Ø 블록 사이즈가 작고(64비트),�취약키들이 발견되어 압축함수 구성에 방해요소

v 현재:�AES�사용

Ø 128�비트 블록사이즈 +�취약키가 발견되지 않았음

블록암호 기반 압축함수

v 대표적인 블록암호 기반 SBL-압축함수 설계방식

Eghi-1

hi

mi

E

hi-1

hi

miEg

hi

mi

hi-1

Matyas-Meyer-Oseas Davis-Meyer Miyaguchi-Preneel

블록암호 기반 압축함수

v 1993년에 Preneel,�Govaerts,�Vandewalle�이 단순한 연산과 wiring�으로 이루어진 모든 SBL-압축함수를 분류하고(64종),�안전성을 분석하였음

v 이들 가운데 12개 압축함수가 안전성이 증명됨 (Black�etc.,�2002)

압축함수 설계 방식

v 블록암호 출력 크기 n에 대해,�압축함수(해쉬함수)�출력크기가

Ø n�인 경우,�SBL(single�block�length)-압축함수

Ø 2n�인 경우,�DBL(double�block�length)-압축함수

v n�비트의 충돌저항성이 요구될 경우,�출력 사이즈는 2n�비트로 설계해야 함

Ø Birthday�공격 때문

Ø 대표적인 DBL�압축 함수

§ MDC-2,�MDC-4�(block�cipher�/w�n-bit�keys)

§ Tandem-DM,�Abreast-DM�(block�cipher�/w�2n-bit�keys)

vMD4

Ø R.Rivest 설계(1990):�128�비트 출력

Ø MD5,�SHA�해쉬함수 등에 영향을 줌

Ø 효율적인 충돌쌍 공격이 발견됨:�더 이상 사용 불가

vMD5

Ø R.Rivest 설계(1992):�128�비트 출력

Ø 실제 공격(인증서 위조)에 적용 가능한 충돌쌍 공격이 발견됨 (Crypto�‘09)

v RIPEMD

Ø 벨기에 Cosic 그룹(H.Dobbertin 등)에서 설계(1996):�160�비트 출력

Ø 128,�256,320�비트 출력 버전도 있음

Ø 최초 버전은 충돌쌍 공격에 취약하나,�수정안에는 적용되지 않음

Ø MD,�SHA�계열 함수만큼 널리 사용되지 않아서 분석 연구 결과도 적음

전용 해쉬함수 (dedicated hash functions)

v SHA-0,1

Ø NIST에 의해 1993년 표준으로 발표된 후(SHA-0),�1995년 개정됨(SHA-1)

§ NSA에서 SHA-0�의 안전성을 강화하기 위해 개정 (취약성은 발표 안함)

§ 메시지 스케쥴에서 1�비트 회전 변환 추가

Ø 2005년 Wang�등에 의해 충돌쌍 공격이 제안됨

v SHA-2

Ø 2001년 NIST는 4종의 해쉬함수를 추가로 발표함 (2002년 표준화)

Ø 출력크기에 따라,�SHA-224,�SHA-256,�SHA-384,�SHA-512�으로명명 (통칭하여 SHA-2�라 불림)

Ø SHA-1�만큼 널리 사용되지는 않음

전용 해쉬함수 (dedicated hash functions)

SHA 해쉬함수 취약성 & SHA-3 공모사업v 2004년 Crypto�Rump�Session에서 Wang�교수팀은 MD4,�MD5,�RIPEMD,�HAVAL,�SHA-0에 대한 충돌쌍 제시.�

v 2005년 Eurocrypt,�Crypto에서 SHA-1�등을 포함한 해쉬함수에 대한분석방법 제시.

v 점차 실용적인 단계의 공격으로 진화함에 따라 NIST는 새로운 표준 해쉬함수 공모사업을 시작.

SHA-1 충돌쌍Table 1: Colliding message blocks for SHA-1.

CV0 4e a9 62 69 7c 87 6e 26 74 d1 07 f0 fe c6 79 84 14 f5 bf 45

M (1)1 7f 46 dc 93 a6 b6 7e 01 3b 02 9a aa 1d b2 56 0b

45 ca 67 d6 88 c7 f8 4b 8c 4c 79 1f e0 2b 3d f614 f8 6d b1 69 09 01 c5 6b 45 c1 53 0a fe df b760 38 e9 72 72 2f e7 ad 72 8f 0e 49 04 e0 46 c2

CV (1)1 8d 64 d6 17 ff ed 53 52 eb c8 59 15 5e c7 eb 34 f3 8a 5a 7b

M (1)2 30 57 0f e9 d4 13 98 ab e1 2e f5 bc 94 2b e3 35

42 a4 80 2d 98 b5 d7 0f 2a 33 2e c3 7f ac 35 14e7 4d dc 0f 2c c1 a8 74 cd 0c 78 30 5a 21 56 6461 30 97 89 60 6b d0 bf 3f 98 cd a8 04 46 29 a1

CV2 1e ac b2 5e d5 97 0d 10 f1 73 69 63 57 71 bc 3a 17 b4 8a c5

CV0 4e a9 62 69 7c 87 6e 26 74 d1 07 f0 fe c6 79 84 14 f5 bf 45

M (2)1 73 46 dc 91 66 b6 7e 11 8f 02 9a b6 21 b2 56 0f

f9 ca 67 cc a8 c7 f8 5b a8 4c 79 03 0c 2b 3d e218 f8 6d b3 a9 09 01 d5 df 45 c1 4f 26 fe df b3dc 38 e9 6a c2 2f e7 bd 72 8f 0e 45 bc e0 46 d2

CV (2)1 8d 64 c8 21 ff ed 52 e2 eb c8 59 15 5e c7 eb 36 73 8a 5a 7b

M (2)2 3c 57 0f eb 14 13 98 bb 55 2e f5 a0 a8 2b e3 31

fe a4 80 37 b8 b5 d7 1f 0e 33 2e df 93 ac 35 00eb 4d dc 0d ec c1 a8 64 79 0c 78 2c 76 21 56 60dd 30 97 91 d0 6b d0 af 3f 98 cd a4 bc 46 29 b1

CV2 1e ac b2 5e d5 97 0d 10 f1 73 69 63 57 71 bc 3a 17 b4 8a c5

2 Our contributions

We are the first to exhibit an example collision for SHA-1, presented in Table 1, therebyproving that theoretical attacks on SHA-1 have now become practical. Our work buildsupon the best known theoretical collision attack [36] with estimated cost of 261 SHA-1calls. This is an identical-prefix collision attack, where a given prefix P is extended withtwo distinct near-collision block pairs such that they collide for any su�x S:

SHA-1�P ��M (1)1 ��M (1)

2 ��S� = SHA-1�P ��M (2)1 ��M (2)

2 ��S� .The computational e↵ort spent on our attack is estimated to be equivalent to 263.1

SHA-1 calls (see Section 6). There is certainly a gap between the theoretical attack aspresented in [36] and our executed practical attack that was based on it. Indeed, thetheoretical attack’s estimated complexity does not include the inherent relative loss ine�ciency when using GPUs, nor the ine�ciency we encountered in actually launching alarge scale computation distributed over several data centers. Moreover, the construction ofthe second near-collision attack was significantly more complicated than could be expectedfrom the literature.

To find the first near-collision block pair (M (1)1 ,M

(2)1 ) we employed the open-source

code from [36], which was modified to work with our prefix P given in Table 2 and forlarge scale distribution over several data centers. To find the second near-collision block

pair (M (1)2 ,M

(2)2 ) that finishes the collision was significantly harder, as the attack cost is

known to be significantly higher, but also because of additional obstacles.

1 E.g., SHA-1 certificates are still being sold by CloudFlare at the time of writing: https://www.cloudflare.com/ssl/dedicated-certificates/

3

Table 2: Identical prefix of our collision.

25 50 44 46 2d 31 2e 33 0a 25 e2 e3 cf d3 0a 0a %PDF-1.3.%......0a 31 20 30 20 6f 62 6a 0a 3c 3c 2f 57 69 64 74 .1 0 obj.<</Widt68 20 32 20 30 20 52 2f 48 65 69 67 68 74 20 33 h 2 0 R/Height 320 30 20 52 2f 54 79 70 65 20 34 20 30 20 52 2f 0 R/Type 4 0 R/53 75 62 74 79 70 65 20 35 20 30 20 52 2f 46 69 Subtype 5 0 R/Fi6c 74 65 72 20 36 20 30 20 52 2f 43 6f 6c 6f 72 lter 6 0 R/Color53 70 61 63 65 20 37 20 30 20 52 2f 4c 65 6e 67 Space 7 0 R/Leng74 68 20 38 20 30 20 52 2f 42 69 74 73 50 65 72 th 8 0 R/BitsPer43 6f 6d 70 6f 6e 65 6e 74 20 38 3e 3e 0a 73 74 Component 8>>.st72 65 61 6d 0a ff d8 ff fe 00 24 53 48 41 2d 31 ream......$SHA-120 69 73 20 64 65 61 64 21 21 21 21 21 85 2f ec is dead!!!!!./.09 23 39 75 9c 39 b1 a1 c6 3c 4c 97 e1 ff fe 01 .#9u.9...<L.....

In Section 5 we will discuss in particular the process of building the second near-collisionattack. Essentially we followed the same steps as was done for the first near-collision attack[36], combining many existing cryptanalytic techniques. Yet we further employed the SHA-1collision search GPU framework from Karpman et al. [18] to achieve a significantly morecost e�cient attack.

We also describe two new additional techniques used in the construction of the secondnear-collision attack. The first allowed us to use additional di↵erential paths around step23 for increased success probability and more degrees of freedom without compromising theuse of an early-stop technique. The second was necessary to overcome a serious problem ofan unsolvable strongly over-defined system of equations over the first few steps of SHA-1’scompression function that threatened the feasibility of finishing this project.

Our example colliding files only di↵er in two successive random-looking messageblocks generated by our attack. We exploit these limited di↵erences to craft two collidingPDF documents containing arbitrary distinct images. Examples can be downloaded fromhttps://shattered.io; another smaller example is given in Section B.1. PDFs with thesame MD5 hash have previously been constructed by Gebhardt et al. [12] by exploitingso-called Indexed Color Tables and Color Transformation functions. However, this methodis not e↵ective for many common PDF viewers that lack support for these functionalities.Our PDFs rely on distinct parsings of JPEG images, similar to Gebhardt et al.’s TIFFtechnique [12] and Albertini et al.’s JPEG technique [1]. Yet we improved upon these basictechniques using very low-level “wizard” JPEG features such that these work in all commonPDF viewers, and even allow very large JPEGs that can be used to craft multi-page PDFs.

Some details of our work will be made public later only when su�cient time to implementadditional security measures has passed. This includes our improved JPEG technique andthe source-code for our attack and cryptanalytic tools.

The remainder of this paper is organized as follows. We first give a brief descriptionof SHA-1 in Section 3. Then in Section 4 we give a high-level overview of our attack,followed by Section 5 that details the entire process and the cryptanalytic techniquesemployed, where we also highlight improvements with respect to previous work. Finally,we discuss in Section 6 the large-scale distributed computations required to find the twonear-collision block pairs. The parameters used to find the second colliding block are givenin the appendix, in Section A.

3 The SHA-1 hash function

We provide a brief description of SHA-1 as defined by NIST [27]. SHA-1 takes an arbitrary-length message and computes a 160-bit hash. It divides the (padded) input message into k

4

v 2017년, M.�Stevens�등이 SHA-1�충돌쌍 제시

v 263.1 해쉬계산량 / 100,000�USD�소요

SHA-1(P||M1(1)||M2

(1))=SHA-1(P||M1(2)||M2

(2)).

Prefix P

v 2012년 KECCAK(G.�Bertoni,�J.�Daemen,�M.�Peeters,�G.�V.�

Assche.)이 최종 선정되고, 2015년 SHA-3로 표준화.

0

0f

p0 p1 z0 z1absorbing squeezing

r

c…

pi

f f f f …

SHA 해쉬함수 취약성 & SHA-3 공모사업

SHA-0/1 해쉬함수: 작동 방식v Merkle-Damgard�방식 기반

Ø 메시지 블록 mj :�512�비트

Ø 연쇄 변수 Hj:�160�비트

Ø 출력 해쉬값 h(m):�160비트

v 패딩 적용 (MD-strengthening:�Pad(M)=M||10*||Length�as�64�bits)

SHA-0/1 압축함수 (Optional)

SHA-0/1 압축함수 (Optional)

SHA-0/1 압축함수 (Optional)

SHA-0/1 압축함수 (Optional)

SHA-0/1 압축함수 (Optional)

SHA-0/1 압축함수: step 변환 (Optional)

SHA-0/1 압축함수: step 변환 (Optional)v 부울함수 f ,�상수 Ki는 매 20�step�마다 변경됨

Ki= 0x5a827999Ki= 0x6ed6eba1Ki= 0x8fabbcdcKi= 0xca62c1d2

Merkle-Damgard 이후v 기존 해쉬함수 설계는

Ø 전용 압축함수(dedicated�compression�function),�또는

Ø 블록암호 기반 압축함수(block cipher-based�compression�function)

를 설계한 뒤,�이를 MD�모드에 적용하는 방식

v 이후MD�설계 방식에 대한 구조적인 취약성이 드러나기 시작함

Ø Joux’s�multicollision�attack�(Crypto�2004)

Ø Long-message�second�preimage�attack�(Eurocrypt�2005)

Ø Herding�attack (Eurocrypt�2006)

v 새로운 형태의 해쉬 운용모드가 다양하게 제안되고 있음

Ø Ex)�블록암호의 키를 고정해서 쓰는 방식(random�permutation�model)

§ 키스케줄링 비용을 절감

§ 블록암호의 연관키 공격에 대한 취약점 해소

Sponge Construction

Ø 고정키 블록암호(또는 random�permutation)에 기반한 최초의 구성

방식

Ø Indifferentiability�framework�에서 안전성이 증명됨

§ G.�Bertoni,�“On�the�indifferentiability�of�the�Sponge�

construction”�(Eurocrypt�08)

§ Sponge-type�해쉬함수:�RadioGatun(2006),�Grindahl�

(2007),�KECCAK(2008)

2. 메시지 인증 코드(MAC)

MAC 이란?v Message�Authentication�Code

Ø 메시지를 인증하기 위해 첨부하는 짧은 태그

Ø “무결성” 및 “인증”을 동시에 제공하기 위한 것임

Ø 반드시 송수신자의 비밀키가 포함되며,�(비밀키 없이 계산되는)�CRC�등과는 근본적으로 다름

Ø 특정 비밀키를 공유하고 있는 사용자들끼리 주고받는 메시지의 무결성을 확인하기 위한 수단

위조 변조

MAC 의 안전성 목표v 무결성 확보(Integrity)

Ø 공격자의 의도적인 공격에 의한 데이터의 위조/변조를 확인할 수 있어야 함

v 인증(Authentication)

Ø 메시지를 보낸 상대방의 신원을 확인할 수 있어야 함

v 참고)�부인봉쇄 (Non-repudiation)�기능은 제공하지 않음

Ø 송수신자가 보낸/받은 데이터에 대하여 부인할 수 없도록 하는 것

§ 송신자:�“나는 그런 말 한적 없다!”

§ 수신자:�“나는 그런 말 들은 적 없다!”

Ø “본인만이” 생성할 수 있으며 “제3자”가 그것을 확인할 수 있는 “전자 서명”등의 기법이 필요함

위조 변조

일반적인 MAC 작동 방식v 송신자는MAC을 계산하여 메시지에 덧붙여서 전송

Ø 메시지에 덧붙이는 것을 Tag�라고 부름

v 수신자는MAC을 재계산하고,�수신한 MAC과 비교하여 검증함

M

M

T

SenderM’

A KK

M’

T’MAC MAC 0 or 1

Receiver

=T *

= ?

KK

일반적인 MAC 작동 방식

≠

K K

Forger의 시도

MAC에 대한 공격목표

v 비밀키를 모르는 사람이,�송수신자가MAC을 생성하지 않았던 메시지에

대하여,�유효한MAC을 생성해내는 것

Ø MAC의 위조 공격

v MAC은 위조 공격에 대하여 안전하도록 설계되어야 함

MAC의 안전성 요소

v 키의 크기

Ø 키에 대한 전수조사 가능 ⇒ 키의 크기를 원하는 안전성 이상 되도록 선택

v Tag의 크기

Ø MAC:{0,1}*´ {0,1}kà {0,1}t

Ø Tag의 크기가 t�비트라면,�임의의 메시지에 대해 tag를 랜덤하게 선택하

는 경우,�tag가 정확한 MAC이 될 확률이 2-t이 됨

v Tag�를 랜덤하게 선택할 때 성공할 확률은,�MAC�키와 전혀 상관없으므로,�

MAC�키를 교체하는 것은 tag�위조 공격을 막지 못함

MAC vs. Hashv 해쉬함수

Ø 메시지에 대해 일정 길이의 “Fingerprint”�생성

Ø 키 사용 없음

Ø 일방향성,�충돌 저항성 요구

Ø CRC�와 같은 무결성 체크(error�체크)

Ø 전자서명에 사용

Ø 예)�MD5,�SHA1,�SHA2,�HAS160

v MAC

Ø 비밀키 사용

Ø 메시지 무결성(Integrity)�제공

Ø 수신자와 송신자만 MAC을 생성,�검증할수 있음

Ø 예)�HMAC,�CBC-MAC,�OMAC,�XCBC

Message HashHash Algorithm

MAC

SEND

MACMAC Algorithm

Shared Secret Key

블록 암호 기반 MAC: CBC-MACv 가장 대표적인 블록암호 기반MAC

M1 M2 M3 Checksum

+ ++

C1 C2 C3 C4

+IV

M2 M3 M4M1

Tag

CBC-MAC 은 안전한가?

v 답:�그때 그때 다르다!

v 일반적인 경우,�MAC�위조 가능

Ø M1:�query�è T1:�tag

Ø (M2ÅT):�query�è T2:�tag

Ø 그러면,�(M1||M2)에 대한 tag는 T2가 되어,�새로운 (메시지,�MAC) 쌍

을 얻을 수 있음

v 특별한 경우

Ø 조건1:�사용된 블록암호가 안전함 (pseudorandom�permutation�가정)

Ø 조건2:�MAC의 대상이 되는 모든 메시지의 길이가 고정됨

Ø 그러면,�CBC-MAC은 안전하다고 증명됨

CMAC (Cipher-based MAC)

v CBC-MAC의 단점을 해소하고자 Black,�Rogaway�가 XCBC�제안(2000)

Ø 키가 3개 필요함

v XCBC를 개선하여 Iwata,�Kurosawa�가 OMAC�제안(2003)

v 약간 수정된 OMAC1이 NIST의 Special�Publication�800-38B의 권고

안에 포함됨 (이후 CMAC�이라 불림)

v 특징

Ø 메시지의 크기가 블록의 배수가 아니더라도 가능함

Ø 원래 CBC-MAC을 약간 변형한 것임

Ø 실제로 필요한 키의 개수가 1개임

Ø 증명가능한 안전성 제공

XCBC (Black, Rogaway)

M1 M2 M3 M4

+ ++

Tag

K2

If last block full

M1 M2 M3 M410*

+ ++

Tag

K3

If last block partial

OMAC (Iwata, Kurosawa)

M1 M2 M3 M4

+ ++

Tag

2L

If last block full

M1 M2 M3 M410*

+ ++

Tag

4L

If last block partial

L = EK (0n)2L = msb(L)? L<<1 Å 0x87 :

L<<14L = 2(2L)

A trick to let youinstantiate with a single key

해쉬함수 기반 MAC

v 해쉬함수 기반MAC

Ø 잘 알려진 해쉬함수 구현을 이용해서 메시지 인증을 하려는 시도들이 있었음

Ø 가장 간단한 예:�Mk(x)�=�H(k�||�x)

Ø H가 random�oracle이면 위의 방식은 안전함

Ø H가 Merkle-Damgard�해쉬함수면,�위의 방식은 위조 공격에 취약함

§ 메시지 확장 공격이 가능

§ H(k�||�x)를 query한 공격자는 k를 모르더라도 H(k�||�x�||�b)를 계산할 수

있음

HMAC: Keyed-Hash MACv 해쉬함수기반 MAC으로, Bellare 등에의해제안됨v 해쉬함수기반 MAC의사실상표준v Merkle-Damgard 해쉬함수의확장공격을막을수있도록설계됨

Ø 해쉬값을그냥출력하지않고, 한번다시압축함수를통과시켜출력⇒연결을끊어서확장공격봉쇄

n-bit

…

K0⊕ipad

IV

M1 M1 Mt

K0 ⊕ opad

IV

b-bit

n-bit

b-bit

n-bit

b-bit

n-bit

b-bit

n-bit

b-bit b-bit

n-bit

padding

n-bit

f f f f

f f

HMAC: Keyed-Hash MAC

K

|K| £ B

K0 = ||ZerosK

|K| > B K0 Å ipad Text

K0 Å opad

Hash Algorithm

Hash1

K0

Hash2

Hash Algorithm

Text

ØB : Block size of Hash functionK0 is B bytes (b=8B)

Ø ipad : 0x36 repeated B timesØ opad : 0x5C repeated B times

MAC = H(K0Å opad || H( K0Å ipad || Text ) )

K0 = H(K) ||Zeros

MAC

HMAC의 특징

Ø 기존에 이미 사용되어온 MD5,�SHA-1�등의 Merkle-Damgard�해쉬함수를blackbox로 이용하여 구현 가능 (즉,�기존 소스 코드 수정 불필요)

Ø Merkle-Damgard�해쉬함수의 메시지 확장 성질을 MAC�레벨에서 봉쇄

Ø 안전성 증명 가능

§ 압축 함수가 PRF이고,�그 외에 사소한 성질을 더 만족하면 HMAC�역시PRF

Ø 이같은 설계 원칙 안에서 최선의 효율성을 유지하나, 짧은 메시지에 대해서는 H(k�||�x)�방식보다 2배까지도 느려짐

3. 인증 제공 암호화(Authenticated Encryption)

Why Authenticated Encryption (AE) ?

v 인증 제공은 필수적

Ø 최근 인증을 기밀성만큼 중요시하는 분위기

Ø (방안 1)�암호 운용모드 +�인증 제공 운용모드

§ 기존 기밀성 제공 운용모드에 MAC�결합

§ 어떻게 결합할 것인가가 문제

§ 안전성과 효율성을 고려하여 설계

v 효율성 증대

Ø 기밀성과 인증을 분리해서 다루지 말고 동시에 처리하는 것이 훨씬 효율적이지 않을까?

Ø (방안 2)�기밀성/인증 동시 제공

§ MAC�값을 동시에 출력하는 블록암호 운용모드(OCB�등)

§ 메시지 암호화와 동시에 MAC�값을 계산하는 스트림암호 (Phelix�등)

방안 1) 기밀성과 인증의 순차적 결합

Enc-and-MAC

Enc-then-MAC

MAC-then-Enc

3가지 방식의 안전성 및 효율성v Encrypt-then-MAC�(EtM)

Ø IPsec�에서 사용되며 ISO/IEC�19722:2009�표준화

Ø 세 가지 방식 가운데 가장 안전함

v Encrypt-and-MAC�(E&M)

Ø SSH�에서 사용됨

Ø MAC과 encryption의 안전성으로부터 전체 안전성이 보장되지 않음

v MAC-then-Encrypt�(MtE)

Ø SSL/TLS�에서 사용됨

Ø Generic한 안전성 증명은 제공되지 않으나, SSL/TLS의 경우 부가적인조치로 증명 가능한 안전성이 제공됨

위 3가지 방식 모두 효율성은 “암호 비용 +�MAC�비용”

인증 제공 블록암호 운용모드: OCB 3.0

Checksum

C1 C3

M1 MM2 M3

C2 C

E

C1

E

C3

M1 M4M2 M3

E

C2

E

C4

EK K K K K

Checksum

Auth

Auth

*

*

T

T

τ

τ

A1 A2 A3

Auth

10*A *A1 A2

Auth

∆

∆ ∆ ∆ ∆

∆ ∆ ∆

∆

∆ ∆ ∆

∆ ∆ ∆

∆

∆ ∆ ∆ ∆ ∆ ∆

∆

E EE E EK K K K K

E EEK K K E EEK K K

∆← Inc1(∆)

∆← Init(N)

∆← Inc2(∆) ∆← Inc3(∆) ∆← Inc4(∆) ∆← Inc$(∆)

∆← Inc1(∆)

∆← Init(N)

∆← Inc2(∆) ∆← Inc3(∆) ∆← Inc (∆) ∆← Inc$(∆)

∆← Inc1(∆)

∆← Init

∆← Inc2(∆) ∆← Inc3(∆) ∆← Inc1(∆)

∆← Init

∆← Inc2(∆)

*

∆← Inc (∆)*

0*

Pad Final

Tag

Final

Tag

Figure 5: Illustration of OCB3[E,τ ]. Again E : K × {0, 1}128 → {0, 1}n and τ ∈ [0 .. 128]. Top:Message M has a full final block (|M4| = n) (Checksum = M1 ⊕M2 ⊕M3 ⊕M4). Middle: Message M hasa short final block, 1 ≤ |M∗| < n (Checksum = M1 ⊕M2 ⊕M3 ⊕M∗10∗). Bottom: An AD of three fullblocks (left) or two full blocks and one short one (right). Throughout: Offsets (the ∆-values) are updatedand used top-to-bottom, then left-to-right. Offset initialization and update functions (Init, Inci, Inc$, Inc∗)return n-bit strings. Each flavor of increment is an xor with some precomputed, K-dependent value.

7

v

인증 제공 블록암호 운용모드: OCB 3.0v 인증만 되는 보조정보(AD)와 암호화 및 인증되는 메시지로 구분됨

Checksum

C1 C3

M1 MM2 M3

C2 C

E

C1

E

C3

M1 M4M2 M3

E

C2

E

C4

EK K K K K

Checksum

Auth

Auth

*

*

T

T

τ

τ

A1 A2 A3

Auth

10*A *A1 A2

Auth

∆

∆ ∆ ∆ ∆

∆ ∆ ∆

∆

∆ ∆ ∆

∆ ∆ ∆

∆

∆ ∆ ∆ ∆ ∆ ∆

∆

E EE E EK K K K K

E EEK K K E EEK K K

∆← Inc1(∆)

∆← Init(N)

∆← Inc2(∆) ∆← Inc3(∆) ∆← Inc4(∆) ∆← Inc$(∆)

∆← Inc1(∆)

∆← Init(N)

∆← Inc2(∆) ∆← Inc3(∆) ∆← Inc (∆) ∆← Inc$(∆)

∆← Inc1(∆)

∆← Init

∆← Inc2(∆) ∆← Inc3(∆) ∆← Inc1(∆)

∆← Init

∆← Inc2(∆)

*

∆← Inc (∆)*

0*

Pad Final

Tag

Final

Tag

Figure 5: Illustration of OCB3[E,τ ]. Again E : K × {0, 1}128 → {0, 1}n and τ ∈ [0 .. 128]. Top:Message M has a full final block (|M4| = n) (Checksum = M1 ⊕M2 ⊕M3 ⊕M4). Middle: Message M hasa short final block, 1 ≤ |M∗| < n (Checksum = M1 ⊕M2 ⊕M3 ⊕M∗10∗). Bottom: An AD of three fullblocks (left) or two full blocks and one short one (right). Throughout: Offsets (the ∆-values) are updatedand used top-to-bottom, then left-to-right. Offset initialization and update functions (Init, Inci, Inc$, Inc∗)return n-bit strings. Each flavor of increment is an xor with some precomputed, K-dependent value.

7

OCB 3.0의 효율성

Figure 2: Performance of CCM, GCM, and OCB3 on an x86 with AES-NI. The x-coordinateis the message length, in bytes; the y-coordinate is the measured number of cycles per byte. From top-to-bottom on the right-hand side, the curves are for CCM, GCM, and OCB3. The shaded region shows thetime for CTR mode. This and subsequent graphs are best viewed in color.

introduce something like a GF(2128) multiply to compensate for the usually-eliminated blockciphercall, and no significant penalty is paid, compared to OCB1, if the provided nonce is not a counter(one just fails to save the blockcipher call). We go on to eliminate the latency that used to occurwhen computing the “checksum” and processing the AD (associated data).

Next we study the relative software performance of CCM, GCM, and the different versions ofOCB. We employ the fastest publicly available code for Intel x86, both with and without Intel’s newinstructions for accelerating AES and GCM. For other platforms—ARM, PowerPC, and SPARC—we use a refined and popular library, OpenSSL. We test the encryption speed on messages of everybyte length from 1 byte to 1 Kbyte, plus selected lengths beyond. The OCB code is entirelyin C, except for a few lines of inline assembly on ARM and compiler intrinsics to access byteswap,trailing-zero count, and SSE/AltiVec functionality.

We find that, across message lengths and platforms, OCB, in any variant, is well faster thanCCM and GCM. While the performance improvements from our refining OCB are certainly mea-surable, those differences are comparatively small. Contrary to McGrew and Viega’s findings, thespeed differences we observe between GCM and OCB1 are large and favor OCB1.

As an example of our experimental findings, for 4 KB messages on an Intel i5 (“Clarkdale”)processor, we clock CCM at 4.17 CPU cycles per byte (cpb), GCM at 3.73 cpb, OCB1 at 1.48 cpb,OCB2 at 1.80 cpb, and OCB3 at 1.48 cpb. As a baseline, CTR mode runs at 1.27 cpb. See Figures 2and 3. These implementations exploit the processor’s AES New Instructions (AES-NI), including“carryless multiplication” for GCM. The OCB3 authentication overhead—the time the mode spendsin excess of the time to encrypt with CTR—is about 0.2 cpb, and the difference between OCBand GCM overhead is about a factor of 10. Even written in C, our OCB implementations provide,on this platform, the fastest reported times for AE.

The means for refining OCB are not complex, but it took much work to understand whatoptimization would and would not help. First we wanted to arrange that nonces agreeing on allbut their last few bits be processed using the same blockcipher call. To accomplish this in a way thatminimizes runtime state and key-setup costs, we introduce a new hash-function family, a stretch-then-shift xor-universal hash. The latency reductions are achieved quite differently, by changes inhow the mode defines and operates on the Checksum. Further structural changes improve supportfor incremental APIs.

3

v CCM: CTR�모드에 CBC-MAC�결합한 방식

Ø IEEE�802.11i�등 각종 국제표준으로 채택됨

Ø OCB보다 효율성이 떨어지지만 지적재산권 문제에서 자유로움

v EAX,�CWC,�GCM�등

OCB 1.0/2.0/3.0 의 특징

v Phillip�Rogaway�설계 (2003)

Ø 특허 등록되어 있으나,�미국 외에서는 로열티 면제

v 하나의 키로 운용 가능함

v 안전성 증명 가능함

Ø OCB-AES�공격이 가능하면 AES에 대한 공격도 가능함

Ø 임의의 블록암호 알고리즘 적용 가능

v 2.0�버전부터 보조정보(AD)를 추가로 인증할 수 있도록 함

Ø 보조정보: 암호화되지 않으면서 인증되어야 하는 정보

인증 제공 블록암호 운용모드: GCMv 인증만 되는 보조정보(AD)와 암호화 및 인증되는 메시지로 구분됨

v 유한체 기반 GHASH�와 Ctr�모드의 결합