광고 닫기

iMessage를 통해 메시지를 보내는 것은 iOS 장비와 Mac 컴퓨터 간에 널리 사용되는 통신 방법입니다. 매일 수천만 개의 메시지가 Apple 서버에서 처리되며, Apple 기반 장치의 판매가 증가함에 따라 iMessage의 인기도 높아지고 있습니다. 하지만 잠재적인 공격자로부터 메시지가 어떻게 보호되는지 생각해 본 적이 있나요?

애플이 최근 출시한 문서 iOS 보안을 설명합니다. 시스템, 데이터 암호화 및 보호, 애플리케이션 보안, 네트워크 통신, 인터넷 서비스 및 장치 보안 등 iOS에서 사용되는 보안 메커니즘을 훌륭하게 설명합니다. 보안에 대해 조금 이해하고 영어에 문제가 없다면 20페이지에서 iMessage를 찾을 수 있습니다. 그렇지 않다면 iMessage 보안의 원리를 최대한 명확하게 설명하려고 노력하겠습니다.

메시지 전송의 기본은 암호화입니다. 일반인의 경우 이는 키로 메시지를 암호화하고 수신자가 이 키로 메시지를 해독하는 절차와 관련되는 경우가 많습니다. 이러한 키를 대칭이라고 합니다. 이 과정에서 중요한 점은 키를 수신자에게 전달하는 것입니다. 공격자가 이 정보를 확보한 경우 메시지를 해독하고 수신자를 가장할 수 있습니다. 단순화하기 위해 열쇠 하나만 들어갈 수 있는 자물쇠가 달린 상자를 상상해 보세요. 이 열쇠를 사용하면 상자의 내용물을 넣고 꺼낼 수 있습니다.

다행스럽게도 공개 키와 개인 키라는 두 가지 키를 사용하는 비대칭 암호화가 있습니다. 원칙은 모든 사람이 공개 키를 알 수 있다는 것입니다. 물론 개인 키는 본인만이 알고 있습니다. 누군가 당신에게 메시지를 보내려고 하면 당신의 공개 키로 메시지를 암호화할 것입니다. 그러면 암호화된 메시지는 개인 키로만 해독될 수 있습니다. 단순화된 방식으로 다시 사서함을 상상해 보면 이번에는 두 개의 자물쇠가 있을 것입니다. 공개 키를 사용하면 누구나 잠금을 해제하여 콘텐츠를 삽입할 수 있지만, 개인 키를 가진 사용자만 선택할 수 있습니다. 확실히 하기 위해 공개 키로 암호화된 메시지는 이 공개 키로 해독할 수 없다는 점을 덧붙이겠습니다.

iMessage의 보안 작동 방식:

  • iMessage가 활성화되면 데이터를 암호화하기 위한 1280b RSA와 도중에 데이터가 변조되지 않았는지 확인하기 위한 256b ECDSA라는 두 개의 키 쌍이 장치에 생성됩니다.
  • 두 개의 공개 키는 Apple의 IDS(디렉터리 서비스)로 전송됩니다. 물론 두 개의 개인 키는 장치에만 저장되어 있습니다.
  • IDS에서 공개 키는 APN(Apple 푸시 알림 서비스)의 전화번호, 이메일 및 장치 주소와 연결됩니다.
  • 누군가가 당신에게 메시지를 보내고 싶다면, 그 사람의 IDS 장치는 당신의 공개 키(또는 여러 장치에서 iMessage를 사용하는 경우 여러 공개 키)와 장치의 APN 주소를 알아낼 것입니다.
  • 그는 128b AES를 사용하여 메시지를 암호화하고 개인 키로 서명합니다. 메시지가 두 개 이상의 장치에 전달되는 경우 메시지는 각 장치에 대해 별도로 Apple 서버에 저장되고 암호화됩니다.
  • 타임스탬프와 같은 일부 데이터는 전혀 암호화되지 않습니다.
  • 모든 통신은 TLS를 통해 이루어집니다.
  • 더 긴 메시지와 첨부 파일은 iCloud의 임의 키로 암호화됩니다. 이러한 각 개체에는 고유한 URI(서버에 있는 항목의 주소)가 있습니다.
  • 메시지가 모든 장치에 전달되면 삭제됩니다. 귀하의 장치 중 하나 이상에 전달되지 않으면 서버에 7일 동안 남아 있다가 삭제됩니다.

이 설명이 복잡해 보일 수도 있지만, 위의 그림을 보시면 원리를 확실히 이해하실 수 있을 것입니다. 이러한 보안 시스템의 장점은 외부로부터의 무차별 대입 공격만 가능하다는 점이다. 현재로서는 공격자가 점점 더 똑똑해지고 있기 때문입니다.

잠재적인 위협은 Apple 자체에 있습니다. 이는 그가 키의 전체 인프라를 관리하므로 이론상으로는 예를 들어 법원 명령에 따라 들어오는 메시지를 해독할 수 있는 다른 장치(공용 및 개인 키의 또 다른 쌍)를 귀하의 계정에 할당할 수 있기 때문입니다. 그러나 여기서 Apple은 그러한 일을 하지 않으며 앞으로도 하지 않을 것이라고 밝혔습니다.

자료 : 테크 크런치, iOS 보안(2014년 XNUMX월)
.