"암호화해도 데이터 형태가 변하면 안 돼!"

2016-04-23 Penta Security 보안칼럼

“이 정보는 민감하다.”

2016년 9월부터 모든 ‘민감정보’의 안전성 확보조치가 의무화된다. 전엔 지문∙얼굴∙홍채∙정맥∙음성∙서명 등 소위 ‘바이오 정보’ 암호화만 의무였는데 이제 암호화 대상이 대폭 늘어난 것. ‘민감정보’란? 참 많다. 바이오 정보, 유전자검사 등의 결과로서 얻는 유전정보, 범죄경력 등 뻔한 내용 외에도 사상과 신념, 노조 및 정당 가입 탈퇴, 정치적 견해, 건강 및 성생활 등에 대한 정보, 그리고 그 밖에 사생활을 침해할 우려가 있는 온갖 개인정보 등등등 정말 많다. 왜 그것들을 모두 다 암호화하자는 걸까? 그 이유는,

첫째, 개인정보 유출사고가 너무 자주 일어난다. 특히 우리나라는 다 까발려졌으니 이미 늦은 일 아닌가 싶을 정도로 하도 많이 당해, 외양간 고치라니 고치긴 고친다만 더 훔쳐갈 소도 없는데,, 그런 생각마저 든다. 하지만 어쩌랴, 뒤늦게라도 고칠 수밖에.

둘째, 개인정보 보호조치는 빅데이터 등 최신 데이터 기술 연구개발의 필수조건이다. 아니라면 해당 산업은 활성화될 수 없고 또 활성화되어서도 안 된다. 개인정보가 막 노출된 데이터로는 뭔 짓을 하든 무모한 짓이다. 지금도 이미 중요정보는 알아볼 수 없게끔 처리하지 않나? 물론 그러고 있다. 하지만 문제는 “이 정도는 뭐, 괜찮아!” 대수롭지 않게 여겼던 정보들의 교차편집을 통한 ‘재식별화’의 위험, 그러니까 드러난 정보들을 이리저리 끼워 맞추다 보면 그 관계를 통해 감춰진 내용까지도 유추해 알아낼 수 있어서 비식별화 조치는 아예 헛된 노력이 되고 만다.

“암호화해도 데이터 형태가 변하면 안 돼!”

그래, 민감정보를 모두 암호화하자! 그럼, 끝인가? 아니, 끝 아니다. 업무처리를 위해 어떤 데이터의 값은 특정한 형태를 요구한다. 그러니까, 주민등록번호 값은 ‘000000-0000000’와 같은 형태의 값이어야 하는 경우가 있다. 다른 형태의 값도 인식하게끔 어플리케이션을 수정하면 되잖아? 그게 그리 간단한 일은 아니다. 특히 SAP로 대표되는 기업용 어플리케이션들은 수정이 매우 까다롭다. 그러니 데이터 내용을 알아볼 수 없게끔 비식별화 조치를 취하더라도 ‘000000-0000000’ 형태를 유지해야 한다. 그런데 암호화란 건 원래 암호화하고 나면 형태뿐 아니라 길이까지도 막 달라진다. 그래야 안전하니까. 암호화의 대표선수 AES만 보더라도 원본과 암호문의 형태는 완전히 다르다.
그래서, 문제를 해결할 해법은 없나? 아니, 있다. 크게 두 가지,

첫째, ‘랜덤 토큰’
비식별화가 필수인 데이터만 따로 뽑아내 보안용 데이터베이스에 따로 저장하고, 업무용 데이터베이스에는 실제 데이터를 대신해 원본 데이터와 형태만 동일한 임의의 ‘랜덤 토큰’ 값으로 대체해 사용하는 방법이 있다. 중요한 데이터만 따로 안전하게 보관하니까 편리하고 안전해 보이지만, 그렇지 않다. 업무용 데이터베이스와 보관용 데이터베이스 사이 통신이 필수라 통신구간 보안문제가 심각하고, 애초에 “이 토큰은 이 데이터, 저 토큰은 저 데이터” 1:1로 매칭한 테이블의 존재 자체가 이미 위험하다고 볼 수 있고, 일단 이 DB 저 DB 섞여서 시스템이 복잡한데 복잡한 시스템은 이래저래 좋을 게 없다.

둘째, ‘FPE’
데이터 형태를 그대로 유지한 채 암호화하는 ‘FPE(Format Preserving Encryption, 형태 보존 암호화)’가 있다. 랜덤 토큰과는 달리 원본 데이터를 따로 보관하는 게 아니라 데이터 자체를 암호화해버리기 때문에 보관용 데이터베이스가 따로 필요하지 않아서 전체 시스템 구조가 복잡하지 않고, 불필요한 통신구간 등 보안허점이 적다는 장점이 크다. 하지만 근거 없는 불신이 있다. “암호화는 AES처럼 형태까지도 싹 변해야 제대로 된 암호화지!” FPE의 안전성에 대한 의심은 FPE가 NIST(National Institute of Standards and Technology, 미국 국립표준기술연구소)의 표준 지정을 받지 못했기 때문에 더욱 증폭되었다. 그런데 궁금한 건,

암호화란 도대체 뭘까? 뭘 어떻게 하면 “암호화했다”고 할까?

암호화의 세 가지 조건

암호화란, 아래 세 가지 조건을 갖추면 안전한 암호화라 할 수 있다.1. 원문을 키로 암호화할 때, 원문과 암호문의 관계는 그 키에 대해 유일하다.
2. 원문과 암호문 모두 가져도 모든 키를 다 써 보기 전엔 어떤 키인지 모른다.
3. 원문과 암호문 모두 가져도 원문과 암호문의 관계는 알 수 없다.

