iMessage는 얼마나 안전할까?

애플이 iOS에 대해 강조하는 장점중의 하나는 처음부터 보안을 중심에 두고 설계했다는 점입니다. iOS기기의 부팅이나 업데이트 과정은 각 단계마다 암호화(encryption)로 보호되어 혹시라도 악의적으로 수정된 iOS가 구동될 가능성을 차단하며 파일시스템 또한 암호화되어 탈취된 iOS기기의 플래시 메모리칩을 뜯어내더라도 내용을 알 수 없습니다. 뿐만 아니라 iOS앱들은 sandboxing에 의해 동작에 필요한 최소한의 권한과 자원만을 할당 받음으로써 사용자 모르게 iOS기기의 데이터에 접근할 수 없습니다. 이에 더해 A시리즈 SoC(System-on-Chip)에는 다양한 전용회로와 프로세서가 추가되어 iOS에 구현된 암호화 기술들이 원활하게 동작할 수 있게합니다. 보안을 강조하는 애플답게 iOS의 메시징 서비스인 iMessage에도 강력한 암호화 기술들을 적용하였는데 이번 글에서는 iMessage의 보안이 어떻게 동작하는지 살펴보고 잠재적 약점에 대해서도 간단히 살펴보겠습니다.

암호화 키(key)생성 및 관리

애플에서 공개한 “iOS Security” 문서에 따르면 iMessage를 통해 전송되는 메시지는 암호화되어 주고받는 당사자를 제외하고는 애플조차 내용을 알 수 없다고 되어있습니다. 이를 구현하기 위해 RSA 암호화와 ECDSA(Elliptic Curve Digital Signature Algorithm) 알고리즘이 각각 암호화와 디지털 서명을 위해 사용됩니다. 암호화는 메시지의 내용을 감추기 위해, 디지털 서명은 메시지를 보내는 사람의 신원을 보증하기 위해 필요한데 RSA/ECDSA 두 방식 모두 공개키(public key)와 비밀키(private key)쌍을 가지는 비대칭키 암호화 방식입니다.

최초 iMessage 사용을 개시할 때 각 iOS 기기마다  RSA/ECDSA를 위한 두 쌍의 공개키와 비밀키가 생성되는데, 아래 그림과 같이 사용자 A와 B의 iOS기기에서 공개키/비밀키 쌍이 생성되었다면 이 중 공개키는 애플이 운영하는 IDS(Apple’s Directory Service)에 등록됩니다. IDS에 등록된 공개키는 A나 B에게 iMessage를 보내려는 상대방이라면 누구나 가져와 사용할 수 있습니다. 반면 A와 B의 비밀키는 애플의 서버로 보내지지 않고 기기내의 안전한 장소에 보관되어 누구도 알 수 없습니다.

RSA암호화 알고리즘은 아주 큰 수의 소인수분해가 어렵다는 성질을 이용하고 있는데 아주 큰 소수 두개(p, q)와 이의 곱 n(=p*q)을 바탕으로 유도된 암호화/복호화 지수(e/d) 를 이용하여 공개키 {e, n} 과 비밀키 {d, n}을 만들어 냅니다(관련 링크). 공개키와 비밀키에 대해서는 아래의 성질이 알려져 있습니다.

• 공개키로 암호화한 내용은 비밀키로만 복호화 가능 (공개키로는 복호화 불가)
• 비밀키로 암호화한 내용은 공개키로만 복호화 가능 (비밀키로는 복호화 불가)
• 아주 큰 수 n에 대해 공개키를 통해 비밀키를 추측하기는 거의 불가능에 가까움

이 중 첫 번째 성질 때문에 iMessage를 보내는 기기에서는 상대방의 공개키를 사용하여 보낼 메시지를 암호화하기만 하면 원하는 상대방 이외에는 보내는 메시지의 내용을 볼 수 없음이 보장 됩니다. 공개키/비밀키 쌍은 각 기기마다 생성되기 때문에 iMessage를 받을 상대가 iPhone, iPad, Mac 컴퓨터 등 여러대의 기기를 가지고 있다면 보내는 기기에서는 각 기기에 해당하는 여러개의 공개키들을 가져와 같은 내용을 각각 다른 공개키로 암호화하여 여러 번 전송하게 됩니다. 세번째 성질과 관련하여 iMessage는 1280-bit의 RSA키를 사용하는데, 현재의 컴퓨팅 성능으로는 2의 1280승에 달하는 큰 수를 유의미한 시간안에 인수분해하기가 힘들기 때문에 안전성이 보장됩니다.

