WWDC 주간이다. Apple 쪽 이야기 한 번 시작하면 컴파일러부터 앱 프레임워크까지 너무 이야기할 게 많아서 (...) 웬만하면 다루지 않으려 했는데, iOS 13의 API 변경사항 체인지로그를 읽다가 상당히...

Gepostet von Daniel Hong am Mittwoch, 5. Juni 2019

WWDC 주간이다. Apple 쪽 이야기 한 번 시작하면 컴파일러부터 앱 프레임워크까지 너무 이야기할 게 많아서 (...) 웬만하면 다루지 않으려 했는데, iOS 13의 API 변경사항 체인지로그를 읽다가 상당히 재미있는 걸 발견했다.

https://developer.apple.com/documentation/cryptokit

iOS 13과 macOS 10.15 (Catalina), tvOS 13, 그리고 릴리즈 버전의 Mac용 UIKit SDK에서는 CryptoKit이라는 새로운 API 세트가 추가되었다. 이름부터 뭔가 심상치 않다. 좀 더 자세히 살펴보자.

베타 개발자 문서를 보면, CryptoKit에 관해 이렇게 설명되어 있다.
"자주 쓰이는 일부 암호화 작업을 수행하는 데에 Apple CryptoKit을 사용할 수 있습니다. 1. 안전한 메시지 다이제스트 (해시값)을 계산하고 비교. 2. 공개키 암호화를 사용한 전자서명의 생성 및 검증, 그리고 키 교환 수행. 메모리에 저장되어 있는 키뿐만 아니라, *Secure Enclave에 의해 저장되고 관리되는 키도 사용할 수 있습니다.* 3. 메시지 인증 및 암호화와 같은 작업 수행에 사용될 수 있는 대칭키 생성. 저수준 (low-level) 인터페이스 대신 CryptoKit을 우선적으로 사용하십시오. CryptoKit을 사용하면 직접적인 메모리 포인터를 다루지 않아도 될 뿐만 아니라, 메모리 할당 해제 시 민감한 정보를 자동으로 덮어씌우는 등 당신의 앱을 더 안전하게 만들어 줍니다."

사용 가능한 인터페이스들을 살펴보면, 실제로 고수준 암호화 및 서명에 자주 쓰이는 알고리즘들은 거의 다 구현해 놓았다. SHA512/384/256 등 SHA-2 계열은 물론, HMAC와 대칭키, AES, ChaCha20-Poly1305 (ChaChaPoly), 심지어는 X25519 디피-헬먼 키 교환/ed25519 서명을 포함한 타원곡선 암호 (ECC) 알고리즘까지 있다. 이러한 알고리즘들이 미리 다 구현되어 있으니, 안전하지 않은 암호화 구현체로 인해 보안취약점이 발생할 가능성은 현저히 낮아졌다고 볼 수 있겠다. 개발자가 직접 성가신 암호화 코드를 건드리지 않아도 되는 건 물론이고.

다만 내가 개인적으로 주목하는 부분은 따로 있다. 바로 Secure Enclave에 대한 고수준의 API 접근권한이 주어졌다는 것이다. Secure Enclave를 개발자가 직접 다룰 수 있다는 것은, 메인 프로세서의 메모리 영역에서 암/복호화를 직접 수행하는 것과는 차원이 다른 수준의 보안을 구현할 수 있다는 의미이기 때문이다.

Secure Enclave는 애플의 A7 이상 SoC에 탑재되는 보안 코프로세서다. A7 또는 그 이후 칩을 탑재한 iOS 기기에서는 모두 사용 가능하며, 2018년 이후 출시된 MacBook Pro/MacBook Air/Mac mini/iMac Pro 등 T2 칩이 탑재된 Mac에서도 사용할 수 있다. 이 코프로세서는 시스템 레벨에서 보호되는 데이터 (Touch ID와 Face ID 데이터, Apple Pay 카드 토큰, 심지어는 기기 전체의 저장소를 암호화하는 키까지)에 대한 암/복호화 연산을 모두 직접 수행한다. (Apple Pay의 경우 Secure Element라 불리는 별도의 Java Card 호환 장치에 결제 토큰을 저장하고, 결제 요청에 대한 서명 및 승인만 Secure Enclave를 거치도록 하는 (...) 별도의 아키텍처를 채택하고 있어 다소 구성이 다르기는 하다.)

