클라우드에 저장되는 가치 있는 데이터가 늘어나는 만큼 이를 견고하게 보호하는 일이 더욱 중요해집니다. iCloud 같은 클라우드 데이터 서비스에 강력한 보안 조치가 갖춰지면 최종 사용자, Apple 같은 클라우드 서비스 제공업체, Reincubate 같은 생태계 플랫폼 모두에게 이롭습니다.
이 데이터를 보호하는 방식은 여러 형태가 있으며, 이를 구현해 온 Apple의 실적은 좋은 편입니다. 이 글에서는 Apple과 Reincubate 팀이 사용해 온 여러 기법을 살펴봅니다.
가능하면 적게 저장하기
첫째, _많이 저장하기보다 적게 저장하는 것_이 효과적입니다. 사진 앱의 얼굴 인식 데이터가 iCloud 사진 보관함에 저장되지 않고 로컬에 캐시되는 것처럼, 처음부터 iCloud에 저장되지 않는 데이터가 그 예입니다. Apple의 HealthKit, HomeKit, TouchID에서 나오는 데이터 결과물도 비슷하게 다뤄지며, Android의 잠금 화면 얼굴 인식 데이터도 마찬가지입니다. 물론 이는 편의성과, 기기 간에 데이터를 동기화하는 가치 사이의 절충인 경우가 많습니다. 일부 시스템은 부분적인 방식을 씁니다. 예를 들어 iMessage는 제한된 양의 콘텐츠를 클라우드에 저장하고, 나머지 데이터는 기기 간 직접 동기화에 의존합니다.
Telegram이나 WhatsApp 같은 보안 메시징 시스템은 완전히 다른 방식을 취합니다. 서버에 저장되는 데이터가 없거나 있어도 많지 않기 때문에, 사용자가 의미 있게 백업하고 복원하려면 기기 백업에 풍부한 데이터가 포함되어야 합니다. 어떤 면에서 보안을 유지하기 위해 이런 앱 개발사는 데이터 관리에서 손을 떼고 이를 최종 사용자에게 맡기는 셈이며, 최종 사용자는 기기를 로컬에 또는 클라우드에 백업하도록 선택할 수 있습니다.
이렇게 양극단이 존재합니다. 클라우드에는 거의 없고 모든 것이 백업에 들어 있는 WhatsApp과, 클라우드에서 쉽게 이용할 수 있고 Facebook이 웹 인터페이스를 제공하려면 그래야 하기 때문에 기기 백업에는 아무것도 저장하지 않는 Facebook Messenger를 대조해 볼 수 있습니다.
여기에 정답은 없지만 생각해 볼 만한 문제입니다. 이 데이터를 호스팅하는 앱을 사용하려면 앱 개발사가 이를 안전하게 관리해야 하는데, 사용자는 무엇이 어떻게 저장되는지 알지 못하는 경우가 많습니다. 데이터를 중앙에 저장하지 않는 앱을 사용하면 최종 사용자가 자신의 백업 데이터 보안에 책임을 져야 합니다. iCloud 백업과 Google의 Android 7.0 이상 기기 백업처럼 플랫폼의 클라우드에 저장되도록 맡기는 경우는 예외입니다.
흥미롭게도 아래 차트처럼 일부 앱 제작사는 이 양극단을 모두 차지합니다. Snapchat 앱은 거의 모든 데이터를 클라우드에 저장하지만, 앱의 물리적 확장 제품인 Spectacles는 모든 데이터를 기기에 로컬로 저장합니다.
앱 데이터 보안에 대한 다양한 접근 방식
널리 보급되지는 않았지만 Snapchat Spectacles는 상당히 안전하지 않습니다. “스냅” 버튼을 7초 동안 누르고 있으면 해커가 새 휴대폰과 페어링해 정당한 소유자가 저장해 둔 암호화되지 않은 스냅을 가져갈 수 있습니다. 이는 Apple Watch에 적용된 보안 원칙과 뚜렷한 대조를 이룹니다.
강력한 암호화
이는 두 번째 핵심 기법인 강력한 암호화, 그중에서도 키를 불완전하게 저장하는 방식으로 이어집니다. 기기가 파손되거나 교체될 때 접근할 수 있는 방식으로 백업하기에는 데이터가 지나치게 민감하다고 판단되면, 다른 기법을 사용할 수 있습니다. Facebook의 “Secret Conversations” 기능은 특정 기기의 사용을 요구함으로써 하드웨어 식별자를 이용해 콘텐츠를 암호화합니다. 기기를 분실하면 콘텐츠는 사실상 복구할 수 없게 됩니다.
일부 시스템은 한 번에 제한된 수의 기기만 콘텐츠에 접근할 수 있도록 _기기별 토큰_을 만드는 비슷한 기법을 사용합니다. Snapchat과 WhatsApp은 각각 이를 변형해 사용합니다. 기기에서 Snapchat에 로그인하면 토큰이 만들어져 Snapchat 서버와 기기가 공유합니다. 같은 사용자가 다른 기기에 로그인하면 새 토큰이 만들어져 클라우드에 있던 이전 토큰을 대체하고, 첫 번째 기기는 들어오는 메시지를 복호화할 수 없으므로 로그아웃됩니다. 이 기법을 안전하지 않은 시스템에서 사용하면 토큰을 복사해 다른 곳에서 쓸 수 있다는 명백한 취약점이 있습니다. 루팅된 Android나 탈옥된 iOS 기기를 사용하는 것이 왜 끔찍한 생각인지 설명할 근거가 필요하다면 바로 이것이며, Snapchat용 웹 클라이언트가 가까운 시일 내에 나오기 어려운 이유도 설명해 줍니다.
비밀 Facebook 메시지를 잃을 수 있다는 것과는 별개로, 일부 데이터는 매우 민감하면서 동시에 소유자에게 매우 가치가 큽니다. 직관에 어긋나 보이지만 데이터의 개인적 가치가 충분히 크면, 이를 복호화하거나 복구할 수 있는 방법이 여러 가지가 되도록 저장하는 경우가 많습니다. 이는 보안을 어느 정도 포기하는 대신 비현실성을 줄이는 절충입니다. 예를 들어 iCloud와 Google 계정에는 방대한 데이터가 연결되어 있고, 두 경우 모두 사용자의 모든 비밀번호를 저장하는 일종의 분산 클라우드 키체인이 포함됩니다. 뿐만 아니라 Google이 OAuth로 자사 계정을 다른 사이트의 인증 수단으로 내세우고 있어서, 이런 계정에 대한 접근을 돌이킬 수 없이 잃는다면 감당하기 쓰라린 일이 될 것입니다.
이러한 계정은 영구적으로 잃을 위험을 쉽게 감수하기에는 너무 가치가 크다고 여겨지므로, 데이터는 클라우드에 저장하되 사용자만 가지고 있고 저장되지 않는 토큰이나 비밀번호로 암호화하는 절충안이 사용됩니다. 예를 들어 Google Chrome 브라우저를 새로 설치하고 로그인하면, 보조 동기화 비밀번호를 브라우저에 입력하기 전에는 클라우드에 저장된 비밀번호를 사용할 수 없는 이유입니다.
암호화의 부담 나누기
보안에 대해 진지하고 근본적으로 옳은 Apple의 Tim Cook은 바로 작년에 이 기법에 대한 신념을 이렇게 밝혔습니다.
For many years, we have used encryption to protect our customers’ personal data because we believe it’s the only way to keep their information safe. We have even put that data out of our own reach, because we believe the contents of your iPhone are none of our business.
— Tim Cook, “A Message to Our Customers”
무엇보다 이는 클라우드 제공업체가 정부 기관에 전체 사용자 데이터를 공개하는 일을 피하는 데 도움이 됩니다. 영장에 따라 제공해야 하더라도 사용자의 데이터를 직접 노출하지 않고 제공할 수 있습니다. 데이터에는 추가 복호화가 필요하고, 이는 최종 사용자만 가진 키로만 할 수 있기 때문입니다.
다중 인증(MFA), 이중 인증(2FA), 2단계 인증(2SV)의 경우처럼, 추가 키가 특정 기기로만 전송되거나 그 기기에서만 생성될 수 있다는 의미일 때도 있습니다. 은행과 VPN은 시간 기반 일회용 비밀번호 생성기(OTP 또는 TOTP)의 한 형태인 물리적 카드 리더나 보안 시드 생성기를 자주 사용합니다. Google과 Apple은 모두 간단한 SMS 기반 MFA와 완전한 2FA 시스템을 제공하며, Google은 HOTP/OATH를, Apple은 독자 방식을 사용합니다.
보안 기관이나 법 집행 기관(LEA)이 암호화된 데이터는 가졌지만 이를 복호화할 최종 사용자 키가 없는 경우, 강력한 장비로 자동으로 추측한 비밀번호를 대입해 보는 무차별 대입 공격을 시도할 수 있습니다. 여기서 Apple의 iOS는 Google의 Android보다 큰 이점이 있습니다. Apple은 기기의 하드웨어를 엄격히 통제하므로 자사 하드웨어만 빠르게 수행하고 데스크톱 컴퓨터 같은 다른 기기는 느리게 수행하는 암호화 기법을 설계할 수 있습니다. Reincubate가 세계 최초로 10.2 데이터의 복호화를 지원했을 때, 중요한 점은 10.2의 작동 방식을 가장 먼저 이해했다는 것만이 아니었습니다. Apple의 영리한 기법을 빠르게 대규모로 복호화하는 데 처음 성공했다는 점이었습니다. 일반적인 하드웨어에서 복호화를 한 번 시도하는 데 몇 초가 걸리도록 만들어, 해커나 LEA가 무차별 대입을 하기에는 현실성이 없어졌습니다.
모호함을 통한 보안
Apple이 특히 잘하는 기법인 모호함을 통한 보안을 다루지 않고 이런 기법들을 검토할 수는 없습니다. 공개 API, 상세한 문서를 공개하지 않고 이런 시스템에 대해 거의 이야기하지 않음으로써, 회사는 해커에게 잠재적인 공격 경로를 알리는 일을 피할 수 있습니다. 오랫동안 모호함에 반대하는 논거는 공개와 오픈 소스가 더 나은 보안 결과로 이어진다는 것이었지만, 이는 2014년에 거의 모든 곳에서 사용하는 핵심 오픈 소스 보안 라이브러리인 OpenSSL이 근본적으로 안전하지 않았고 거의 줄곧 그랬다는 사실이 밝혀지기 전의 이야기입니다.
앱 또는 클라우드 데이터를 다루는 방법을 함께 알아보고 싶거나 다양한 접근 방식의 역학을 더 잘 이해하고 싶으시다면 문의해 주세요.
