기술[iOS 취약점 점검] 1. iOS 보안 구조와 보안 모델 이해하기

문성준
2025-09-29
조회수 547

438ae115044f3.png


iOS란 무엇인가?


iOS는 애플이 만든 모바일 운영체제로, iPhone에서 동작합니다.

 

안드로이드가 여러 제조사와 개방적인 생태계 위에서 돌아가는 것과 달리, iOS는 폐쇄적인 구조를 가지고 있습니다.

 

앱 설치는 원칙적으로 App Store를 거쳐야 하며, 모든 앱은 애플이 발급한 개발자 인증서와 서명을 가져야만 실행할 수 있습니다.

이 때문에 사용자는 비교적 안전한 환경을 누릴 수 있지만, 보안 연구자나 모의해킹을 하는 입장에서는 탈옥(Jailbreak) 같은 과정을 거치지 않고는 내부 구조를 깊게 들여다보기가 어렵습니다.

 

참고: App Distribution - Apple Developer


iOS 애플리케이션 구조



507d6225e5ac9.png


iOS는 크게 네 개의 계층으로 나눌 수 있습니다.

 

가장 위에는 Cocoa Touch 계층이 있습니다. 사용자가 실제로 보고 만지는 앱 화면(UI), 제스처, 알림 기능들이 속해 있으며, 앱 개발자가 가장 많이 다루는 영역입니다.

 

그 아래는 Media 계층으로, 사진 촬영, 영상 재생, 게임 그래픽 등 멀티미디어 기능을 담당합니다. AVFoundation, CoreGraphics, Metal 같은 기술들이 여기에 포함됩니다.

 

세 번째는 Core Services 계층입니다. 앱 데이터를 저장하거나 서버와 통신할 때, 달력과 시간을 처리할 때, 혹은 iCloud와 동기화할 때 필요한 서비스들이 이 계층에서 작동합니다. 앱의 중간 허리 역할을 하는 곳이라고 볼 수 있습니다.

 

맨 아래에는 Core OS 계층이 있습니다. Darwin 커널, 파일 시스템, 디바이스 드라이버, 메모리 관리 기능 등이 모두 이곳에 포함됩니다. 특히 보안과 관련된 중요한 기능들—샌드박스, 코드 서명 검증, 하드웨어 암호화, 키체인—은 바로 Core OS에서 이루어집니다.

 

참고: iOS Technology Overview - Apple Developer


보안의 출발점: Chain of Trust


보안에서 가장 무서운 공격은 시스템이 완전히 켜지기도 전에 침투하는 공격입니다.

 

PC 시절을 떠올려 보면, 루트킷(rootkit)이나 부트킷(bootkit)이 부팅 시점에 감염되어 보안 소프트웨어조차 감염된 상태에서 실행되는 경우가 있었습니다.

 

한번 이러한 상태가 되면, 그 위에서 아무리 보안 프로그램이 작동해도 의미가 없을 것입니다.

 




59d3d0e98559d.png

 

아이폰은 이런 위협을 막기 위해 Chain of Trust를 설계했습니다.

 

전원이 켜지는 순간 가장 먼저 실행되는 것은 Boot ROM이라는 칩 내부의 읽기 전용 코드입니다. Boot ROM은 다음 단계인 iBoot를 불러오기 전에 “이 코드가 애플이 서명한 원본인지”를 검증합니다. 이 검증은 커널이 로딩될 때까지 계속 이어집니다.

 

여기서 말하는 서명(Signature)은 단순히 서류에 찍는 도장이 아니라, “이 코드가 변조되지 않았다”는 암호학적 증명입니다. 애플은 자신만의 비밀키로 도장을 찍고, 누구나 볼 수 있는 공개키로 그 도장이 진짜인지 확인할 수 있게 합니다. 따라서 누군가가 코드를 한 줄이라도 바꾼다면, 검증은 곧바로 실패합니다.

 

참고: Apple Platform Security - Secure Boot


부팅 체인, 한 단계씩 살펴보기


iOS 기기 실행

전원이 들어오면 애플리케이션이나 커널이 먼저 깨어나는 것이 아니라, 칩 안쪽의 읽기 전용(ROM) 코드가 먼저 움직입니다. 이 코드가 Boot ROM(= SecureROM)을 깨워 다음 단계로 넘기는 준비를 하며, Chain of Trust는 여기서 시작됩니다.

 

