클라우드에서의 데이터 암호화 : 포맷이 문제

십자드라이버로 일자 구멍 난 나사 조이려니 삐걱거릴 수밖에

암호화할 파일 포맷을 맞출 수 없다면 암호화 후 포맷 맞추면 돼

기술의 발전과 발맞추는 학문적인 접근, 두 성과가 같이 가야

[보안뉴스 문가용] 클라우드 보안 문제가 심각하게 대두되자 기업들의 첫 번째 반응은 다음과 같았다. “모조리 암호화 하자!” 암호화가 데이터 레지던시(data residency)와 관련된 법이나 정책을 충족시키는 방법이기도 하고 불의의 사고나 실수로 정보가 유출되었을 때 마지막 안전장치 역할을 하기는 한다.

또한 이로 인해 생기는 심리적 안정감은 보너스나 다름이 없다. 그러나 기존의 암호화 기술은 클라우드의 사용 목적 자체를 근본부터 부정하기도 한다는 데서 문제가 생긴다. 마치 십자드라이버를 가지고 일자 나사를 꽉 조이려고 하는 것과 비슷한, 부자연스럽고 아귀가 안 맞는 느낌이랄까.

클라이언트 측면에서의 암호화 문제 : 구조화된 데이터

현존하는 클라우드 데이터 API들은 데이터가 특정 포맷으로 변환되어야만 받아들일 수 있다. 예를 들어 신용카드는 16자리 스트링 값을 데이터로서 받아들일 수 있다. 이를테면 일자 나사 구멍과 같다. 그런데 데이터 암호화는 포맷이 딱히 정해지지 않은 무작위 비트 스트링으로 구성된다.

즉 일자 나사 구멍을 압박하고 있는 십자드라이버라고 볼 수 있다. 결과는 어떨까? 기존의 암호화 방법이 아무리 뛰어나도 제대로 사용하는 게 불가능했다. 일자 나사와 십자드라이버가 맞을 리가 없기 때문이다.

그런데 문제는 이게 다가 아니다. 십자드라이버니 일자 나사 구멍이니 하는 예는 정말로 ‘단순화’시킨 비유이다. 실제로 민감한 정보는 제각각의 포맷으로 구성되기 때문이다. 즉 구멍 모양이 너무나 많다는 것이다. 신용카드가 16자리 스트링으로 구성되어 있다면 봉급은 양수로, 이메일은 알파벳 스트링이면서 가운데 @가 들어가는 포맷을 갖추고 있다. 도메인 이름에는 .com과 같은 꼬리표가 붙는다. 우리가 가지고 있는 건 십자드라이버인데 별모양, 삼각형, 네모모양 나사 구멍에 맞추어야 하는 게 현실이다.

그러니 특정 포맷 한 가지의 암호화 문제를 해결했다해도 대세에는 큰 영향이 없는 것이다. 그런 식으로 해결해야 할 포맷의 물리적인 수량이 압도적으로 많기 때문이다. 그래서 앞서가는 보안 업체의 엔지니어들의 가장 기본이 되는 덕목 혹은 능력은 최대한 많은 포맷을 다룰 수 있는 ‘인간 호환성’이라고도 한다. 실제로 큰 기업들의 전문가들은 고객마다 다른 포맷을 능수능란하게 다룬다고 한다.

문제 뒤집어보기

이러한 문제의 근본을 자각하고 난 뒤 곧바로 팀을 꾸려 연구를 시작했다. 그게 2009년의 일이었고, 우리 팀은 이 문제를 거꾸로 거슬러 올라가 보고자 했다. 십자드라이버니 일자 홈이니 하는 비유는 잠시 접어두고, 암호화 후 데이터가 특정 포맷으로만 산출될 수 있도록 했던 것이다.

그리고 이를 포맷 유지 암호화, FPE(Format-preserving Encryption)라고 명명했다. 이 이름을 처음 지은 건 HP의 테렌스 스파이즈(Terence Spies)라는 부서였다. 즉, 우리가 이런 식으로 암호화에 접근한 최초의 사람이거나 유일한 부류였던 건 아니라는 뜻이다.

