특별한 ‘보안’ 수요를 위해 클라우드라는 산업 내에서 ‘종단간 암호화’를 핵심 기능으로 삼는 서비스들이 생겨나 사용되고 있다. 하지만 상세히 살펴보니 이들이 주장하는 ‘보안성’은 제대로 제공되지 않고 있었다. 무슨 일이 일어나고 있는 것일까?
[보안뉴스 문정후 기자] 클라우드 서비스들 중 종단간 암호화를 전면에 내세우는 경우들이 있다. 사용자들은 소중한 데이터를 제3자인 클라우드 서비스에 저장해야 할 때, 바로 이런 ‘종단간 암호화’라는 약속을 믿고 안심할 수 있다. 하지만 최근 연구를 통해 일부 ‘종단간 암호화’ 클라우드 서비스들이 제대로 된 데이터 보호 성능을 갖추고 있지 않음이 드러났다. 심지어 문제가 있음을 알렸는데도 응답을 하지 않거나 보완할 필요가 없다고 대응한 업체들도 있었다.
종단간 암호화 클라우드 서비스들을 대상으로 보안 실태를 조사한 건 취리히공과대학의 연구원들이다. 이들은 보고서를 통해 싱크(Sync), 피클라우드(pCloud), 아이스드라이브(Icedrive), 시파일(Seafile), 트레소릿(Tresorit)이라는 서비스를 집중적으로 파헤쳤다고 밝히며 “이 서비스들의 보안 수준이 적절하지 못했다”고 밝혔다. “이 기업들은 총 2,200만 명의 고객을 보유하고 있으며, 종단간 암호화 클라우드(E2EE Cloud)라는 시장에서 꽤나 큰 영향력을 발휘하고 있습니다.”
종단간 암호화 클라우드?
이번 연구의 대상이 된 다섯 가지 클라우드 서비스는 클라우드 중에서도 ‘저장소’로 분류된다. 사용자들 대신 저장 인프라를 제공해주는 사업을 하고 있다는 뜻으로, 구글 드라이브, 아이클라우드, 원드라이브, 드롭박스 등이 대표적이다. 이런 서비스들에 등록된 사용자는 전 세계 40억 명이 넘는 것으로 알려져 있으며, 이런 서비스들에 저장된 데이터는 엑사바이트 단위라고 한다. 데이터 보호를 위해 암호화 기술을 채택하고 있는데, 종단간 암호화가 아니라 ‘저장된 상태에서의 암호화(Encryption at rest)’이다.
‘저장된 상태에서의 암호화’는 클라우드 업체 자체가 해킹당할 경우 데이터를 보호하지 못한다. 물론 아직까지 ‘메이저’ 클라우드 업체들이 해킹당해 고객 데이터를 잃은 사례는 없지만 그 어떤 조직이라도 해킹에 당할 가능성을 100% 배제할 수 없기 때문에 불안감을 표현하는 경우들이 있다. 그래서 일부 클라우드는 한층 더 강력한 암호화 기술인 종단간 암호화(E2EE)를 제공하기 시작했고, 자연스럽게 E2EE 클라우드 시장이 형성되기에 이르렀다.
“저장된 상태에서의 암호화는 암호화 키를 클라우드 제공 업체의 서버에 보관합니다. 그래서 회사가 해킹당하면 무용지물이 된다는 소리가 나오는 겁니다. 하지만 종단간 암호화는 서버가 아니라 사용자가 암호화 키를 관리하도록 되어 있습니다. 해커 입장에서는 암호화 키를 얻어내기 위해 수많은 고객들을 일일이 해킹해야 합니다. 따라서 공격 난이도가 높아집니다. 이 기술이 더 안전하다고 딱 잘라 말하기는 어렵습니다만, 이런 방식의 보호 기술을 더 선호하는 사용자들이 있는 것이 사실입니다.” 대표적으로 독일 및 세르비아 정부, 국제사면위원회 등과 같이 굵직한 조직들이 데이터 보호에 민감하며, 따라서 종단간 암호화를 더 선호하는 것으로 알려져 있다.
서비스 상세 보기 : 싱크
싱크는 2011년에 설립된 캐나다 회사다. 전 세계 200만 명 이상의 사용자를 보유하고 있다. 캐나다 정부, 토론토대학교, 캐나다 적십자 등이 주요 클라이언트로, 정보 보호에 민감한 사람이나 조직들이 이용한다는 인상을 주고 있다. 현재 130 페타바이트 이상의 데이터를 저장하고 있으며, 웹 애플리케이션과 데스크톱용 애플리케이션, 모바일용 클라이언트를 제공한다. 이번 분석에서는 웹 애플리케이션에 초점이 맞춰져 있다.
“싱크는 대칭 암호화로서는 AES-GCM을 사용하며, 비대칭 암호화로서는 PKCS1v1.5가 적용된 RSA를 사용합니다. 키 도출 함수로서는 12바이트의 무작위 솔트 값을 사용하는 PBKDF2-SHA256을 사용하고 있습니다.” 취리히공과대학 연구원들이 보고서를 통해 밝힌 내용이다. “등록 과정에서 클라이언트는 두 개의 값을 도출하고, 동시에 새로운 RSA 키 쌍을 생성합니다. 생성된 키 쌍은 다시 암호화 되는 등 여러 후속 과정을 거칩니다. 모든 암호문은 서버에 전송되고, 클라이언트가 로그인 할 때마다 암호문과 키 자료가 서버에서 확인되고 복호화 과정을 거칩니다.”
싱크는 링크나 폴더 공유 옵션을 통해 파일 공유를 가능하게 해 준다. “링크 공유의 경우, 해당 링크를 가진 사람만이 파일에 접근할 수 있게 됩니다. 이 링크를 생성하려면 사용자가 먼저 32자의 무작위 문자열을 가지고 비밀번호를 생성해야 합니다. 그런데 이 비밀번호가 공유 링크의 URL 경로의 일부로 편입됩니다. 이 때문에 링크만 가지고 있어도 어느 정도 비밀번호 파악이 가능하며, 따라서 파일에 접근하는 게 가능해집니다.”
서비스 상세 보기 : 피클라우드
스위스에 본사를 둔 피클라우드는 이번 실험 대상이 된 업체 중 가장 큰 규모를 자랑한다. 사용자도 1900만 명 이상인 것으로 알려져 있다. 가입할 때 사용자는 암호화 된 저장소에 접근하기 위한 추가 비밀번호를 설정해야 하는데, 이는 로그인 비밀번호와는 다른 역할을 한다. 이번 연구에서 집중적으로 분석된 것은 바로 이 추가 비밀번호였다고 연구원들은 밝혔다.
"피클라우드의 경우 암호화 하려는 데이터의 유형에 따라 상이한 대칭 암호화 방식을 사용합니다. 비대칭 암호화도 사용하는데, RSA와 OAEP를 활용하며, 해시 함수로는 SHA1을 채택하고 있습니다. 키 도출을 위해서는 64바이트의 무작위 솔트를 사용하는 PBKDF2-SHA512가 활용되고 있습니다.” 이는 피클라우드라는 회사의 암호화 방식을 나타내는 전반적인 설명이다. 연구원들은 계속해서 신규 등록 시 발생하는 일에 대해 상세히 설명했다.
“새 사용자가 등록하면 비밀번호 P를 사용해 32바이트 대칭 키 𝐾master와 16바이트 IVmaster를 도출합니다. 또한 RSA 키 쌍(sk, pk)이 생성되며, 개인 키는 𝐾master와 IVmaster로 암호화 됩니다. 사용자가 파일을 업로드할 때 클라이언트는 암호화된 개인 키(sk)를 서버로부터 가져와 비밀번호로 복호화하고, 인증되지 않은 공개 키(pk)를 서버에서 받아옵니다. 공개 키가 인증되지 않았으므로, 클라이언트는 개인 키와 공개 키의 일관성을 확인해야 합니다. 이를 위해 클라이언트는 32자리의 무작위 16진수 문자열을 추출한 후, 이를 공개 키로 암호화하고 개인 키로 복호화하여 원래의 문자열이 반환되는지 확인합니다.”
그런 방식으로 검증에 성공하면 클라이언트는 32바이트 대칭 암호화 키를 두 개 생성한다. 파일은 섹터 단위로 나눠지며, 각 섹터는 4096 바이트로 분할된다. 단 마지막 섹터의 크기는 본래 파일 크기에 따라 달라질 수 있다. 분할 과정을 통해 생성된 섹터는 개별적으로 암호화 되고, 이 과정에서 암호문과 태그가 생성된다. 파일 무결성을 보장하기 위한 조치가 반복해서 이뤄지며, 파일이 다운로드 될 때 이 조치들을 통해 무결성 검사가 이뤄진다.
서비스 상세 보기 : 아이스드라이브
아이스드라이브는 2019년에 출범한, 가장 연차가 짧은 업체로 현재 약 15만 명의 고객을 보유하고 있는 것으로 알려져 있다. 블록 암호로서 투피시(TwoFish)를 사용하는데, 아이스드라이브에 따르면 투피시가 AES/Rijndael보다 안전하다고 한다. “커스텀 블록 암호 모드를 사용할 때는 블록 암호화 기술을 활용해 암호화하고, 파일과 폴더 이름을 암호화 할 때는 표준 CBC 구조를 사용합니다. 키 도출을 위해서는 PBKDF2-SHA256을 사용합니다.”
아이스드라이브에서는 파일을 암호화 하기 전에 2MB의 파일 덩어리로 파일을 분할하며, 각 덩어리는 동일한 키로 암호화 된다. “그런데 이 과정에서 사용되는 요소 하나가 1234567887654321이라는 값을 가지고 있고, 이게 어떤 경우에도 변하지 않습니다. 따라서 파일 덩어리의 조건에 따라 파일의 유사성과 같은 특징을 높은 확률로 추측할 수 있게 됩니다.”
이 값이 변동되지 않는다고 하는데, 랜덤화 옵션이 사용되어 다른 문자열(숫자열)이 적용되는 경우도 있긴 하다고 연구원들은 설명을 잇는다. “하지만 활용되는 문자나 숫자가 제한적입니다. 정해진 범위 안에서만 랜덤화가 이뤄진다는 것이죠. 보안이 그만큼 허술할 수 있다는 뜻이 됩니다. 게다가 그 범위가 너무 좁아서 랜덤으로 만들어진 값이 서로 충돌할 가능성도 배제할 수 없습니다. 이 역시 문제로 이어질 가능성이 있습니다.”
서비스 상세 보기 : 시파일
시파일의 가장 큰 특징은 클라이언트와 서버의 코드가 오픈소스라는 것이다. 자체 서버를 호스팅하지 않고, 사용자가 직접 서버를 호스팅 할 수 있도록 지원한다. 이런 방법으로 시파일 서비스를 사용하는 사람들이 100만 명 이상이라고 한다. 주요 고객으로는 보안 업체 카스퍼스키(Kaspersky), 베를린훔볼트대학, 스트라스부르대학, 투르크대학 등이 있다. 이번 분석에서는 데스크톱 클라이언트에 초점을 맞췄다. 웹 인터페이스도 있긴 한데 종단간 암호화가 지원되지 않는다고 한다.
“시파일의 클라이언트는 암호화 프로토콜의 버전에 따라 다양한 암호화 기술을 채용합니다. 따라서 클라이언트는 아주 다양한 버전의 암호화 프로토콜을 지원하며, 그러므로 호환성 면에서 뛰어난 모습을 보입니다. 하지만 기본적으로는 오픈SSL(OpenSSL)의 바이츠투키(BytesToKey) 알고리즘을 기반으로 하여 해시 함수와 키 도출을 반복해 암호화 자료를 생성하는 방식을 취하고 있습니다.”
보고서에 의하면 시파일은 독립된 암호화 자료를 가진 여러 저장소루 구성된 스토리지 모델을 보유하고 있다고 한다. 사용자들은 저장소마다 다른 비밀번호를 설정하는데, 저장소 생성 시 “비밀번호를 통해 32바이트 대칭 키가 생성되고, 이 대칭 키는 또 다시 암호화를 거친 후에 서버로 전송된다.” 파일 암호화 전에는 중복 제거를 위해 덩어리별로 분할되며, 각 덩어리는 암호화 된다. “그런데 각 덩어리를 암호화할 때 사용하는 값을 변동하지 않으면 파일 덩어리 간 유사성이 의도치 않게 드러날 수 있습니다. 이런 위험성을 시파일도 내포하고 있는 것으로 분석됐습니다.”
서비스 상세 보기 : 트레소릿
2011년에 설립된 클라우드 스토리지로, 주로 기업 고객을 많이 보유하고 있다. 스위스의 업체가 대주주로 있으며, 기술 세부 내용이 담긴 백서를 발표한 적도 있다. 트레소릿은 위 업체들보다 훨씬 복잡한 암호화 구조를 가지고 있는 것으로 분석됐다. 비밀번호 복구, 사용자 계정에 대한 관리자 접근 등의 고급 기능을 제공하기 때문이다.
“트레소릿은 AES-GCM을 사용해 키 자료를 암호화 하며, 파일 암호화를 위해서는 AES OpenPGP 유형의 CFB 모드를 사용합니다. 이와 함께 HMAC-SHA512를 사용해 맥(MAC) 값을 생성하고, 비대칭 암호화로서는 RSA-OAEP를 사용합니다. 키 도출을 위해서는 스크립트(scrypt)와 PBKDF2를 통해 32바이트 솔트를 생성 및 적용합니다.”
트레소릿은 파일을 트레소(Tresor)라는 이름의 상위 폴도 단위로 구성하며, 각 폴더에는 그룹 키 파일이 하나씩 지정된다. 이 그룹 키 파일은 루트 디렉터리의 키를 포함하고 있으며, 대칭 키로 암호화 된다고 한다. “이 대칭 키는 다시 비대칭 키로 암호화 되며, 이는 다시 한 번 그룹으로 암호화 되어 사용자 프로필에 저장됩니다. 그룹 키 파일은 각 상위 폴더의 정보를 포함하며, 이 정보는 폴더 관련 데이터를 암호화 하는 데 사용됩니다.”
트레소릿의 모든 비대칭 키 자료는 인증 기관이 서명한 공개 키 인증서를 통해 인증된다. 클라이언트가 서버로부터 공개 키 자료를 요청할 때마다 인증서가 검증된다. 파일 공유 시 링크 공유와 폴더 공유의 두 가지 방법 중 하나를 선택할 수 있다. 이는 싱크 등 다른 서비스와 유사하다. 링크 공유를 할 때마다 16바이트 비밀이 생성되고, 이것을 바탕으로 고유 식별자가 생성된다. 이 고유 식별자를 통해 파일 이름과 내용의 복호화가 이뤄진다.
실험 결과, 종단간 암호화 클라우드에서 발견된 문제들
종단간 암호화를 제공하는 클라우드 서비스를 집중적으로 분석한 건 “서비스 제공 업체가 해킹을 당하는 상황에서도 데이터가 암호화 된 채로 안전하게 보호된다”는 이들 업체들의 약속이 제대로 지켜지는지 확인하기 위해서였다고 한다. “실제로 저희가 분석한 기업들은 이런 점을 강하게 홍보하고 있었거든요. 홍보한 내용이 사실인지 아무도 확인하지 않는 상황에서 저희가 나선 것이라고 할 수 있습니다.” 그래서 연구원들은 총 10가지 공격을 4가지 항목으로 나누어 실시해 다음과 같은 결과를 얻어낼 수 있었다.
1) 기밀성 침해 공격
- 싱크와 피클라우드의 경우, 공개 키로 암호화 된 암호문에 대한 인증 절차가 없어 공격자가 임의의 키를 주입하는 게 가능했다.
- 싱크와 트레소릿의 경우, 파일을 공유할 때 서버에서 제공하는 공개 키가 인증되지 않는다는 보안 문제가 발견됐다.
- 시파일의 경우, 공격자가 암호화 프로토콜을 다운그레이드 함으로써 사용자의 비밀번호를 추측할 수 있었다.
- 싱크의 경우, 파일 공유 시 링크에 암호가 포함되어 있어 기밀성이 쉽게 깨졌다.
2) 파일 데이터 무결성 공격
- 아이스드라이브와 시파일의 경우, 인증되지 않은 암호화 모드를 사용함으로써 파일 내용을 공격자가 조작하는 게 가능했다.
- 시파일과 피클라우드의 경우, 파일이 암호화 전에 여러 부분으로 나뉘는데(이를 파일 덩어리라고 한다) 이 과정이 인증되지 않아 각 파일 덩어리를 바꾸거나 제거하는 게 가능했다.
3) 메타데이터 공격
- 모든 서비스에서 파일 위치와 이름이 파일 내용과 연결되지 않았다. 그래서 공격자가 파일을 이동시키거나 이름을 바꾸는 게 가능했다.
- 모든 서비스에서 파일 크기, 파일 유형, 수정 날짜와 같은 메타데이터가 인증되지 않아 공격자가 이를 임의로 변경할 수 있었다.
- 파일 길이나 유사성, 디렉터리 구조 등 중요한 정보가 유출되는 경우가 많았다.
4) 파일 및 폴더 주입 공격
- 싱크의 경우, 공격자가 공유 메커니즘을 악용해 폴더를 사용자가 업로드한 것처럼 만들 수 있었다. 따라서 폴더 주입 공격이 가능했다.
- 피클라우드의 경우, RSA 암호문 인증 부재를 이용해 악성 파일 키와 내용을 사용자의 저장소에 주입하는 게 가능했다.
결국 거의 모든 종단간 암호화 클라우드 서비스가 광고하는 내용과 실제로 그들이 제공하는 서비스 사이에 큰 격차가 있음을 알 수 있었다고 연구원들은 강조했다. “종단간 암호화 클라우드 시스템에 근본적인 설계 결함들이 있었습니다. 그러므로 종단간 암호화로 데이터를 보호한다 치더라도, 종합적으로 안전한 환경을 제공하지는 못했습니다. 이는 클라우드 저장소 전반에 걸쳐 광범위하게 퍼져 있는 문제로 파악됩니다.”
현재 상황에 대한 종합적 진단
연구원들은 “대부분의 서비스에서 나타난 첫 번째 문제는 암호화 기본 요소의 오용”이라고 짚었다. “보안성이 불충분한 암호화 기본 요소를 사용하는 경우가 많았습니다. 예를 들어 아이스드라이브와 시파일에서 사용하고 있는 CBC 모드는 파일 데이터에 대한 보안을 어느 정도 제공하지만 무결성은 보장하지 않고 있었습니다. RSA 암호화 알고리즘에 OEAP를 적용하면 공개 키 암호화를 강력하게 하지만, 인증이라는 문제에 있어서는 취약할 수 있습니다. 위에 여러 번 적었지만 암호화 요소 하나를 고정적으로 사용하는 경우도 있었습니다.”
이 문제를 어떻게 해결해야 할까? 연구원들은 “보안에 대한 더 깊은 이해가 필요하다”고 말한다. “예를 들어 파일 데이터는 인증된 암호화 기본 요소를 사용하여 암호화 해야 합니다. RSA 암호문은 반드시 인증 과정을 더해야 한다는 점을 설계 과정에서부터 인지해야 합니다. 하지만 이런 이해도는 상당한 전문성을 필요로 하고 있으며, 기술적 구축을 위해서는 비용도 꽤나 들어갈 수 있습니다. 그럼에도 이것이 필요하다고 하는 건, 종단간 암호화 클라우드 서비스들이 자신들의 보안성을 계속해서 자랑하고 광고하고 있기 때문입니다. 그 정도로 광고하려면 이 정도의 전문성을 갖춰야 한다고 봅니다.”
파일 내용이 유출된다는, 말도 안 되는 문제가 발견되기도 했다. “종단간 암호화 클라우드를 사용하는 목적이 파일의 내용을 보호하는 것인데, 이런 기본마저 잘 지켜지지 않는 모습이 있었습니다. 시파일이나 아이스드라이브의 경우, 올바른 암호화 기본 요소를 사용하지 않고 있어서 종단간 암호화를 실시하긴 하나 파일 데이터의 패턴이 노출될 가능성을 품고 있습니다. 파일 내용이 직접 드러나는 건 아니지만 메타데이터 등의 ‘힌트’들을 얻어가는 게 가능하다는 겁니다. 이 역시 충분히 위험한 상황으로 이어질 수 있습니다.”
이는 대부분의 사람과 기업들이 메타데이터의 가치를 낮게 보기 때문에 발생하는 문제라고 연구원들은 진단한다. “메타데이터는 누군가의 삶에 대한 모든 것을 말해준다는 명언도 있습니다. 메타데이터를 충분히 갖게 된다면 데이터의 내용이 필요 없어질 때도 많습니다. 메타데이터의 중요성을 인정하는 전문가들이 있긴 하지만 대부분 보안 전문가들일 뿐입니다. 좀 더 많은 서비스 기획자와 개발자들이 메타데이터의 중요성을 인지해야 할 겁니다.” 하지만 인식 개선은 대단히 오래 걸리는 일이다. 그래서 연구원들은 “모든 메타데이터를 암호화 하여 서버가 사용자 스토리지의 구조를 알 수 없도록 해야 한다”고 제안하기도 했다.
스토리지의 무결성이 부족하다는 문제도 지적됐다. “예를 들어 파일 이름과 경로의 무결성을 확인하지 않을 경우, 공격자는 환자의 의료 데이터의 내용을 몰라도 임의의 파일로 교체할 수 있게 됩니다. 그러면 해당 파일을 통해 잘못된 진단이 내려질 수 있고, 이는 환자의 생명을 위협하는 데에까지 이를 수 있습니다. 데이터도 중요하지만, 그 데이터를 담고 있는 스토리지를 보호하는 것도 데이터 보호에 있어서는 필수적인 요소라는 걸 클라우드 서비스들이 기억해야 합니다.”
클라우드에서 발견된 문제를 해결하기 위해 패치나 완화 조치를 배포하는 것 역시 난제 중 하나다. “클라우드에 호스팅 된 각종 데이터는 물론 프로그램들과의 호환성을 고려하며 패치나 완화 조치를 개발하는 것은 대단히 어려운 일입니다. 경우에 따라 클라이언트가 직접 파일을 복호화 했다가 다시 암호화 해야 하기도 합니다만, 데이터가 많으면 많을수록 이 과정은 긴 시간을 필요로 하게 됩니다. 한 연구에 따르면 1천 페타데이터의 데이터를 다시 암호화 하는 데에만 최소 6개월이 걸린다고 합니다. 심지어 인프라에 가해지는 과부하를 고려하지 않았을 때의 기간이 이 정도입니다. 이것을 클라이언트에게 요구한다는 건 서비스 제공업체로서 어려운 일이지요.”
그렇기에 클라이언트가 특정 파일에 접근할 때마다 해당 파일을 다시 암호화하도록 유도하는 ‘점진적 개선’ 방안이 고려되고 있기도 하다. 하지만 완벽한 해결책은 아니다. “나중에 가서는 이미 암호화 된 파일과 그렇지 않은 파일이 혼재되어 큰 혼란을 유발합니다. 클라이언트와 서비스 제공 업체 모두가 꼼꼼하게 관리할 수 있다는 전제가 필요합니다. 파일 암호화 확인을 위한 합리적인 체계가 마련되어야 하며, 여기에 모두가 동의해야 합니다. 그럼에도 모든 파일을 한꺼번에 다시 암호화 하는 것보다는 현실적입니다.”
그래서 결론은 무엇인가?
연구원들은 보고서를 통해 “이번 연구의 가장 큰 결론은 ‘서비스 제공 업체들이 시장에 광고하는 내용들이 실제로는 지켜지지 않고 있다’는 것”이라고 정리한다. 그럼에도 다섯 개의 모든 서비스가 동일한 수준의 허술함을 보이고 있는 건 아니라고 짚었다. “트레소릿의 경우 암호화 환경이 비교적 신중하게 설계되었습니다. 따라서 가장 안전하게 데이터를 보호하고 있었습니다. 다만 공개된 자료가 상당히 부족하고 암호화 설계 자체가 복잡하여 분석에 한계가 있었다는 것도 사실입니다.”
이런 현상이 나타나는 건 종단간 암호화 클라우드 서비스 업체들이 대체로 비윤리적이어서 그런 게 아니라고 연구원들은 강조했다. “암호화라는 기술 자체가 대단히 어렵다는 게 첫 번째 문제입니다. 암호화 기술을 익히는 것도 어려운데, 여러 암호화 기술들을 조합해 실제 서비스로 구현한다는 건 더더욱 어려운 일입니다. 어지간한 전문성만으로는 허점이 생길 수밖에 없고, 그것이 지금 나타나는 문제의 뿌리에 해당합니다. 다년간 연구로 습득한 이론적 기반이 없지 않는 이상 종단간 암호화 클라우드 서비스는 약점을 가질 수밖에 없습니다. 지금 업계 전체가 그런 상태라는 걸 알아낸 게 이번 연구의 의의라고 봅니다.”
종단간 암호화는 유용한 기술이다. 클라우드에 종단간 암호화를 접목하는 건 강력한 보안을 위해 존재해야만 하는 시도다. 다만 지금은 종단간 암호화나 클라우드나, 학문적으로 난이도가 높고 구현에 많은 비용이 들어가는 시기라는 게 문제다. “이러한 서비스나 산업 자체를 부정할 이유는 없습니다. 그들을 매도할 이유도 없습니다. 지금 암호화와 클라우드를 모두 섭렵하고 있는 전문가를 찾기가 너무 어려운 시기일 뿐입니다. 그래서 현재 상태로의 종단간 암호화 클라우드 서비스는 구멍투성이이고, 상당한 보완과 투자가 필요합니다.”
[국제부 문정후 기자(globoan@boannews.com)]
[보안뉴스 문정후 기자] 클라우드 서비스들 중 종단간 암호화를 전면에 내세우는 경우들이 있다. 사용자들은 소중한 데이터를 제3자인 클라우드 서비스에 저장해야 할 때, 바로 이런 ‘종단간 암호화’라는 약속을 믿고 안심할 수 있다. 하지만 최근 연구를 통해 일부 ‘종단간 암호화’ 클라우드 서비스들이 제대로 된 데이터 보호 성능을 갖추고 있지 않음이 드러났다. 심지어 문제가 있음을 알렸는데도 응답을 하지 않거나 보완할 필요가 없다고 대응한 업체들도 있었다.
[이미지 = gettyimagesbank]
종단간 암호화 클라우드 서비스들을 대상으로 보안 실태를 조사한 건 취리히공과대학의 연구원들이다. 이들은 보고서를 통해 싱크(Sync), 피클라우드(pCloud), 아이스드라이브(Icedrive), 시파일(Seafile), 트레소릿(Tresorit)이라는 서비스를 집중적으로 파헤쳤다고 밝히며 “이 서비스들의 보안 수준이 적절하지 못했다”고 밝혔다. “이 기업들은 총 2,200만 명의 고객을 보유하고 있으며, 종단간 암호화 클라우드(E2EE Cloud)라는 시장에서 꽤나 큰 영향력을 발휘하고 있습니다.”
종단간 암호화 클라우드?
이번 연구의 대상이 된 다섯 가지 클라우드 서비스는 클라우드 중에서도 ‘저장소’로 분류된다. 사용자들 대신 저장 인프라를 제공해주는 사업을 하고 있다는 뜻으로, 구글 드라이브, 아이클라우드, 원드라이브, 드롭박스 등이 대표적이다. 이런 서비스들에 등록된 사용자는 전 세계 40억 명이 넘는 것으로 알려져 있으며, 이런 서비스들에 저장된 데이터는 엑사바이트 단위라고 한다. 데이터 보호를 위해 암호화 기술을 채택하고 있는데, 종단간 암호화가 아니라 ‘저장된 상태에서의 암호화(Encryption at rest)’이다.
‘저장된 상태에서의 암호화’는 클라우드 업체 자체가 해킹당할 경우 데이터를 보호하지 못한다. 물론 아직까지 ‘메이저’ 클라우드 업체들이 해킹당해 고객 데이터를 잃은 사례는 없지만 그 어떤 조직이라도 해킹에 당할 가능성을 100% 배제할 수 없기 때문에 불안감을 표현하는 경우들이 있다. 그래서 일부 클라우드는 한층 더 강력한 암호화 기술인 종단간 암호화(E2EE)를 제공하기 시작했고, 자연스럽게 E2EE 클라우드 시장이 형성되기에 이르렀다.
“저장된 상태에서의 암호화는 암호화 키를 클라우드 제공 업체의 서버에 보관합니다. 그래서 회사가 해킹당하면 무용지물이 된다는 소리가 나오는 겁니다. 하지만 종단간 암호화는 서버가 아니라 사용자가 암호화 키를 관리하도록 되어 있습니다. 해커 입장에서는 암호화 키를 얻어내기 위해 수많은 고객들을 일일이 해킹해야 합니다. 따라서 공격 난이도가 높아집니다. 이 기술이 더 안전하다고 딱 잘라 말하기는 어렵습니다만, 이런 방식의 보호 기술을 더 선호하는 사용자들이 있는 것이 사실입니다.” 대표적으로 독일 및 세르비아 정부, 국제사면위원회 등과 같이 굵직한 조직들이 데이터 보호에 민감하며, 따라서 종단간 암호화를 더 선호하는 것으로 알려져 있다.
서비스 상세 보기 : 싱크
싱크는 2011년에 설립된 캐나다 회사다. 전 세계 200만 명 이상의 사용자를 보유하고 있다. 캐나다 정부, 토론토대학교, 캐나다 적십자 등이 주요 클라이언트로, 정보 보호에 민감한 사람이나 조직들이 이용한다는 인상을 주고 있다. 현재 130 페타바이트 이상의 데이터를 저장하고 있으며, 웹 애플리케이션과 데스크톱용 애플리케이션, 모바일용 클라이언트를 제공한다. 이번 분석에서는 웹 애플리케이션에 초점이 맞춰져 있다.
[이미지 = gettyimagesbank]
“싱크는 대칭 암호화로서는 AES-GCM을 사용하며, 비대칭 암호화로서는 PKCS1v1.5가 적용된 RSA를 사용합니다. 키 도출 함수로서는 12바이트의 무작위 솔트 값을 사용하는 PBKDF2-SHA256을 사용하고 있습니다.” 취리히공과대학 연구원들이 보고서를 통해 밝힌 내용이다. “등록 과정에서 클라이언트는 두 개의 값을 도출하고, 동시에 새로운 RSA 키 쌍을 생성합니다. 생성된 키 쌍은 다시 암호화 되는 등 여러 후속 과정을 거칩니다. 모든 암호문은 서버에 전송되고, 클라이언트가 로그인 할 때마다 암호문과 키 자료가 서버에서 확인되고 복호화 과정을 거칩니다.”
싱크는 링크나 폴더 공유 옵션을 통해 파일 공유를 가능하게 해 준다. “링크 공유의 경우, 해당 링크를 가진 사람만이 파일에 접근할 수 있게 됩니다. 이 링크를 생성하려면 사용자가 먼저 32자의 무작위 문자열을 가지고 비밀번호를 생성해야 합니다. 그런데 이 비밀번호가 공유 링크의 URL 경로의 일부로 편입됩니다. 이 때문에 링크만 가지고 있어도 어느 정도 비밀번호 파악이 가능하며, 따라서 파일에 접근하는 게 가능해집니다.”
서비스 상세 보기 : 피클라우드
스위스에 본사를 둔 피클라우드는 이번 실험 대상이 된 업체 중 가장 큰 규모를 자랑한다. 사용자도 1900만 명 이상인 것으로 알려져 있다. 가입할 때 사용자는 암호화 된 저장소에 접근하기 위한 추가 비밀번호를 설정해야 하는데, 이는 로그인 비밀번호와는 다른 역할을 한다. 이번 연구에서 집중적으로 분석된 것은 바로 이 추가 비밀번호였다고 연구원들은 밝혔다.
"피클라우드의 경우 암호화 하려는 데이터의 유형에 따라 상이한 대칭 암호화 방식을 사용합니다. 비대칭 암호화도 사용하는데, RSA와 OAEP를 활용하며, 해시 함수로는 SHA1을 채택하고 있습니다. 키 도출을 위해서는 64바이트의 무작위 솔트를 사용하는 PBKDF2-SHA512가 활용되고 있습니다.” 이는 피클라우드라는 회사의 암호화 방식을 나타내는 전반적인 설명이다. 연구원들은 계속해서 신규 등록 시 발생하는 일에 대해 상세히 설명했다.
“새 사용자가 등록하면 비밀번호 P를 사용해 32바이트 대칭 키 𝐾master와 16바이트 IVmaster를 도출합니다. 또한 RSA 키 쌍(sk, pk)이 생성되며, 개인 키는 𝐾master와 IVmaster로 암호화 됩니다. 사용자가 파일을 업로드할 때 클라이언트는 암호화된 개인 키(sk)를 서버로부터 가져와 비밀번호로 복호화하고, 인증되지 않은 공개 키(pk)를 서버에서 받아옵니다. 공개 키가 인증되지 않았으므로, 클라이언트는 개인 키와 공개 키의 일관성을 확인해야 합니다. 이를 위해 클라이언트는 32자리의 무작위 16진수 문자열을 추출한 후, 이를 공개 키로 암호화하고 개인 키로 복호화하여 원래의 문자열이 반환되는지 확인합니다.”
그런 방식으로 검증에 성공하면 클라이언트는 32바이트 대칭 암호화 키를 두 개 생성한다. 파일은 섹터 단위로 나눠지며, 각 섹터는 4096 바이트로 분할된다. 단 마지막 섹터의 크기는 본래 파일 크기에 따라 달라질 수 있다. 분할 과정을 통해 생성된 섹터는 개별적으로 암호화 되고, 이 과정에서 암호문과 태그가 생성된다. 파일 무결성을 보장하기 위한 조치가 반복해서 이뤄지며, 파일이 다운로드 될 때 이 조치들을 통해 무결성 검사가 이뤄진다.
서비스 상세 보기 : 아이스드라이브
아이스드라이브는 2019년에 출범한, 가장 연차가 짧은 업체로 현재 약 15만 명의 고객을 보유하고 있는 것으로 알려져 있다. 블록 암호로서 투피시(TwoFish)를 사용하는데, 아이스드라이브에 따르면 투피시가 AES/Rijndael보다 안전하다고 한다. “커스텀 블록 암호 모드를 사용할 때는 블록 암호화 기술을 활용해 암호화하고, 파일과 폴더 이름을 암호화 할 때는 표준 CBC 구조를 사용합니다. 키 도출을 위해서는 PBKDF2-SHA256을 사용합니다.”
아이스드라이브에서는 파일을 암호화 하기 전에 2MB의 파일 덩어리로 파일을 분할하며, 각 덩어리는 동일한 키로 암호화 된다. “그런데 이 과정에서 사용되는 요소 하나가 1234567887654321이라는 값을 가지고 있고, 이게 어떤 경우에도 변하지 않습니다. 따라서 파일 덩어리의 조건에 따라 파일의 유사성과 같은 특징을 높은 확률로 추측할 수 있게 됩니다.”
이 값이 변동되지 않는다고 하는데, 랜덤화 옵션이 사용되어 다른 문자열(숫자열)이 적용되는 경우도 있긴 하다고 연구원들은 설명을 잇는다. “하지만 활용되는 문자나 숫자가 제한적입니다. 정해진 범위 안에서만 랜덤화가 이뤄진다는 것이죠. 보안이 그만큼 허술할 수 있다는 뜻이 됩니다. 게다가 그 범위가 너무 좁아서 랜덤으로 만들어진 값이 서로 충돌할 가능성도 배제할 수 없습니다. 이 역시 문제로 이어질 가능성이 있습니다.”
서비스 상세 보기 : 시파일
시파일의 가장 큰 특징은 클라이언트와 서버의 코드가 오픈소스라는 것이다. 자체 서버를 호스팅하지 않고, 사용자가 직접 서버를 호스팅 할 수 있도록 지원한다. 이런 방법으로 시파일 서비스를 사용하는 사람들이 100만 명 이상이라고 한다. 주요 고객으로는 보안 업체 카스퍼스키(Kaspersky), 베를린훔볼트대학, 스트라스부르대학, 투르크대학 등이 있다. 이번 분석에서는 데스크톱 클라이언트에 초점을 맞췄다. 웹 인터페이스도 있긴 한데 종단간 암호화가 지원되지 않는다고 한다.
“시파일의 클라이언트는 암호화 프로토콜의 버전에 따라 다양한 암호화 기술을 채용합니다. 따라서 클라이언트는 아주 다양한 버전의 암호화 프로토콜을 지원하며, 그러므로 호환성 면에서 뛰어난 모습을 보입니다. 하지만 기본적으로는 오픈SSL(OpenSSL)의 바이츠투키(BytesToKey) 알고리즘을 기반으로 하여 해시 함수와 키 도출을 반복해 암호화 자료를 생성하는 방식을 취하고 있습니다.”
보고서에 의하면 시파일은 독립된 암호화 자료를 가진 여러 저장소루 구성된 스토리지 모델을 보유하고 있다고 한다. 사용자들은 저장소마다 다른 비밀번호를 설정하는데, 저장소 생성 시 “비밀번호를 통해 32바이트 대칭 키가 생성되고, 이 대칭 키는 또 다시 암호화를 거친 후에 서버로 전송된다.” 파일 암호화 전에는 중복 제거를 위해 덩어리별로 분할되며, 각 덩어리는 암호화 된다. “그런데 각 덩어리를 암호화할 때 사용하는 값을 변동하지 않으면 파일 덩어리 간 유사성이 의도치 않게 드러날 수 있습니다. 이런 위험성을 시파일도 내포하고 있는 것으로 분석됐습니다.”
서비스 상세 보기 : 트레소릿
2011년에 설립된 클라우드 스토리지로, 주로 기업 고객을 많이 보유하고 있다. 스위스의 업체가 대주주로 있으며, 기술 세부 내용이 담긴 백서를 발표한 적도 있다. 트레소릿은 위 업체들보다 훨씬 복잡한 암호화 구조를 가지고 있는 것으로 분석됐다. 비밀번호 복구, 사용자 계정에 대한 관리자 접근 등의 고급 기능을 제공하기 때문이다.
“트레소릿은 AES-GCM을 사용해 키 자료를 암호화 하며, 파일 암호화를 위해서는 AES OpenPGP 유형의 CFB 모드를 사용합니다. 이와 함께 HMAC-SHA512를 사용해 맥(MAC) 값을 생성하고, 비대칭 암호화로서는 RSA-OAEP를 사용합니다. 키 도출을 위해서는 스크립트(scrypt)와 PBKDF2를 통해 32바이트 솔트를 생성 및 적용합니다.”
트레소릿은 파일을 트레소(Tresor)라는 이름의 상위 폴도 단위로 구성하며, 각 폴더에는 그룹 키 파일이 하나씩 지정된다. 이 그룹 키 파일은 루트 디렉터리의 키를 포함하고 있으며, 대칭 키로 암호화 된다고 한다. “이 대칭 키는 다시 비대칭 키로 암호화 되며, 이는 다시 한 번 그룹으로 암호화 되어 사용자 프로필에 저장됩니다. 그룹 키 파일은 각 상위 폴더의 정보를 포함하며, 이 정보는 폴더 관련 데이터를 암호화 하는 데 사용됩니다.”
트레소릿의 모든 비대칭 키 자료는 인증 기관이 서명한 공개 키 인증서를 통해 인증된다. 클라이언트가 서버로부터 공개 키 자료를 요청할 때마다 인증서가 검증된다. 파일 공유 시 링크 공유와 폴더 공유의 두 가지 방법 중 하나를 선택할 수 있다. 이는 싱크 등 다른 서비스와 유사하다. 링크 공유를 할 때마다 16바이트 비밀이 생성되고, 이것을 바탕으로 고유 식별자가 생성된다. 이 고유 식별자를 통해 파일 이름과 내용의 복호화가 이뤄진다.
실험 결과, 종단간 암호화 클라우드에서 발견된 문제들
종단간 암호화를 제공하는 클라우드 서비스를 집중적으로 분석한 건 “서비스 제공 업체가 해킹을 당하는 상황에서도 데이터가 암호화 된 채로 안전하게 보호된다”는 이들 업체들의 약속이 제대로 지켜지는지 확인하기 위해서였다고 한다. “실제로 저희가 분석한 기업들은 이런 점을 강하게 홍보하고 있었거든요. 홍보한 내용이 사실인지 아무도 확인하지 않는 상황에서 저희가 나선 것이라고 할 수 있습니다.” 그래서 연구원들은 총 10가지 공격을 4가지 항목으로 나누어 실시해 다음과 같은 결과를 얻어낼 수 있었다.
[이미지 = gettyimagesbank]
1) 기밀성 침해 공격
- 싱크와 피클라우드의 경우, 공개 키로 암호화 된 암호문에 대한 인증 절차가 없어 공격자가 임의의 키를 주입하는 게 가능했다.
- 싱크와 트레소릿의 경우, 파일을 공유할 때 서버에서 제공하는 공개 키가 인증되지 않는다는 보안 문제가 발견됐다.
- 시파일의 경우, 공격자가 암호화 프로토콜을 다운그레이드 함으로써 사용자의 비밀번호를 추측할 수 있었다.
- 싱크의 경우, 파일 공유 시 링크에 암호가 포함되어 있어 기밀성이 쉽게 깨졌다.
2) 파일 데이터 무결성 공격
- 아이스드라이브와 시파일의 경우, 인증되지 않은 암호화 모드를 사용함으로써 파일 내용을 공격자가 조작하는 게 가능했다.
- 시파일과 피클라우드의 경우, 파일이 암호화 전에 여러 부분으로 나뉘는데(이를 파일 덩어리라고 한다) 이 과정이 인증되지 않아 각 파일 덩어리를 바꾸거나 제거하는 게 가능했다.
3) 메타데이터 공격
- 모든 서비스에서 파일 위치와 이름이 파일 내용과 연결되지 않았다. 그래서 공격자가 파일을 이동시키거나 이름을 바꾸는 게 가능했다.
- 모든 서비스에서 파일 크기, 파일 유형, 수정 날짜와 같은 메타데이터가 인증되지 않아 공격자가 이를 임의로 변경할 수 있었다.
- 파일 길이나 유사성, 디렉터리 구조 등 중요한 정보가 유출되는 경우가 많았다.
4) 파일 및 폴더 주입 공격
- 싱크의 경우, 공격자가 공유 메커니즘을 악용해 폴더를 사용자가 업로드한 것처럼 만들 수 있었다. 따라서 폴더 주입 공격이 가능했다.
- 피클라우드의 경우, RSA 암호문 인증 부재를 이용해 악성 파일 키와 내용을 사용자의 저장소에 주입하는 게 가능했다.
결국 거의 모든 종단간 암호화 클라우드 서비스가 광고하는 내용과 실제로 그들이 제공하는 서비스 사이에 큰 격차가 있음을 알 수 있었다고 연구원들은 강조했다. “종단간 암호화 클라우드 시스템에 근본적인 설계 결함들이 있었습니다. 그러므로 종단간 암호화로 데이터를 보호한다 치더라도, 종합적으로 안전한 환경을 제공하지는 못했습니다. 이는 클라우드 저장소 전반에 걸쳐 광범위하게 퍼져 있는 문제로 파악됩니다.”
현재 상황에 대한 종합적 진단
연구원들은 “대부분의 서비스에서 나타난 첫 번째 문제는 암호화 기본 요소의 오용”이라고 짚었다. “보안성이 불충분한 암호화 기본 요소를 사용하는 경우가 많았습니다. 예를 들어 아이스드라이브와 시파일에서 사용하고 있는 CBC 모드는 파일 데이터에 대한 보안을 어느 정도 제공하지만 무결성은 보장하지 않고 있었습니다. RSA 암호화 알고리즘에 OEAP를 적용하면 공개 키 암호화를 강력하게 하지만, 인증이라는 문제에 있어서는 취약할 수 있습니다. 위에 여러 번 적었지만 암호화 요소 하나를 고정적으로 사용하는 경우도 있었습니다.”
[이미지 = gettyimagesbank]
이 문제를 어떻게 해결해야 할까? 연구원들은 “보안에 대한 더 깊은 이해가 필요하다”고 말한다. “예를 들어 파일 데이터는 인증된 암호화 기본 요소를 사용하여 암호화 해야 합니다. RSA 암호문은 반드시 인증 과정을 더해야 한다는 점을 설계 과정에서부터 인지해야 합니다. 하지만 이런 이해도는 상당한 전문성을 필요로 하고 있으며, 기술적 구축을 위해서는 비용도 꽤나 들어갈 수 있습니다. 그럼에도 이것이 필요하다고 하는 건, 종단간 암호화 클라우드 서비스들이 자신들의 보안성을 계속해서 자랑하고 광고하고 있기 때문입니다. 그 정도로 광고하려면 이 정도의 전문성을 갖춰야 한다고 봅니다.”
파일 내용이 유출된다는, 말도 안 되는 문제가 발견되기도 했다. “종단간 암호화 클라우드를 사용하는 목적이 파일의 내용을 보호하는 것인데, 이런 기본마저 잘 지켜지지 않는 모습이 있었습니다. 시파일이나 아이스드라이브의 경우, 올바른 암호화 기본 요소를 사용하지 않고 있어서 종단간 암호화를 실시하긴 하나 파일 데이터의 패턴이 노출될 가능성을 품고 있습니다. 파일 내용이 직접 드러나는 건 아니지만 메타데이터 등의 ‘힌트’들을 얻어가는 게 가능하다는 겁니다. 이 역시 충분히 위험한 상황으로 이어질 수 있습니다.”
이는 대부분의 사람과 기업들이 메타데이터의 가치를 낮게 보기 때문에 발생하는 문제라고 연구원들은 진단한다. “메타데이터는 누군가의 삶에 대한 모든 것을 말해준다는 명언도 있습니다. 메타데이터를 충분히 갖게 된다면 데이터의 내용이 필요 없어질 때도 많습니다. 메타데이터의 중요성을 인정하는 전문가들이 있긴 하지만 대부분 보안 전문가들일 뿐입니다. 좀 더 많은 서비스 기획자와 개발자들이 메타데이터의 중요성을 인지해야 할 겁니다.” 하지만 인식 개선은 대단히 오래 걸리는 일이다. 그래서 연구원들은 “모든 메타데이터를 암호화 하여 서버가 사용자 스토리지의 구조를 알 수 없도록 해야 한다”고 제안하기도 했다.
스토리지의 무결성이 부족하다는 문제도 지적됐다. “예를 들어 파일 이름과 경로의 무결성을 확인하지 않을 경우, 공격자는 환자의 의료 데이터의 내용을 몰라도 임의의 파일로 교체할 수 있게 됩니다. 그러면 해당 파일을 통해 잘못된 진단이 내려질 수 있고, 이는 환자의 생명을 위협하는 데에까지 이를 수 있습니다. 데이터도 중요하지만, 그 데이터를 담고 있는 스토리지를 보호하는 것도 데이터 보호에 있어서는 필수적인 요소라는 걸 클라우드 서비스들이 기억해야 합니다.”
클라우드에서 발견된 문제를 해결하기 위해 패치나 완화 조치를 배포하는 것 역시 난제 중 하나다. “클라우드에 호스팅 된 각종 데이터는 물론 프로그램들과의 호환성을 고려하며 패치나 완화 조치를 개발하는 것은 대단히 어려운 일입니다. 경우에 따라 클라이언트가 직접 파일을 복호화 했다가 다시 암호화 해야 하기도 합니다만, 데이터가 많으면 많을수록 이 과정은 긴 시간을 필요로 하게 됩니다. 한 연구에 따르면 1천 페타데이터의 데이터를 다시 암호화 하는 데에만 최소 6개월이 걸린다고 합니다. 심지어 인프라에 가해지는 과부하를 고려하지 않았을 때의 기간이 이 정도입니다. 이것을 클라이언트에게 요구한다는 건 서비스 제공업체로서 어려운 일이지요.”
그렇기에 클라이언트가 특정 파일에 접근할 때마다 해당 파일을 다시 암호화하도록 유도하는 ‘점진적 개선’ 방안이 고려되고 있기도 하다. 하지만 완벽한 해결책은 아니다. “나중에 가서는 이미 암호화 된 파일과 그렇지 않은 파일이 혼재되어 큰 혼란을 유발합니다. 클라이언트와 서비스 제공 업체 모두가 꼼꼼하게 관리할 수 있다는 전제가 필요합니다. 파일 암호화 확인을 위한 합리적인 체계가 마련되어야 하며, 여기에 모두가 동의해야 합니다. 그럼에도 모든 파일을 한꺼번에 다시 암호화 하는 것보다는 현실적입니다.”
그래서 결론은 무엇인가?
연구원들은 보고서를 통해 “이번 연구의 가장 큰 결론은 ‘서비스 제공 업체들이 시장에 광고하는 내용들이 실제로는 지켜지지 않고 있다’는 것”이라고 정리한다. 그럼에도 다섯 개의 모든 서비스가 동일한 수준의 허술함을 보이고 있는 건 아니라고 짚었다. “트레소릿의 경우 암호화 환경이 비교적 신중하게 설계되었습니다. 따라서 가장 안전하게 데이터를 보호하고 있었습니다. 다만 공개된 자료가 상당히 부족하고 암호화 설계 자체가 복잡하여 분석에 한계가 있었다는 것도 사실입니다.”
[이미지 = gettyimagesbank]
이런 현상이 나타나는 건 종단간 암호화 클라우드 서비스 업체들이 대체로 비윤리적이어서 그런 게 아니라고 연구원들은 강조했다. “암호화라는 기술 자체가 대단히 어렵다는 게 첫 번째 문제입니다. 암호화 기술을 익히는 것도 어려운데, 여러 암호화 기술들을 조합해 실제 서비스로 구현한다는 건 더더욱 어려운 일입니다. 어지간한 전문성만으로는 허점이 생길 수밖에 없고, 그것이 지금 나타나는 문제의 뿌리에 해당합니다. 다년간 연구로 습득한 이론적 기반이 없지 않는 이상 종단간 암호화 클라우드 서비스는 약점을 가질 수밖에 없습니다. 지금 업계 전체가 그런 상태라는 걸 알아낸 게 이번 연구의 의의라고 봅니다.”
종단간 암호화는 유용한 기술이다. 클라우드에 종단간 암호화를 접목하는 건 강력한 보안을 위해 존재해야만 하는 시도다. 다만 지금은 종단간 암호화나 클라우드나, 학문적으로 난이도가 높고 구현에 많은 비용이 들어가는 시기라는 게 문제다. “이러한 서비스나 산업 자체를 부정할 이유는 없습니다. 그들을 매도할 이유도 없습니다. 지금 암호화와 클라우드를 모두 섭렵하고 있는 전문가를 찾기가 너무 어려운 시기일 뿐입니다. 그래서 현재 상태로의 종단간 암호화 클라우드 서비스는 구멍투성이이고, 상당한 보완과 투자가 필요합니다.”
[국제부 문정후 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-12-25] 