Boot ROM

 

Boot ROM은 칩 제조 단계에서 굳어져 더는 바꿀 수 없는 코드입니다. 단순하지만 결정적인 역할을 하며, 다음 단계로 올릴 바이너리(과거에는 LLB, 최신 기종은 iBoot를 바로 올리는 경우가 많음)가 애플이 서명한 정품인지를 확인합니다.

 

검증에 실패하면 더 이상 진행하지 않고 DFU(Device Firmware Update) 모드로 빠집니다. Boot ROM 내부에는 애플 루트 공개키가 저장되어 있고, 다음 단계 바이너리는 IMG3/IMG4 컨테이너 안에 해시, 전자서명, 인증서 체인을 담고 있어 이를 검증합니다.

 

참고: Apple Platform Security - Boot ROM

 

LLB (Low Level Bootloader)

 

초기 아이폰 세대에는 Boot ROM과 iBoot 사이의 얇은 다리 역할을 했습니다.

 

LLB의 임무는 iBoot 이미지의 서명을 다시 검증하고, 기초적인 초기화를 마친 뒤 iBoot로 제어권을 넘기는 것입니다.

 

오늘날 많은 기기에서 LLB 단계는 사실상 통합되었지만, “한 단계가 다음 단계를 검증한다”는 구조를 이해하는 데 여전히 중요한 개념입니다. 검증이 실패하면 iBoot로 가지 못하고 Recovery/DFU 모드로 전환됩니다.

 

iBoot

 

iBoot는 사용자가 체감하는 iOS 실행 직전까지 대부분의 준비를 총괄합니다. 저장장치와 메모리를 초기화하고, 이후 사용할 이미지들—Device Tree, Kernelcache, TrustCache, SEP 펌웨어—를 차례대로 서명 검증합니다.

 

특히 커널 캐시 검증이 핵심인데, 여기서 운영체제의 심장이 정품인지 확인합니다. 검증 실패 시 iBoot는 정상 부팅을 멈추고 Recovery 모드로 전환해 사용자가 복원할 수 있도록 합니다.

 

iBoot 단계의 검증은 Boot ROM과 원리는 같지만, 검증 대상이 더 많아지고 버전 롤백 방지(APTicket/nonce 기반), 디바이스 고유 식별값 검사 같은 정책이 추가됩니다.

 

참고: Apple Platform Security - iBoot

 

iOS Kernel

 

커널이 메모리로 올라가 실행된 뒤에도 검증은 끝나지 않습니다.

 

iOS는 사용자 공간으로 넘어간 뒤에도 AMFI(Apple Mobile File Integrity)가 계속해서 코드 서명 정책을 집행합니다.

 

앱, 프레임워크, 확장 모듈 등이 정상 서명과 TrustCache에 부합하는지를 런타임에 점검합니다. 여기에 샌드박스(Seatbelt)Entitlements(권리증서)가 결합되어, 실행 가능한 범위를 제한합니다.

 

즉, 부팅 때 한 번만 신뢰하는 것이 아니라 실행 내내 신뢰 상태를 유지하는 구조입니다.

 

참고: Apple Platform Security - Code Signing and Runtime Protections

 

DFU와 Recovery

 

DFU(Device Firmware Update) 는 가장 낮은 단계의 복구 모드로, Boot ROM(SecureROM)이 직접 장비를 받아 최소한의 통신만 허용합니다.

 

서명 검증에 실패해 아주 초기에 막혔거나, iBoot조차 정상적으로 올라오지 못하는 상황에서 사용됩니다. 이 모드에서는 호스트(Mac/PC)가 애플 서명 이미지를 보내고 Boot ROM이 이를 검증하여 복구를 이어갑니다.

 

Recovery 모드는 iBoot가 살아있을 때 제공됩니다. iBoot는 호스트와 통신하며 복원 이미지를 받아 설치하고, 이 단계에서는 사용자에게 케이블+컴퓨터 아이콘 같은 화면도 보여집니다.

 

요약하면 DFU는 Boot ROM 직통, Recovery는 iBoot 경유 복구 모드입니다. 둘 다 애플 서명 이미지만 허용합니다.

 

참고: About Apple Device Firmware Update (DFU) mode - Apple Support

참고: Recovery Mode - Apple Support

카카오톡 채널 채팅하기 버튼