ECDSA의 경우도 앞에서 설명한 첫번째 두번째 성질은 동일하며 RSA와의 차이점은 큰 수의 소인수분해가 힘들다는 성질을 이용하는 것이 아니라 타원 곡선에서의 이산 대수문제를 풀기 힘들다는 성질을 이용한다는 점입니다 (관련 링크). ECDSA의 경우 RSA에 비해 짧은 키 길이를 사용하더라도 동일한 수준의 보안성을 달성할 수 있음이 알려져 있어 ECDSA키는 RSA의 1280-bit 보다 짧은 256-bit 길이를 가집니다.

iMessage 암호화 방식

설명을 위해 A가 B에게 iMessage를 보내는 상황을 가정해 보도록 하겠습니다. A는 보낼 메시지를 B의 RSA 공개키를 사용하여 암호화하는 것에 더해 자신이 보낸 메시지가 전송 과정에서 변경되지 않았고, C나 D 등의 다른 사람이 아닌 A가 보냈다는 것을 증명(서명)할 필요가 있습니다. 이를 위해 SHA-256/SHA-1해쉬(hash)가 ECDSA와 함께 사용되는데 자세한 내용을 살펴보도록 하겠습니다.

먼저 메시지가 전송도중에 변형 되지 않았음을 보증하기 위해 iMessage는 SHA-256 해쉬를 사용합니다. SHA-256 해쉬는 가변적인 길이의 데이터를 입력으로 받아 고정된 길이의 출력을 계산해내는데, 입력 데이터가 1-bit이라도 달라지면 결과가 크게 달라지는 성질이 있습니다. A는 B에게 메시지를 보낼 때 A와 B의 공개키, 그리고 보낼 메시지를 입력으로하여 40-bit의 SHA-256 값을 계산합니다. A는 계산된 SHA-256 해쉬값을 보낼 메시지와 함께 B의 RSA 공개키로 암호화하여 전송하는데, B는 RSA 개인키를 통해 받은 메시지를 복호화한 후 자신과 A의 공개키, 복호화한 메시지를 입력으로 다시 40-bit의 SHA-256 해쉬값을 계산해 봅니다. 메시지와 함께 전송된 SHA-256 결과가 B가 계산한 SHA-256 해쉬값과 일치한다면 B는 A가 보낸 메시지가 전송과정에 변경되지 않았음을 알 수 있습니다.

SHA-256 해쉬의 결과값 40-bit은 A가 보내는 메시지의 내용이 변경되지 않았음을 보증하는 용도 이외에도 iMessage의 가변적인 길이에 대응하는 용도로도 사용됩니다. 위의 그림과 같이 iMessage를 보낼 때 마다 생성되는 88-bit의 무작위 값과 합쳐져 128-bit의 AES(Advanced Encryption Standard)의 암호화키가 생성되는데 이는 iMessage의 길이가 1280-bit의 RSA 공개키로 암호화 할 수 있는 크기를 넘어갈 때를 대비한 것입니다. 아래 그림과 같이 1280-bit RSA 암호화를 수행할 경우 AES키와 OAEP(Optimal Asymmetric Encryption Padding) 값을 제외하면 808-bit을 iMessage 내용 전송을 위해 사용할 수 있는데, 이를 초과하는 부분은 RSA에 의해 암호화 될 부분에 포함된 128-bit AES키로 암호화 됩니다. iMessage의 길이가 길어질 경우 메시지의 후반부는 암호화 강도가 약해지는 약점이 있는 것이지요.

메시지 내용의 암호화가 완료되면 A가 메시지를 보냈음을 보증하기 위해 디지털 서명을 작성할 차례인데 위의 그림과 같이 RSA로 암호화된 1280-bit의 데이터, 그리고 길이가 가변적인 AES로 암호화된 데이터를 입력으로 SHA-1 해쉬를 계산합니다. SHA-1해쉬도 SHA-256해쉬와 마찬가지로 내용에 변경이 있었는지를 확인하는 용도로 사용됩니다. SHA-1해쉬를 계산한 결과는 A의 ECDSA의 개인키로 암호화되어 디지털 서명으로 사용되는데 A의 ECDSA 공개키로만 복호화가 가능하기 때문에 A가 보낸 메시지임이 보장됩니다. 암호화와 서명이 완료된 iMessage 데이터는 애플의 푸쉬 서버인 APNs(Apple Push Notification Service)를 통해 B에게 전달되며 각 애플기기와 APNs 사이의 연결은 TLS(Transport Layer Security) 채널을 통해서 보호됩니다.