괜히 복잡해 보이는데 달리 말하면, 조건2는 암호화의 필수요소인 ‘혼돈(Confusion)’, 조건3은 ‘확산(Diffusion)’을 뜻하고, 조건1은 암호화의 근본인 ‘경우의 수’를 뜻한다. 그래도 복잡해 보이는데,, 다시 말해, 원문을 통해 암호문을 알 수 없어야 하고, 암호문을 통해 원문을 알 수 없어야 하고, 어떤 암호문의 원문은 어떤 건지 알아낼 수 없어야 한다는 뜻으로 이해해도 무방하다.

이 조건을 모두 다 제대로 갖추면 “암호화했다”고 할 수 있다. 자 그럼, FPE는 제대로 된 암호화라 할 수 있을까? FPE에 대해 아주 조금만 더 알아보자.

안전한 FPE 알고리즘을 만드는 방법

먼저 생각해 볼 건 ‘그냥 막 완벽한 암호화’다. 신용카드 번호를 예로 들어, 16자리 십진수 원문을 무작위 16자리 십진수 암호문으로 각각 매칭해 가능한 모든 경우의 수를 생성하면 완벽하다. 그러나, 제대로 안전하려면, 즉 위 암호화의 세 가지 조건을 모두 갖추려면 동원해야 할 모든 경우의 수는 약 60,000GB 용량에 이른다,, 그러니, 완벽하지만 완벽하기 때문에 실용성은 아예 없는 것이다.

따라서 어느 정도 절충이 필요하다. 절충의 기준은 ‘충분한 안전성’이다. 보다 구체적으로 말해, “안전성이 이미 충분히 검증된 AES 알고리즘 이상의 안전성”을 확보하는 것이다. 그럼 가장 기초적인 알고리즘 세 가지를 간단히 훑어보자. 알고리즘 이야기는 왠지 그냥 막 싫지만 대충 포기하고 읽으면 나름 재밌다. 직접 구현하겠다고 덤비지 않는다면 말이지.. -_-

첫째, ‘Prefix Method’
원문의 인풋값, 십진수니까 0~9까지의 값을 AES 등 일반적인 암호화 알고리즘으로 암호화하고, 그렇게 생성된 암호문을 내림차순으로 나열한다. 그럼 순서가 달라져서 인풋값 0~9 값이 무작위로 재배치되는데, 그걸 다시 원래 순서에 따라 교체한다. 그러면 0~9 값은 다른 값으로 바뀌게 된다. 그러면 애초 목적은 훌륭히 달성하지만 ‘완벽한 암호화’와 마찬가지로 너무 큰 용량의 테이블이 형성되기 때문에 실용성은 높지 않은 방법이다.

둘째, ‘Cycle Walking Method’
이건 일단, 간단하다. 원문을 AES 등 암호화 알고리즘으로 암호화하되 원문과 같은 형태가 나올 때까지 계속 돌린다. 안 나오면 나올 때까지 계속 돌린다. 몇 번을 돌려야 할지 해 보기 전에는 알 수 없다. 역시 목적은 달성하지만 실용적이라 할 수는 없다.

셋째, ‘Feistel Network’
가장 적절한 방법이다. 우선 원문을 이진수 형태로 바꾼다. 변환된 이진수 값을 DES 알고리즘의 일종인 Feistel Network로 암호화하고, 암호화된 이진수를 다시 원문과 같은 형태로 변환한다. 알고리즘의 라운드 함수로서 AES 알고리즘을 사용하고 암호화를 여러 번 반복해 수행하기 때문에 AES 이상으로 안전하다고 할 수 있다.
살펴본 바 Prefix Method와 Cycle Walking Method의 경우 데이터 용량과 이용상의 불편함으로 인해 실용성은 떨어지지만 어쨌든, 흔히 걱정하듯 FPE가 “안전하지 않은 방법”은 아닌 것이다. 그중에서도 Feistel Network 방식은 시스템 성능에 영향을 미치지 않는 범위 내에서 적용이 가능하므로 안전성과 실용성을 모두 가졌다고 볼 수 있다.

“FPE 드디어 표준화!”

FPE는 사실상 대안이 없기 때문에 학계와 업계에서 연구개발이 매우 활발히 이루어졌다. 그런데도 NIST가 인정한 표준은 아니었기 때문에 근거 없는 불신이 팽배했다. 특히 랜덤 토큰 방식을 주장하는 측에서는 늘 “FPE는 안전하지 않기 때문에 표준이 아닌 것이다!” 열심히 떠들었다. 그 상황은 뭐랄까, 지적이지 않아서 안타까웠다,,
그러다 마침내 2016년 3월 29일, NIST는 FPE 표준화를 선언했다. FPE는 ‘랜덤 토큰’에 비해 단 하나 찝찝하게 남아 있던 약점마저도 모두 사라진 셈이다. 기술의 성격 상 시스템 적용이 간단하니 도입도 순조롭게 이루어질 것이다. 내심 민감정보 안전성 확보조치 의무화를 앞두고 시스템 복잡도 때문에라도 제대로 시행될 수 있을까 걱정했는데, NIST발 FPE 표준화 뉴스는 정말 반가운 소식이다. 이렇게 사회적으로 그리고 국가적으로 정말 중요한 상황 변화를 나 혼자 반가워 하는 것 같아 좀 쓸쓸하긴 하지만,, T_T