테렌스 스파이즈 소속의 연구원들처럼 이미 암호화와 포맷의 상관관계를 연구하고 고민하던 사람들은 여럿 있었다. 우리는 그런 선행 연구를 꼼꼼히 공부하고 분석했다. 그렇게 FPE 중에서도 굉장히 다양한 포맷을 아우를 수 있는 FFX 모드라는 게 탄생했다. 여기에는 신용카드 번호, 작은 정수 등이 포함된다.

하지만 많은 포맷과 호환할 수 있는 기능을 가지고 있을지는 몰라도 ‘모든’ 포맷이 담겨있는 건 아니었다. 예를 들어 이메일 주소를 FFX 모드로 암호화한다면 오류가 무수히 발생했다.

지금은 해결책이 나왔지만 당시에는 그놈의 이메일 주소가 커다란 장벽처럼 보였다. 알고리즘을 마련하는 데에 여러 번 실패가 있었다. 하지만 그 실패 속에서 FPE와 FFX는 점점 단단해져갔다. 평범한 표현 방식의 포맷화나 문맥 자유 문법(Context Free Grammar)을 다루는 데에 있어 효율성도 높아졌다.

또한 보다 보편적인 알고리즘을 만들어내기도 했다. 그것이 포맷을 유지하는 암호화를 넘어선, 포맷을 변환시키는 암호화(format transforming encryption, FTE). FPE에서는 평범한 텍스트가 사이퍼텍스트(ciphertext)로 바뀐다면, FTE에서는 굳이 입력 포맷과 결과물 포맷이 같지 않아도 되었던 것이다.

결국 사용자가 사용하기 쉬워야

하지만 결국에 가서는 안전하기도 하지만 사용자가 매력을 느낄 수 있을 정도로 사용이 용이해야 했다. 다시 드라이버 비유로 돌아갔을 때 사용자가 그저 ‘드라이버 홈이 맞질 않는다’고 할 것이 아니라 ‘어떤 크기와 모양의 드라이버가 잘 어울리겠다’는 것도 찾아낼 수 있어야 한다는 뜻이다. 그래서 어떤 보안 업체에서는 특정 표현들을 아예 지정해 고객이 자신의 컴퓨터나 사이트에서 직접 프로토타이핑을 더 빠르게 해주는 서비스를 제공하기도 했다.

동시에 새로운 암호화 엔진 개발에 드는 비용도 크게 줄여주었다. FPE 역시 이 암호화 과정을 매우 간단히 만들어 사용자가 편리하게 사용할 수 있도록 했다. 커스터마이징이 가능하게 했다. 이렇게, 사용하기 쉬우니 사용자들은 이를 가져가 자신의 다른 여러 클라우드 서비스에 적용하기 시작했다. 심지어 익명성을 보장해주기로 유명한 서버인 토르(Tor)에도 이 기술이 일부 적용되었다.

결국 클라우드 분야에서 보안의 기술이 발전함에 따라 학문적인 혁신도 함께 이루어져가고 있는 형국이다. 암호화의 기술이 높아지면 높아질수록, 그리고 학문적인 연구와 성취도 그에 발맞출 수 있으면 있을수록 기업들은 클라우드 서비스를 좀 더 안전하게 활용할 수 있게 될 것이다. 누구나 하는 말이지만, 보안의 혁신은 사용성의 혁신을 이끈다. 이 둘은 반목할 필요가 전혀 없는 개념이다.

글 : 토마스 리스텐파트(Thomas Ristenpart)

Copyrighted 2015. UBM-Tech. 117153:0515BC

[국제부 문가용 기자(globoan@boannews.com)]

내년 회사에 꼭 도입하고 싶은 보안 솔루션 또는 플랫폼은 무엇인가요?
	XDR
	EDR
	AI 보안
	제로트러스트
	공급망 보안 체계(SBOM)
	클라우드 보안 솔루션
	기타(댓글로)