간단히 설명해 보려고 노력해 봤습니다만 iMessage의 암호화 구조는 상당히 복잡한데, 보다 자세한 내용이 궁금하실 경우 최근에 발표된 논문 [1]을 참고하시기 바랍니다.

iMessage의 첨부파일 암호화

iMessage를 전달하는 APNs의 경우 한번에 최대 16KB 까지만 전송이 가능하기 때문에 동영상, 사진 등의 첨부 파일은 텍스트 메시지와는 다른 방식으로 전달됩니다. 첨부 파일 전달을 위해서는 iCloud 서버를 이용하는데 메시지를 보낼 때 마다 기기에서 무작위로 AES 256-bit 암호화키를 생성한 후 이 키를 이용하여 암호화한 첨부파일을 iCould 서버에 올리게됩니다. 받을 사람에게는 iCloud 서버로 부터 해당 파일을 다운로드 받을 수 있는 링크와 AES 암호화 키를 앞에서 설명한 텍스트 메시지를 보내는 방법으로 암호화하여 전달하는데, 이러한 방식을 사용하면 텍스트 메시지와 마찬가지로 애플은 주고받는 첨부파일의 내용을 알 수 없습니다. 아래 그림은 “iOS Security” 문서에 포함된 그림인데, 지금까지 설명한 내용을 간단히 요약하고 있습니다.

출처 – Apple, “iOS Security – iOS10”

잠재적 약점들

iMessage의 암호화 동작 방식을 살펴 보았으니 iMessage의 잠재적 약점들을 살펴 보면서 글을 마무리 하도록 하겠습니다. 제가 보안 전문가가 아니라서 각 약점들이 얼마나 위협적인지는 파악하기가 힘듦니다만 글을 쓰기 위해 자료를 찾아보면서 iMessage의 보안이 일반적인 공격에 대해서는 안전한 편이지만 100% 완벽하지는 않다는 정도의 느낌을 받았습니다.

첫번째는 논문 [1]에 자세히 설명된 문제인데 iMessage의 메시지 내용이 길어지면 후반부가 RSA보다 보안성이 떨어지는 AES 암호화로 보호되는 약점을 이용하여 chosen ciphertext attack을 통해 제 3자가 iMessage 첨부 파일의 내용을 볼 수 있다고 합니다. 다행히 해당 문제는 iOS 9.3 이후로는 고쳐졌다고하니(관련 링크) 혹시나 아직 iOS 9.3 이하의 버전을 사용하고 계신다면 iOS 업데이트를 권장합니다.

두 번째는 잠재적인 위협에 관한 내용인데 iOS기기의 key chain 관리에서 certificate pinning 과정이 빠져 있어 iOS기기에 악의적인 certificate을 설치한 후 제 3자가 중간에 끼어들어 Man-in-the-Middle attack을 하더라도 알아차리기 어렵다는 내용이 있습니다 (관련 링크). 다만 이 문제에 관련된 글은 2013년에 쓰여졌고 2016년 WWDC 자료를 보면 “Certificate Transparency”라는 이름으로 certificate pinning을 구현하고 있어 해당 문제에 대한 걱정은 줄어든 것으로 보입니다.

제가 찾아본 마지막 자료는 iMessage의 공개키를 애플의 IDS에 등록하는 과정과 관련된 것인데, 여러개의 기기를 소유한 사용자의 공개키 묶음에 공격자의 공개키를 포함시켜 의도치 않은 사람에게도 메시지가 전달될 가능성에 관한 것입니다 (관련 링크). 이 가능성에 대해서는 자세한 설명이 없어 그럴수도 있겠다 정도만 생각하는 것이 좋을 것 같습니다.

References

[1] Christina Garman, et al., “Dancing on the Lip of the Volcano: Chosen Ciphertext Attacks on Apple iMessage”, 25th Usenix Security Symposium, 2016.