화이트박스 암호 기술
본 내용은 ETRI의 화이트박스 암호 및 응용 기술 동향 분석 문서를 참고하여 작성한 글입니다.
등장 배경
지금까지 암호 알고리즘은 동작하는 단말과 단말의 신뢰를 토대로 제 3자가 해독할 수 없게 하는 것을 목표로 만들어졌다. 그러나 사용자가 사용하는 단말에 심어진 악성 프로그램이나, 공격자가 공격을 위해 암호화 통신에 참여할 수 있으므로 통신하는 양쪽을 신뢰할 수 없는 것이 현실이다. 이에 TPM, 스마트카드와 같은 하드웨어를 활용한 대안이 제시되고 있으나 비용증가 및 설치의 어려움의 문제를 안고 있다.
이를 해결하고자 등장한 화이트 박스 암호 기술은 소프트웨어만으로 암호 키를 안전하게 보관할 수 있고, 신뢰할 수 없는 단말에서 암호화 알고리즘이 실행되더라도 암호 키가 드러나지 않도록하는 기술이다.
암호 기술
AES 화이트박스 암호를 활용하여 기본 원리와 동작 메커니즘을 알아보자.
화이트 박스 암호 원리
암호 키가 신뢰할 수 있는 장치에서 관리된다고 가정했던 기존의 암호 메커니즘과 달리 화이트박스 암호 메커니즘에서는 끝단의 장치를 신뢰하지 않고 암호 키를 암호 알고리즘에 섞어 암호 키를 쉽게 볼 수 없게 하였다.
즉, 화이트박스 암호는 알고리즘을 큰 룩업테이블로 만들고 그 안에 암호 키를 암호 알고리즘과 뒤섞인 상태로 숨겨둠으로써 내부의 동작을 분석하더라도 암호 키를 쉽게 유추하지 못하도록 하는 기법이다. 암호 알고리즘을 하나의 큰 룩업테이블로 만들면 크기가 지나치게 커지므로, 분리하되 중간 값이 노출되지 안도록 인코딩과 디코딩을 수행한다.
인코딩 과정()과 디코딩 과정()이 별도의 테이블에서 계산되므로 중간 값이 노출되지 않고 원래 암호화 동작()만 수행하는 결과와 동일하다. 안전성() 과정이 추가되기 때문에 동일한 암호 키를 사용하더라도 AES를 이용한 암복호화 결과와 화이트박스로 구현된 AES를 이용한 암복호화 결과는 차이가 있다.
룩업테이블
순람표(順覽表) 또는 룩업 테이블(lookup table)은 컴퓨터 과학에서 일반적으로 배열이나 연관 배열로 된 데이터 구조로, 런타임 계산을 더 단순한 배열 색인화 과정으로 대체하는 데 자주 쓰인다. 처리 시간의 절약은 중요할 수 있는데, 이는 메모리로부터 값을 받아오는 것이 더 일이 많이 드는 계산이나 입출력 기능을 거치는 것보다 더 빠르기 때문이다.[1] 테이블들은 정적인 프로그램 저장소에 미리 계산되어 저장하거나, 프로그램 초기화 단계(메모이제이션)의 일부로 계산(프리페치)할 수도 있다. 룩업 테이블은 배열에 위치한 일련의 (올바르거나 올바르지 않은) 값 항목들을 일치시키면서 입력값이 유효한지 확인하는 데 널리 쓰이기도 하며, 프로그래밍 언어에서는 포인터 함수를 포함(또는 레이블로 오프셋)하여 일치하는 입력을 처리할 수 있다.
위키피디아 - 순람표
동작 메커니즘
AES 알고리즘의 라운드 연산과 WB-AES의 라운드 연산에는 차이가 있다. AES의 경우 SubBytes, ShiftRows, MixColumns, AddRoundKey의 반복으로 이루어지지만, WB-AES 라운드 연산은 ShiftRows, AddRoundKey, SubBytes, MixColumns의 반복으로 이루어져 있다. 즉, WB-AES에서는 최초의 Key whitening을 위한 AddRoundKey 연산을 첫 번째 라운드 내에서 수행하고 첫 번째 라운드의 AddRoundKey 연산은 다음 라운드 연산에서 수행하도록 함으로써, 매 라운드는 AddRoundKey 연산에서 시작해 MixColumns 연산으로 끝난다. WB-AES에서 라운드 연산을 MixColumns로 끝나도록 한 이유는 WB-AES 구현 시 하나의 큰 룩업 테이블이 아닌, 여러 개의 작은 룩업 테이블로 만드는 과정과 관계가 있다. ShiftRows는 1 바이트 단위의 연산으로써 AddRoundKey 및 SubBytes와 순서가 바뀌어도 연산 결과는 동일하므로 구현의 편의를 위해서 매 라운드 연산의 맨 앞에서 수행한다. 다음 표는 128비트 입력 키 길이에 대한 AES 및 WB-AES의 연산 순서를 보여준다.
| AES | WB-AES |
|---|---|
| 1.AddRoundKey() | 1.for i from 1 to 9: |
| 2.for i from 1 to 9: | (a) ShiftRows; |
| (a) SubBytes; | (b) AddRoundKey(); |
| (b) ShiftRows; | (c) SubBytes; |
| (c) MixColumns; | (d) MixColumns; |
| (d) AddRoundKey(); | 2.ShiftRows; |
| 3.SubBytes; | 3.AddRoundKey(); |
| 4.ShiftRows; | 4.SubBytes; |
| 5.AddRoundKey() | 5.AddRoundKey() |
SubBytes
역변환이 가능한 S-Box 표를 이용하여 암호문이 비선형을 갖게 한다.
ShiftRows
각 행 단위로 정해진 수 만큼 순환 시프트를 수행한다.
MixColumns
순환행렬을 사용하여 열을 섞는다.
AddRoundKey
라운드 키와 현재 상태를 비트 단위로 (XOR) 연산한다.
S. Chow가 제안한 WB-AES는 Type1a, Type1b, Type2, Type3, Type4의 다섯 가지 테이블로 구성되어 있는데, 각 테이블의 입력 데이터와 출력 데이터는 각각 2개의 nibble(4비트)을 치환하여 디코딩하고 인코딩하는 비선형 변환을 통해서 테이블 내부 연산이 쉽게 드러나지 않도록 하였다. 5개 테이블을 이용한 WB-AES의 연산 순서는 다음과 같다.
Type1a -> Type4 ->
Type2 -> Type4 -> Type3 -> Type4 (1st Round)
Type2 -> Type4 -> Type3 -> Type4 (2nd Round)
...
Type2 -> Type4 -> Type3 -> Type4 (9th Round) ->
Type1b -> Type4위에서 볼 수 있듯이 Type1a, Type1b, Type2, Type3 테이블 연산 후에는 Type4 테이블 연산이 따라온다. 이는 Type1a, Type1b, Type2, Type3 내에서 수행했던 행렬 곰셈 결과들을 모아서 행렬 곰셈의 마무리를 위한 XOR 연산을 할 필요가 있는데, Type4 테이블에서 이러한 XOR 연산을 수행하기 때문에 Type4 테이블이 다른 테이블의 뒤에서 따라오게 된다. Type2 테이블에서는 대부분의 AES 라운드 연산을 수행하는 데 상세 구조는 다음과 같다.
| Input Decoding |
|---|
| 8x8 Mixing bijection |
| ShiftRows |
| AddRoundKey |
| SubBytes |
| MixColumns |
| 32x32 Mixing bijection |
| Input Decoding |
Type2 테이블에서는 입력 데이터의 디코딩, 출력 데이터의 인코딩 외에도 라운드 연산 전/후에 8X8 가역행렬을 곱해주는 8x8 Mixing bijection 연산이 존재한다. 라운드 연산 전/후에 곱해줌으로써 라운드 연산의 중간 데이터 및 키를 공격자로부터 안전하게 숨길 수 있다.
Type3 테이블에서는 Type2 테이블에서 곱해진 8×8 행렬(8×8 mixing bijection)과 32×32 행렬 (32×32 mixing bijection)에 대한 역행렬을 곱해줌 으로써 Type2, Type4, Type3, Type4 테이블 연산 을 모두 수행하였을 때, AES의 라운드 연산만 남을 수 있도록 한다. Type1a 테이블과 Type1b 테이블 은 WB-AES의 안전성을 높이기 위하여 128비트 입 력 및 출력 데이터에 128×8 가역행렬을 곱해주는 연산을 수행한다. 그리고, 이들 행렬 곱으로 인해서 동일 입력 데이터와 동일한 키가 입력되더라도 WB-AES의 연산 결과와 AES의 연산 결과는 달라지게 된다. 또한 Type1b 테이블은 앞서 기술한 출력 데이 터가 직접 드러나지 않도록 보호해주는 기능 외에도 AES의 마지막 라운드 연산을 함께 수행하는데, Type1b 테이블의 구조는 아래를 참고하자.
| Input Decoding |
|---|
| 8x8 Mixing bijection |
| ShiftRows |
| AddRoundKey (9th 라운드의 AddRoundKey 연산) |
| SubBytes |
| AddRoundKey (10th 라운드의 AddRoundKey 연산) |
| 128x8 Mixing bijection |
| Input Decoding |
AES의 암호화 연산은 Add- RoundKey 연산을 수행한 후 10회의 라운드 연산 (128비트 입력 데이터에 대한 암호화 연산의 경우)을 수행하는데, WB-AES에서는 최초의 AddRoundKey 연산을 첫번째 라운드 연산을 수행하는 Type2 테이블 내에서 수행하고, 첫 번째 라운드의 AddRoundKey 연산은 두 번째 라운드 연산을 수행하는 Type2 테이블 내에서 수행하므로, 마지막 라운드 연산을 수행하는 Type1b 테이블에서는 9번째 라운드용 AddRound- Key 연산과 마지막 라운드용 AddRoundKey 연산을 함께 수행한다.
Type1b 테이블의 8×8 mixing bijection 연산은 9번째 라운드 연산을 수행했던 테이 블들 중 Type3 테이블에서 8×8 역행렬을 미리 곱해주고, Type1b 테이블에서 이의 역행렬인 8×8 행렬을 곱해주는 연산을 수행함으로써 서로 상쇄될 수 있도록 하였다.
앞서 기술하였듯이, Type3 테이블에서는32× 32 역행렬과 8×8 역행렬을 곱해주는 기능을 수행하는데, 32×32 역행렬은 동일 라운드의 Type2 테이블 에서 곱해준 32×32 행렬에 대한 역행렬을 곱해주는 것이고, 8×8 역행렬은 다음 라운드의 Type2(마지막 라운드의경우Type1b) 테이블에서 곱해줄 8×8 행렬에 대한 역행렬을 곱해 주는 것 이다. 또한 첫 번째라운드 연산에서 Type2 테이블에서 곱해줬던 8×8 행 렬에 대한 역행렬은 Type1a 테이블에서 미리 곱해 주기 때문에 서로 상쇄되어 없어질 수 있다. 아래는 Type1a 테이블의구조를보여준다.
| Input Decoding |
|---|
| 128x8 Mixing bijection |
| 128x128 inverse mixing bijection |
| Input Decoding |
아래는 WB-AES에서 mixing bijection (행렬 곱셈) 과정을 통해서 곱해진 행렬이 어떤 행렬과 서로 역행렬 관계에 있고, 이들이 상쇄되는지를 보여준다.
cancel out+---------------------------------------+cancel out+---------------------------------------+
+---------------+ | +----------+ +-------------+ | | +----------+ +-------------+ |
| 128x8 MB | +->+ | 8x8 MB |cancel out| 8x8 MB^+1 | +--------->+ | 8x8 MB |cancel out| 8x8 MB^+1 | |
| Type1a | | | | Type2 | | Type3 | | | | Type2 | | Type3 | |
| 128x128 MB^+1 +--+ | | 32x32 MB +--------->+ 32x32 MB^+1 | | | | 32x32 MB +--------->+ 32x32 MB^+1 | |
+---------------+ | +----------+ +-------------+ | | +----------+ +-------------+ |
| | | |
+---------------------------------------+ +---------------------------------------+
1st round 2nd round
cancel out+---------------------------------------+
| +----------+ +-------------+ |cancel out+-------------+
... +-------->+ | 8x8 MB |cancel out| 8x8 MB^+1 +----------->+ 8x8 MB |
| | Type2 | | Type3 | | | Type1b |
| | 32x32 MB +--------->+ 32x32 MB^+1 | | | 128x128 MB |
| +----------+ +-------------+ | +-------------+
| |
+---------------------------------------+
9th round위에서 볼 수 있듯이 WB-AES 연산 중간에 Mixing bijection 과정을 통해서 곱해진 행렬들은 모두 상쇄되지만, 평문 입력 데이터에 곱해진 행렬과, 암호문 출력 데이터에 곱해진 행렬은 상쇄되지 않고 남아있게 되고, 이들 행렬에 대한 역행렬은 복호화 과정에서 곱해져서 상쇄되어 데이터의 암/복호화가 정상적으로 이루어진다. (위의 그림은 편의를 위하여 Type4 테이블이 생략되었다.)
기술적 이슈
암호화 키를 추출해 내고자 하는 공격에 안전하게 대응이 가능하지만, 화이트박스 암호모듈 전체를 가져다 쓰는 공격에 대해서는 취약할 수 밖에 없다. 따라서 다른 단말에서 불법으로 사용되지 못하도록 하는 노드-락킹(node-locking) 기술이 함께 구현될 필요가 있다. 또한 기존의 암호 기술에 비해 암/복호화 속도가 느리고 많은 양의 메모리를 필요로 하는 단점이 있다. 그 밖에도 키만 안전하게 전송하면 되었던 기존의 방식과는 달리 룩업 테이블 전체를 전송해야한다는 점 또한 추가로 고려해야 할 점이다. 하지만 이는 별도의 키 전송 보안 메커니즘이 불필요하다는 장점으로 해석될 수 있다.
응용 기술
소프트웨어 보호 응용 서비스
소프트웨어 임의조작 방지에 화이트박스 암호를 적용하여 소프트웨어에 변조가 발생되면 화이트박스의 암호 키까지 변경되도록 화이트박스 암호 테이블을 구성함으로써 암호 연산 결과 값이 의미 없는 값이 되도록 한다. 이는 복호화를 진행하면서 바이너리 코드의 무결성을 확인한다는 의미에서 ‘이중 해석’ 메커니즘으로 부르기도 한다.
콘텐츠 보호 응용 서비스
DRM은 디지털 콘텐츠에 대한 불법적인 사용을 차단하기 위해서 콘텐츠는 암호화하고, 콘텐츠 암호 키(CEK) 등의 권한정보는 특정 단말 또는 사용자만 볼 수 있도록 별도로 암호화하여 전송한다. 이에 DRM 클라이언트에 권한정보를 해독할 수 있는 사용자의 비밀키를 내장하는 경우가 많다. 이 경우, 콘텐츠 제공자가 콘텐츠를 암호화해서 전송하더라도 사용자가 DRM 클라이언트 소프트웨어를 분석하면 사용자 비밀키를 알아낼 수 있고, 불법적인 사용과 배포에 무방비 상태가 된다. 하지만 사용자 비밀키를 화이트박스 암호로 적절히 숨겨 놓는다면 소프트웨어 분석에 의해서도 쉽게 비밀키를 알아낼 수 없을 것이다.
결론
화이 트박스 암호 기술은 메모리, 수행 속도 등의 제약 등 으로 일부 응용에 국한될 수는 있으나, 저비용의 원격 단말의 소프트웨어적인 보안 솔루션으로는 매우 유용할 것이다. 다만, 관련 기술에 대한 연구 및 개발이 아직까지는 미비한 상태이므로, 안전한 화이트박스 암호구현기술및응용에대한활발한연구개발이 필요하다.