명목상 SoC 내에 존재하는 코프로세서의 형태이기는 하나, Secure Enclave는 사실 메인 시스템과 물리적으로 완전히 격리된 별도의 서브시스템이다. Secure Enclave OS라는 별도의 운영체제와 Secure Enclave Boot ROM까지 갖추고 있으며, 메인 시스템과는 다르게 L4 마이크로커널 기반으로 커스텀된 별도의 커널 상에서 구동된다. 메모리의 경우 물리적으로는 시스템과 같은 칩을 공유하나 별도의 메모리 공간을 갖추고 있다. 이 메모리 공간은 (SE BootROM에 의해) 기기가 재시작될 때마다 변경되는 (!!!) 메모리 보호 키에 의해 암호화되며, 이 키는 기기의 고유 UID와 암호학적으로 연결되기 때문에... 물리적인 칩 재납땜과 같은 극단적인 방법을 동원해도 절대 데이터를 꺼내올 수 없다.

이 Secure Enclave에 저장되고 관리되는 모든 키는 절대 Secure Enclave 밖으로 나갈 수 없다. Secure Enclave 밖에서 생성된 키를 안에 저장하는 것도 불가능하다. Secure Enclave에서 사용되는 모든 키는 Secure Enclave 안에서만 생성되고 사용되어야 하며, 서명 절차 자체도 오직 Secure Enclave 코프로세서에서만 이루어질 수 있다. 이는 하드웨어 지갑과 같은 전용 키 콜드 스토리지 기기에서도 사용하는 방식이지만, 상술했듯 SoC 안에 회로가 포함되어 있는 구조인 데다 USB와 같은 표준 시스템 인터페이스를 거치지도 않으므로 더 안전하다. 거기다 별도의 장치를 들고 다닐 필요도 없다.

Secure Enclave는 iOS/T2 Mac 기기의 저장소 암호화에도 활용된다. 이들 기기에서는 파일시스템 레벨에서의 AES-256 암호화에 더해, 파일별로 별도의 키를 생성해 한 번 더 암호화한다. (...) 파일의 메타데이터는 파일시스템 레벨의 키로 암호화되고, 다시 파일시스템 구역 키를 활용해 파일시스템 레벨 메타데이터로 지정되어 있는 개별 파일 키를 얻는 과정을 거친다. 이 모든 암/복호화 과정도 Secure Enclave에서 일어난다. 이러한 보안 아키텍처 덕분에 iOS는 정부기관조차 뚫을 수 없는 수준의 보안을 자랑한다. FBI가 강제 집행에 성공한 마지막 아이폰은 Secure Enclave가 탑재되지 않은 iPhone 5c였으며, 그 이후로는 iOS 기기에서의 강제집행에 성공한 사례가 단 한 번도 보고되지 않았으니 말 다 했다.

기존에는 Secure Enclave에 저장되어 있는 키를 사용한 암호화를 수행하기 위해 상당히 까다로운 검증 및 데이터 생성 과정을 거쳐야만 했다 (https://developer.apple.com/…/keys/using_keys_for_encryption). 특히나 Secure Enclave는 256비트 ECC 암호화만을 지원하기 때문에 (https://developer.apple.com/…/storing_keys_in_the_secure_en…) ECC 암호화 알고리즘에 대한 기본적인 이해 없이는 코드를 짜는 것이 다소 복잡하다. 반면 CryptoKit에서는 이런 과정들이 상당히 추상화되며, 키체인을 직접 관리할 필요가 없기 때문에 메모리 관리 측면에서도 더욱 더 안전하다. 하드웨어 지갑보다 더 안전한 수준의 키 보안을 아이폰에서 즐길 수 있게 되는 것이다.

CryptoKit이라는 이름 덕분에 애플이 곧 블록체인 지갑을 선보일 것이라고 전망하는 매체들이 꽤 있는데, 당분간은 그럴 일 없을 듯하다. 저런 암호화 로직은 블록체인뿐만 아니라 은행 앱 등에서 더욱 더 수요가 크기 때문이다. 안드로이드 기기들에서 쓰이는 TrustZone보다 더욱 안전한 로직이기 때문에 더욱 더 그렇다. 다만 블록체인 지갑 앱을 더 안전하게 만들기는 더 쉬워질 것이 확실해 보이기는 한다. 최소한 녹스 컨테이너에 담아두는 것보다는 낫지 않겠나 싶다 (...)

iOS 13 프리뷰 SDK 받은 김에, 이걸로 어디까지 할 수 있는지 좀 더 깊게 살펴보아야겠다. 하드웨어 지갑 없이도 iOS 네이티브 DApp 환경을 구현할 수 있을지도?