기본 콘텐츠로 건너뛰기

White-box-Cryptography

화이트박스 암호 기술

본 내용은 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 클라이언트 소프트웨어를 분석하면 사용자 비밀키를 알아낼 수 있고, 불법적인 사용과 배포에 무방비 상태가 된다. 하지만 사용자 비밀키를 화이트박스 암호로 적절히 숨겨 놓는다면 소프트웨어 분석에 의해서도 쉽게 비밀키를 알아낼 수 없을 것이다.

결론

화이 트박스 암호 기술은 메모리, 수행 속도 등의 제약 등 으로 일부 응용에 국한될 수는 있으나, 저비용의 원격 단말의 소프트웨어적인 보안 솔루션으로는 매우 유용할 것이다. 다만, 관련 기술에 대한 연구 및 개발이 아직까지는 미비한 상태이므로, 안전한 화이트박스 암호구현기술및응용에대한활발한연구개발이 필요하다.

출처 : ETRI 화이트박스 암호 및 응용 기술 동향 분석

이 블로그의 인기 게시물

X-Frame-Options-Test

X-Frame-Options 테스트하기 X-Frame-Options 페이지 구성 시 삽입된 프레임의 출처를 검증하여 허용하지 않는 페이지 URL일 경우 해당 프레임을 포함하지 않는 확장 응답 헤더이다. 보안 목적으로 사용되는 확장 헤더로 아직 적용되지 않은 사이트들이 많지만 앞으로 점차 적용될 것으로 보인다. X-Frame OptionsDENY, SAMEORIGIN, ALLOW-FROM 옵션을 이용하여 세부 정책을 설정한다. 옵션 설명 DENY Frame 비허용 SAMEORIGIN 동일한 ORIGIN에 해당하는 Frame만 허용 ALLOW-FROM 지정된 ORIGIN에 해당하는 Frame만 허용 크롬 4.1 , IE 8 , 오페라 10.5 , 사파리 4.0 , 파이어폭스 3.6.9 이상에서는 DENY , SAMEORIGIN 이 적용되며, ALLOW-FROM 은 각 브라우저 마다 지원 현황이 다르다. https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/X-Frame-Options 해당 확장헤더는 브라우저에서 처리하는 응답 헤더이므로 미지원 브라우저 사용 시 설정과 무관하게 페이지 내 포함된 모든 Frame을 출력한다. (검증 테스트: Opera 5.0.0) 테스트 코드 DENY <!DOCTYPE html> < html lang = "en" > < head > < meta http-equiv = "X-Frame-Options" content = "deny" /> < title > Deny option Test </ title > </ head > < bod

C-lang-vulnerabilities

C 언어 공통 취약점 해당 글은 CERN Computer Security의 Common vulnerabilities guide for C programmers 글을 참고하여 작성하였습니다. C언어에서 발생하는 대부분의 취약점은 버퍼 오버플로우와 문자열 처리 미흡과 관련되어 있다. 이는 segmentation fault를 유발하고 입력 값을 조작할 경우 임의 코드 실행으로 이어질 수 있다. 이에 대부분의 에러와 조치 방안을 살펴보자고 한다. gets stdio gets() 함수는 버퍼 길이를 검증하지 않아 사용 시 항상 취약성을 야기한다. Vulnerable Code #include<stdio.h> int main() { char username[ 8 ]; int allow = 0 ; printf ( "Enter your username, please: " ); gets(username); //악의적인 값 삽입 if (grantAccess(username)) { allow = 1 ; } if (allow != 0 ) { //username을 오버플로우하여 덮어씀 privilegeAction(); } return 0 ; } Mitigation fgets() 함수 사용 및 동적 메모리 할당 #include <stdio.h> #include <stdlib.h> #define LENGTH 8 int main () { char * username, *nlptr; int allow = 0 ; username = malloc (LENGTH * sizeof (*username)); if (!username) return EXIT_FAILURE; printf ( "Enter your username, please:

HTML/CSS를 활용하여 카카오톡 클론 만들기

시간을 내어 HTML과 CSS를 공부한 것은 대학생 때가 마지막이었던 것으로 기억한다. 그 동안 사이드 프로젝트로 진행했던 여러 아이디어들을 결국 서비스하지 못했던 결정적인 이유는 프론트 엔드 기술 부족이었다고 생각하고 우선 HTML과 CSS 학습을 진행하였다. 프론트 엔드 기술은 많은 발전을 거듭하여 예전에 비해 큰 복잡성을 가지게 되었다. 빠른 시간 안에 숙지하지 못한 기법들에 대해서 알아보고 구현하고자 하는 아이디어에 활용할 수 있을 정도로 진행해보고자 한다. 또한 보안적 관점에서 발생할 수 있는 프론트 엔드 위협에 대해 파악할 수 있는 좋은 밑거름이 되길 기대해본다. 우선적으로 진행한 카카오 톡 디자인 클론은 노마드 아카데미의 강의를 수강하며 진행하였고 결과는 아래의 링크에서 확인할 수 있다. 소스코드 저장소 구현된 웹 페이지