0x0C 클라우드와 신뢰 컴퓨팅 (Cloud and Trusted Computing)

1. 시스템 보안 개요

1.1 시스템 보안 정의

시스템 보안 (Systems Security):
• 안전한 컴퓨터 시스템 설계의 포괄적 프로세스
• 하드웨어와 소프트웨어의 모든 계층에서 보안 고려

안전한 현대 컴퓨터 시스템의 요건:
• 잘 정의된 신뢰 컴퓨팅 기반 (TCB)
• 권한 분리 (Privilege Separation)  
• 세분화된 접근 제어 (Fine-grained Access Control)
• 구성 요소 격리 (Component Isolation)
• 단일 장애점 없음 (No Single Point of Failure)

1.2 핵심 보안 개념

신뢰 컴퓨팅 기반 (TCB)

TCB (Trusted Computing Base):
• 보안이 의존하는 소량의 소프트웨어와 하드웨어
• 보안에 영향을 주지 않고 오작동할 수 있는 
  훨씬 더 큰 양의 코드와 구별됨

특징:
• TCB는 최대한 작게 유지해야 함
• TCB 밖의 코드는 신뢰하지 않음
• 모든 보안 결정의 기준점

신뢰 기반 (Root of Trust)

Root of Trust:
• 시스템 내 신뢰 체인의 시작점
• 신뢰 기반을 형성하는 소프트웨어와 하드웨어는 TCB

신뢰 체인:
Hardware Root → Bootloader → OS Kernel → Applications

권한 수준 (Privilege Level)

권한 수준 (Privilege Level):
• 허용된 작업 집합과 리소스 접근 권한으로 정의된 계층
• 권한 계층은 종종 계층 구조로 조직됨

예시:
Ring 0 (Kernel) > Ring 1 > Ring 2 > Ring 3 (User)

2. 하드웨어 수준 접근 제어

2.1 x86 CPU 실행 권한

x86 권한 링 구조:
┌─────────────────┐ Ring 0 (Kernel)
│     Kernel      │ • 모든 명령어 실행 가능
├─────────────────┤ • 하드웨어 직접 접근
│   Device        │ Ring 1-2 (Device Drivers)
│   Drivers       │ • 제한된 하드웨어 접근
├─────────────────┤
│  Applications   │ Ring 3 (User)
└─────────────────┘ • 제한된 명령어만 실행

특권 명령어 (Privileged Instructions)

특권 명령어의 정의:
• 프로세서 구성을 수정할 수 있는 특별한 명령어 부집합
• 하드웨어와 직접 상호작용
• Ring 0에서만 실행 가능

주요 특권 명령어:
1. 제어 레지스터 수정: mov crN, Src
2. 메모리 보호 비활성화: mov cr0, eax & ~0x10000
3. 컨텍스트 스위치: mov cr3, eax
4. MSR 수정: wrmsr

2.2 x86 메모리 접근 제어

페이징 시스템의 접근 제어:
• 물리 메모리 위에 가상 메모리 생성
• 페이지 테이블 엔트리(PTE)로 권한 제어

PTE 플래그:
• P bit: 페이지 접근 가능 여부
• R/W bit: 페이지 수정 가능 여부
• XD bit: 페이지 코드 실행 가능 여부
• Supervisor bit: 커널 전용 페이지 여부

3. 운영체제 수준 접근 제어

3.1 커널 수준 접근 제어

커널 권한:
• 최고 권한 수준에서 실행 (x86: Ring 0, ARM: EL1)
• 특권 명령어 실행 가능
• 커널 메모리는 Supervisor 페이지로 구성

사용자 프로그램 제한:
• Ring 3에서 실행
• 커널 메모리 접근 불가
• 시스템 콜을 통해서만 커널 서비스 이용

3.2 사용자-커널 권한 분리

실행 모드 권한

현대 OS의 권한 모델:
• 사용자 프로그램: Ring 3 모드
• 커널: Ring 0 모드
• 특권 명령어는 Ring 0에서만 실행 가능

시스템 콜 메커니즘:
User Mode (Ring 3) → syscall → Kernel Mode (Ring 0)
                                    ↓
                                sysret ← 단일 진입/출구점

시스템 콜의 역할

시스템 콜 계층 구조:

고수준 언어 (Python, Java, JavaScript)
        ↓
런타임 라이브러리 (Python Interpreter, JVM)
        ↓  
C 런타임 라이브러리 (libc, CRT)
        ↓
커널 시스템 콜 (sys_open, sys_read, sys_socket...)
        ↓
하드웨어 리소스

특징:
• 모든 사용자 프로그램은 시스템 리소스 접근 시 시스템 콜 사용
• x86-64 Linux는 313개의 시스템 콜 제공
• 엄격한 단일 진입점과 출구점 강제

3.3 프로세스 주소 공간 보호

프로세스 격리:
• 커널이 각 프로세스에 대해 개별 주소 공간 생성
• 한 프로세스는 다른 프로세스 메모리에 임의 접근 불가
• 페이지 테이블을 통한 하드웨어 기반 격리

메모리 레이아웃:
Process A               Process B
┌─────────────┐        ┌─────────────┐
│    Code     │        │    Code     │
├─────────────┤        ├─────────────┤
│    Data     │        │    Data     │
├─────────────┤        ├─────────────┤
│   Stack     │        │   Stack     │
└─────────────┘        └─────────────┘
     ↑                        ↑
  독립된 가상               독립된 가상
  주소 공간                 주소 공간

4. 커널 익스플로잇과 루트킷

4.1 커널 취약점의 파급력

하나의 취약점으로 완전한 시스템 장악:

임의 메모리 쓰기 버그:
• 전체 커널 공간 어디든 쓰기 가능
• 모든 보안 메커니즘 우회 가능

임의 코드 실행 버그:
• 커널 내 어디든 점프 가능
• 커널 공간 ROP 체인 실행
• 시스템 완전 장악

현대 커널 방어:
• KASLR (Kernel ASLR)
• Stack Canary
• SMEP/SMAP
• 하지만 여전히 취약점 존재

4.2 커널 루트킷

커널 루트킷의 능력:

┌─────────────────┐
│ User Applications│ ← 정보 조작
├─────────────────┤
│   OS Kernel     │ ← 루트킷 감염
│   Rootkit       │
├─────────────────┤
│   Hardware      │ ← 하드웨어 조작
└─────────────────┘

공격 능력:
• OS 수준 보안 조치 비활성화/우회
• 시스템 정보 조작 (프로세스 목록, 파일 목록 숨김)
• 하드웨어 상호작용 간섭 (키보드 입력 가로채기)
• 닭과 달걀 문제: 보안 모듈도 커널에 의존

💡 추가 정보: 커널 루트킷은 시스템의 최고 권한으로 실행되므로 모든 보안 메커니즘을 무력화할 수 있어, 하드웨어 기반 보안 솔루션의 필요성이 대두되었습니다.

5. 신뢰 실행 환경 (TEE) 소개

5.1 현대 소프트웨어의 복잡성

현대 소프트웨어 규모 (MLOC = Million Lines of Code):
• Google Chrome Browser: ≥ 6.7 MLOC
• Android OS: ≥ 12~15 MLOC
• Mac OS X 10.4: ≥ 86 MLOC
• Linux Kernel: ≥ 20 MLOC

복잡성 → 취약점:
• 코드 크기 증가 ∝ 버그 발생 확률 증가
• 지속적인 변경으로 새로운 버그 유입
• 완벽한 버그 없는 소프트웨어 달성 어려움

5.2 보안 접근법의 변화

기존 접근법의 한계

버그 제거 노력:
• 안전한 코딩 (Secure Coding)
• 정적 분석 (Static Analysis)  
• 퍼징 (Fuzzing)
• 형식 검증 (Formal Verification)

한계:
• 상용 소프트웨어에서 버그 완전 제거 불가능
• 현실적으로 버그 없는 소프트웨어 달성 어려움
• 지속적인 개발과 변경으로 새로운 버그 유입

신뢰 실행 접근법

핵심 철학: "신뢰하는 것이 적을수록 더 안전해진다"

접근 방법:
• 모든 소프트웨어를 신뢰하지 않는 것으로 간주
• 소량의 신뢰할 수 있는 코드만 격리하여 보호하는 "엔클레이브" 생성

구조:
┌─────────────────┐
│ Untrusted Code  │ ← 대부분의 복잡한 코드
├─────────────────┤
│  Trusted Code   │ ← 최소한의 신뢰 코드 (TCB)
└─────────────────┘

TEE 구현 방식:
• 하이퍼바이저 기반 TEE
• 하드웨어 기반 TEE (Intel SGX, ARM TrustZone)

5.3 TEE의 실용적 응용

보안 엔드포인트 서비스:
• DRM (Digital Rights Management)
• 보안 결제 시스템

클라우드에서의 기밀 컴퓨팅:
• "클라우드는 남의 컴퓨터"
• 클라우드로 오프로드되는 워크로드 보호
• 클라우드 제공자로부터도 데이터/코드 보호

6. Intel SGX 아키텍처

6.1 Intel SGX 개요

Intel SGX (Software Guard Extensions):
• Intel Skylake 아키텍처에서 도입 (2015년)
• 하드웨어 변경, 새로운 명령어, SGX SDK 포함
• 애플리케이션이 주소 공간 내에서 민감한 코드와 데이터 격리 가능

킬러 애플리케이션:
• 클라우드에서의 기밀 컴퓨팅 (Confidential Computing)
• 신뢰할 수 없는 환경에서의 보안 실행

6.2 SGX 보안 모델

"CPU만 신뢰" 모델

기존 신뢰 모델의 문제:
┌─────────────────┐
│ Application     │ ← 다양하고 복잡, 종종 안전하지 않음
├─────────────────┤
│ OS Kernel       │ ← 연간 100+ CVE (Linux 커널)
├─────────────────┤  
│ Hypervisor      │ ← XEN: 지금까지 361개 CVE
├─────────────────┤
│ Hardware        │
└─────────────────┘

SGX 보안 모델:
┌─────────────────┐
│ Application  ✗  │
├─────────────────┤
│ Secure Enclave ✓│ ← 신뢰하는 유일한 영역
├─────────────────┤
│ OS Kernel    ✗  │
├─────────────────┤
│ Hypervisor   ✗  │
├─────────────────┤
│ BIOS/SMM     ✗  │
├─────────────────┤
│ Hardware     ✓  │ ← CPU만 신뢰
└─────────────────┘

최소화된 공격 표면

SGX의 신뢰 범위:
• 엔클레이브: 사용자 공간 내 보호된 세그먼트
• CPU만 신뢰: 최소한의 TCB
• 나머지 모든 소프트웨어는 신뢰하지 않음

이점:
• 공격 표면 극도로 축소
• 복잡한 OS/하이퍼바이저 신뢰 불필요
• 하드웨어 기반 격리 보장

6.3 SGX 메모리 보호

하드웨어 보안 경계

SGX 메모리 보호 구조:

CPU 패키지 내부 (보안 경계):
┌─────────────────────────────────┐
│ Core  Core  Core  Core          │
│              ↓                  │
│           Caches                │
│              ↓                  │
│          Encrypt               │
└─────────────────────────────────┘
              ↓
         Memory Bus ← 암호화된 데이터만 전송
              ↓
          Memory

보안 특성:
• 코드/데이터는 CPU 내부에서만 복호화
• 메모리 버스 스누핑 방지
• 하드웨어 기반 암호화/복호화

Enclave Page Cache (EPC)

메모리 관리 구조:

PRM (Processor Reserved Memory):
• SGX가 DRAM 범위 예약
• OS도 접근할 수 없는 보호된 영역

EPC (Enclave Page Cache):
• 각 엔클레이브에 할당되는 메모리 영역
• PRM에 속하는 페이지들로 구성

EPCM (Enclave Page Cache Map):
• 각 페이지의 상태 저장
• 올바른 매핑 추적
• OS 커널이 의도된 권한(RWX)으로 페이지 매핑했는지 검사

메모리 접근 제어:
• 일반 사용자 모드에서는 EPC 페이지 접근 시 fault 발생
• 엔클레이브 모드에서만 EPC 페이지 접근 가능
• 어떤 소프트웨어 명령어도 엔클레이브 메모리 접근 불가

6.4 SGX 실행 모드와 인터페이스

ECALL과 OCALL

모드 전환 메커니즘:
• EENTER: 엔클레이브 진입
• EEXIT: 엔클레이브 종료
• AEX: 비동기 엔클레이브 종료

ECALL (Enclave Calls):
• 신뢰하지 않는 코드 → 신뢰하는 엔클레이브 호출
• 미리 정의된 인터페이스를 통해서만 가능

OCALL (Outside Calls):  
• 엔클레이브 → 신뢰하지 않는 외부 코드 호출
• 시스템 리소스 접근 시 사용

제어된 인터페이스:
untrusted code ←→ ecall/ocall ←→ enclave code

시스템 콜 제한

Iago 공격의 교훈:
• 시스템 콜 API는 신뢰할 수 없는 RPC 인터페이스
• 커널에 대한 암묵적 신뢰가 악용될 수 있음
• 커널과의 직접 통신은 공격 표면

SGX 제한 사항:
• 엔클레이브 모드 내에서 시스템 콜 금지
• syscall 명령어 실행 시 불법 명령어 트랩 발생

해결 방법:
• 개발자가 OCALL 래퍼 구현
• libc 함수들을 OCALL을 통해 우회 호출
• 예: printf() → ocall_printf() → 외부에서 실제 printf() 호출

6.5 SGX 암호학과 원격 증명

하드웨어 키

SGX 하드웨어 키:
• Root Provisioning Key (128비트)
• Root Seal Key (128비트)

용도:
Root Provisioning Key:
• SGX의 진위성 증명 (예: "나는 SGX다")
• Intel과의 통신에 사용

Root Seal Key (RSK):
• CPU만 알고 있는 키
• 다른 유형의 키 파생에 사용
• 외부에 노출되지 않음

원격 증명 (Remote Attestation)

원격 증명의 목적:
1. 클라우드가 실제로 SGX 하드웨어를 사용하고 있다는 증명
2. SGX 내에서 실행되는 것이 사용자가 보낸 프로그램이라는 증명

증명 과정:
┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│      Alice      │    │      Cloud      │    │      Intel      │
├─────────────────┤    ├─────────────────┤    ├─────────────────┤
│ "정말 SGX?"     │ →  │                 │    │                 │
│                 │ ←  │ "증명서: 2c057..│    │                 │
│ Intel에 검증    │ →  │                 │    │ "유효한 SGX CPU"│ ←
│ "내 프로그램?"  │ →  │ "엔클레이브 해시 │    │                 │
│                 │ ←  │ 747190e4cfa..." │    │                 │
└─────────────────┘    └─────────────────┘    └─────────────────┘

신뢰 기반:
• CPU (하드웨어)
• Intel (인증 기관)

검증 내용:
• 실제 SGX 하드웨어 여부
• 수정 없이 사용자 프로그램 실행 여부

7. SGX 클라우드 응용

7.1 클라우드 공격 모델

클라우드 위험 요소:
• 침해된 클라우드 인프라
• 악의적/호기심 많은 관리자
• 수상한 동일 테넌트 (Co-tenant)
• 기타 내부자 위협

SGX 해결책:
• 클라우드에서 워크로드를 기밀적으로 수행
• 클라우드 제공자로부터도 데이터 보호
• 하드웨어 기반 격리로 신뢰성 확보

7.2 SGX 클라우드 응용 사례

기밀 딥러닝:
• Occlumency (MobiCom '19)
• 클라우드에서 모델과 데이터 모두 보호

기밀 MapReduce:
• VC3 (Oakland '15)  
• 분산 컴퓨팅에서 데이터 기밀성 보장

SGX 기반 데이터베이스:
• EnclaveDB (Oakland '18)
• 암호화된 데이터베이스 연산

공통 특징:
• 클라우드 제공자 불신
• 하드웨어만 신뢰
• 성능과 보안의 균형

8. SGX 보안 과제

8.1 사이드 채널 공격

캐시 사이드 채널

주요 공격 연구:
• CacheZoom (CHES 2017)
• Software Grand Exposure (SEC '17)  
• Cache Attacks on Intel SGX (EuroSec '17)

공격 원리:
• CPU 캐시 접근 패턴 분석
• 타이밍 차이로 비밀 정보 유추
• 메모리 접근 패턴으로 데이터 유출

페이지 테이블 공격

공격 메커니즘:

1. 초기 상태 - 악의적 커널이 모든 EPC 페이지 매핑 제거:
┌─────────────────┐    ┌─────────────────┐
│  Virtual Addr   │    │ Physical Addr   │
├─────────────────┤    ├─────────────────┤
│ A B C D E F G   │    │ (unmapped)      │
└─────────────────┘    └─────────────────┘

2. 페이지 접근 시 - 페이지 폴트 발생:
┌─────────────────┐    ┌─────────────────┐
│ A B C [D] E F G │    │ Page Fault!     │
└─────────────────┘    └─────────────────┘
           ↑
     접근한 페이지

3. 커널이 학습 - 어떤 페이지가 접근되었는지 파악:
커널: "페이지 D가 접근됨" → 매핑 생성

공격자가 학습할 수 있는 정보:
• 실행 순서: func_a() → func_d() → func_f()
• 사용/미사용 판별: 알고리즘 A는 사용, E는 미사용
• 입력-응답 관찰: 연결 시마다 페이지 C에 폴트 발생

실험적 검증

Membuster (SEC '20):
• 전체 시스템 시뮬레이션을 이용한 실험
• SGX 사이드 채널 공격의 실제 위험성 입증

CPU 캐시를 이용한 비밀 기억:
• "전구 질문": 전구가 켜졌는지 꺼졌는지 어떻게 알 수 있나?
• 캐시 상태 (WARM/COLD)로 비밀 정보 저장
• 타이밍 차이로 캐시 상태 판별 가능

8.2 Meltdown/Spectre 영향

Meltdown의 파급효과:
• 기존 사용자/커널 경계 붕괴
• 모든 사용자 프로세스가 커널 메모리 탐지 가능
• KPTI (Kernel Page Table Isolation) 완화 기법 도입

성능 영향:
• KPTI 성능 오버헤드: I/O 집약적 작업에서 ~20%
• SGX도 유사한 투기적 실행 공격에 취약할 수 있음

보안 영향:
• 하드웨어 수준 취약점의 소프트웨어 보안 영향
• SGX 같은 하드웨어 기반 보안도 완전하지 않음을 시사

8.3 보안 I/O 문제

SGX의 보안 I/O 한계

문제점:
• SGX TCB에 커널 미포함
• 디바이스 드라이버와 I/O 경로 신뢰하지 않음
• 디바이스의 적극적 참여 없이 보안 I/O 달성 불가능

보안 I/O를 위한 요구사항:
• 디바이스는 보안 키 저장소 필요
• 디바이스 인증서와 CA 필요
• 엔클레이브와 보안 채널 생성에 적극 참여

예시 (Graviton - OSDI '18):
디바이스 ←→ 보안 채널 ←→ 엔클레이브
• 종단 간 암호화
• 디바이스 수준 증명
• 하드웨어 기반 신뢰

ARM TrustZone과의 비교

ARM TrustZone 장점:
• 보안 모델에 신뢰할 수 있는 커널 포함
• 보안 I/O 제공 가능
• Android 플랫폼에서 실제 서비스 적용:
  - Samsung Pay
  - Widevine DRM (Netflix 등)

SGX vs TrustZone:
┌─────────────────┬─────────────────┬─────────────────┐
│      구분       │   Intel SGX     │  ARM TrustZone  │
├─────────────────┼─────────────────┼─────────────────┤
│ 신뢰 범위       │ CPU만           │ CPU + 보안 커널 │
├─────────────────┼─────────────────┼─────────────────┤
│ 보안 I/O        │ 제한적          │ 지원            │
├─────────────────┼─────────────────┼─────────────────┤
│ 상용화          │ 클라우드 중심   │ 모바일 중심     │
└─────────────────┴─────────────────┴─────────────────┘

9. SGX 프로그래밍 모델

9.1 프로그래밍 모델 1: 프로그램 분할

코드 분할 전략

분할 기준:
• 프로그램 비밀 식별
• 비밀과 상호작용하거나 노출할 수 있는 함수들
• 민감한 코드와 데이터를 TCB로 격리

예시 - 보안 패스워드 관리자:
┌─────────────────┬─────────────────┐
│    Trusted      │   Untrusted     │
├─────────────────┼─────────────────┤
│ 보안 파일 저장   │ 콘솔 UI         │
│ TLS 통신        │ 소켓 생성       │
│ 마스터 패스워드  │ 기타 I/O        │
└─────────────────┴─────────────────┘

ECALL/OCALL 패턴

일반적인 호출 패턴:

main() 함수 (untrusted)
    ↓ ECALL
ecall_seal() 함수 (trusted)
    ↓ OCALL  
ocall_write_buf_to_file() (untrusted)

특징:
• ECALL: 신뢰 영역 진입
• OCALL: libc/시스템 콜 프록시 역할
• 파일 I/O, 소켓 생성 등에 OCALL 사용

Enclave Definition Language (EDL)

EDL 파일 구조:

enclave {
    from "sgx_pthread.edl" import *;
    from "sgx_tstdc.edl" import *;
    from "wolfssl.edl" import *;
    
    trusted {
        public long ecall_init_ctx_client(void);
        public int ecall_check_passwd(void);
        public int ecall_connect_test(long sslID);
    };
    
    untrusted {
        int ocall_get_passwd([out, size=maxlen] char *passwd, size_t maxlen);
    };
};

특징:
• ECALL과 OCALL 인터페이스 정의
• 방향성 지정: [in], [out], [in,out]
• 버퍼 크기 명시: size=maxlen
• SGX SDK 컴파일러가 링크 코드 자동 생성

9.2 프로그래밍 모델 2: 라이브러리 포팅

라이브러리 포팅 접근법:
• 민감한 라이브러리 (OpenSSL 등)를 통째로 SGX로 포팅
• 작은 TCB보다는 원본 API 디자인 유지가 목적
• 기존 애플리케이션과의 호환성 중시

포팅 과정:
1. 라이브러리 API를 ECALL로 노출
2. 필요한 시스템 리소스는 OCALL 사용 (printf, socket 등)
3. 기존 API 시그니처 최대한 유지

포팅된 라이브러리 예시:
• OpenSSL, wolfSSL, mbedTLS
• zlib, libjpeg
• 기타 암호화/압축 라이브러리들

장점: 기존 코드 재사용 용이
단점: TCB 크기 증가

예상 시험문제

1. 시스템 보안의 계층별 접근 제어

문제: 현대 컴퓨터 시스템에서 하드웨어, 운영체제, 애플리케이션 계층의 접근 제어 메커니즘을 설명하고, 각 계층에서 권한 분리가 어떻게 구현되는지 서술하시오.

모범답안:

하드웨어 계층 접근 제어:

x86 권한 링 구조:

Ring 0 (Kernel Mode):
• 모든 특권 명령어 실행 가능
• Supervisor 페이지 접근 가능
• 하드웨어 직접 제어 (CR 레지스터, MSR 등)

Ring 3 (User Mode):
• 제한된 명령어만 실행
• User 페이지만 접근 가능  
• 시스템 콜을 통해서만 커널 서비스 이용

메모리 접근 제어 (페이징):
• P bit: 페이지 접근 가능 여부
• R/W bit: 읽기/쓰기 권한
• XD bit: 실행 방지 (DEP)
• Supervisor bit: 커널 전용 여부

운영체제 계층 접근 제어:

커널-사용자 권한 분리:

실행 모드 분리:
• 커널: Ring 0, 특권 명령어 실행 가능
• 사용자: Ring 3, 제한된 명령어

메모리 공간 분리:
• 커널 공간: Supervisor 페이지, 사용자 접근 불가
• 사용자 공간: User 페이지, 프로세스별 독립

시스템 콜 인터페이스:
User Mode → syscall → Kernel Mode → sysret → User Mode
• 엄격한 단일 진입/출구점
• 커널이 모든 하드웨어 리소스 중재

프로세스 간 격리:

가상 메모리 기반 격리:
• 각 프로세스는 독립된 가상 주소 공간
• 페이지 테이블을 통한 하드웨어 강제 격리
• 한 프로세스는 다른 프로세스 메모리 직접 접근 불가

컨텍스트 스위치:
• CR3 레지스터 변경으로 페이지 테이블 교체
• 프로세스별 독립된 메모리 뷰 제공

애플리케이션 계층 접근 제어:

프로그래머 정의 접근 제어:

설계 고려사항:
• 무엇을 보호해야 하는가?
• 누가 접근할 수 있어야 하는가?
• 어떤 조건에서 접근이 불법인가?
• 어떤 접근 제어 스키마를 적용할 것인가?
• 접근 제어 스키마에 허점은 없는가?

구현 방법:
• 사용자 인증 및 세션 관리
• 역할 기반 접근 제어 (RBAC)
• 리소스별 권한 설정
• 비즈니스 로직 기반 접근 제어

계층별 상호작용:

상위 계층은 하위 계층의 보안에 의존:
애플리케이션 보안 ← OS 보안 ← 하드웨어 보안

위반 시 영향:
• 하드웨어 침해 → 전체 시스템 장악
• 커널 침해 → 모든 사용자 프로세스 장악  
• 애플리케이션 침해 → 해당 앱 권한 범위 내 피해

방어 전략:
• 최소 권한 원칙 (Principle of Least Privilege)
• 심층 방어 (Defense in Depth)
• 권한 분리 (Privilege Separation)

2. Intel SGX의 보안 모델과 메모리 보호

문제: Intel SGX의 "CPU만 신뢰" 보안 모델을 설명하고, EPC(Enclave Page Cache)를 통한 메모리 보호 메커니즘과 기존 가상 메모리 시스템과의 차이점을 분석하시오.

모범답안:

SGX "CPU만 신뢰" 보안 모델:

기존 신뢰 모델의 문제점:

전통적 신뢰 계층:
┌─────────────────┐ ← 복잡하고 취약
│   Application   │   다양한 소프트웨어
├─────────────────┤ ← Linux: 연간 100+ CVE
│   OS Kernel     │   복잡한 커널 코드
├─────────────────┤ ← XEN: 361개 CVE
│   Hypervisor    │   가상화 복잡성
├─────────────────┤ ← 펌웨어 복잡성 증가
│  BIOS/Firmware  │   공급망 위험
├─────────────────┤
│    Hardware     │
└─────────────────┘

문제점:
• 신뢰해야 할 코드가 너무 많음 (수백만 라인)
• 각 계층에서 지속적인 취약점 발견
• 공격 표면이 매우 넓음

SGX 신뢰 모델:

최소 신뢰 모델:
┌─────────────────┐ ✗ 신뢰하지 않음
│   Application   │   
├─────────────────┤ ✓ 신뢰 (최소 코드)
│ Secure Enclave  │   격리된 실행 환경
├─────────────────┤ ✗ 신뢰하지 않음  
│   OS Kernel     │   
├─────────────────┤ ✗ 신뢰하지 않음
│   Hypervisor    │   
├─────────────────┤ ✗ 신뢰하지 않음
│  BIOS/Firmware  │   
├─────────────────┤ ✓ 신뢰 (하드웨어)
│      CPU        │   Intel SGX 하드웨어
└─────────────────┘

장점:
• TCB 크기 극도로 축소
• 공격 표면 최소화
• 하드웨어 기반 신뢰 기반

EPC 메모리 보호 메커니즘:

SGX 메모리 구조:

물리 메모리 구조:
┌─────────────────┐
│   Regular RAM   │ ← 일반 메모리
├─────────────────┤
│      PRM        │ ← Processor Reserved Memory
│   ┌─────────┐   │   (SGX 전용 보호 영역)
│   │   EPC   │   │   ← Enclave Page Cache
│   └─────────┘   │
└─────────────────┘

EPC 특성:
• CPU만 접근 가능한 보호된 메모리 영역
• OS, 하이퍼바이저, BIOS도 접근 불가
• 하드웨어 암호화/복호화 자동 처리

EPCM (EPC Map) 관리:

EPCM 역할:
• 각 EPC 페이지의 상태 추적
• 페이지 소유권 관리 (어떤 엔클레이브 소속)
• 접근 권한 검증 (읽기/쓰기/실행)
• OS 매핑 검증 (의도된 권한으로 매핑되었는지)

페이지 상태:
• INVALID: 사용되지 않는 페이지
• VALID: 엔클레이브가 사용 중인 페이지
• PENDING: 할당 중인 페이지
• MODIFIED: 수정된 페이지

메모리 접근 제어:

접근 모드별 제어:
일반 모드 (Ring 3): EPC 접근 시 #GP 예외 발생
엔클레이브 모드: EPC 접근 가능, EPCM 검증 수행

하드웨어 강제:
• CPU 마이크로코드 수준에서 접근 제어
• 소프트웨어로 우회 불가능
• 메모리 버스상 데이터 암호화

기존 가상 메모리와의 차이점:

보호 범위:

기존 가상 메모리:
• 프로세스 간 보호 (사용자-사용자)
• 사용자-커널 보호
• 페이지 단위 권한 설정 (RWX)

SGX EPC:
• 엔클레이브-외부 세계 보호
• 커널로부터도 보호
• 하드웨어 암호화 추가

신뢰 범위:

기존 시스템:
• OS 커널 신뢰 필요
• 하이퍼바이저 신뢰 필요
• 페이지 테이블 조작 가능

SGX:
• OS/하이퍼바이저 신뢰하지 않음
• CPU만 신뢰
• EPCM으로 OS 매핑 검증

성능 특성:

기존 메모리:
• 페이지 폴트 시 OS 개입
• 컨텍스트 스위치 오버헤드
• TLB 미스 처리

SGX:
• EPC 페이징 시 CPU 내부 처리
• 암호화/복호화 오버헤드
• 제한된 EPC 크기 (수백 MB)

3. SGX 사이드 채널 공격과 보안 한계

문제: Intel SGX에서 발생하는 페이지 테이블 기반 사이드 채널 공격의 메커니즘을 설명하고, 이러한 공격이 SGX의 보안 모델에 미치는 영향을 분석하시오.

모범답안:

페이지 테이블 기반 사이드 채널 공격:

공격 전제 조건:

SGX 설계의 딜레마:
• 엔클레이브 메모리는 CPU만 접근 가능
• 하지만 가상-물리 주소 매핑은 여전히 OS가 관리
• OS는 신뢰하지 않지만 페이지 테이블 제어권은 가짐

악의적 OS의 능력:
• 페이지 테이블 임의 조작 가능
• 페이지 폴트 핸들링 담당
• 메모리 매핑/언매핑 제어

공격 메커니즘:

1단계: 초기 설정

악의적 커널의 준비:
• 모든 EPC 페이지의 가상 주소 매핑 제거
• 페이지 테이블에서 Present 비트 클리어

초기 상태:
Virtual Address: [A][B][C][D][E][F][G]
Page Table:      [×][×][×][×][×][×][×] ← 모두 unmapped
Physical EPC:    [A][B][C][D][E][F][G]

2단계: 접근 추적

엔클레이브 실행 중:
func_main() → func_a() → func_d() → func_f()

각 함수 호출 시:
1. 해당 페이지 접근 시도
2. 페이지 폴트 발생 (#PF)
3. 커널 페이지 폴트 핸들러 호출
4. 커널이 어떤 페이지가 접근되었는지 학습
5. 해당 페이지만 매핑 생성
6. 엔클레이브 실행 재개

추적 결과:
Time 1: Page A fault → func_a() 실행 중
Time 2: Page D fault → func_d() 실행 중  
Time 3: Page F fault → func_f() 실행 중

3단계: 정보 유출

커널이 학습할 수 있는 정보:

1. 제어 흐름 추적:
   • 함수 호출 순서: A → D → F
   • 조건부 분기 결과
   • 루프 반복 횟수

2. 사용/미사용 판별:
   • 알고리즘 선택: Page A(암호화 A) 사용, Page E(암호화 B) 미사용
   • 코드 경로 분석

3. 입력 의존적 행동:
   • 특정 입력 시 특정 페이지 접근
   • 데이터 의존적 메모리 패턴

고급 공격 기법:

세밀한 관찰:

페이지 크기 활용:
• x86-64 기본 페이지 크기: 4KB
• 함수들을 다른 페이지에 배치하여 세밀한 추적
• 데이터 구조별 페이지 분리

시간 기반 분석:
• 페이지 폴트 발생 타이밍
• 함수 실행 시간 추정
• 브랜치 예측 실패 패턴

캐시 기반 사이드 채널:

CPU 캐시 활용:
• Last Level Cache (LLC) 상태 관찰
• 메모리 접근 패턴으로 암호 키 추출
• Prime+Probe, Flush+Reload 기법 적용

예시 공격:
• CacheZoom: AES 키 추출
• Software Grand Exposure: RSA 키 공격
• 암호화 라이브러리 취약점 악용

SGX 보안 모델에 미치는 영향:

보안 가정의 붕괴:

원래 SGX 가정:
"엔클레이브 내부 실행은 외부에서 관찰할 수 없다"

현실:
• 페이지 접근 패턴으로 내부 로직 추론 가능
• 메모리 접근으로 암호화 키 유출 가능
• 입력 데이터와 출력 결과 연관성 파악 가능

기밀성 위협:

정보 유출 유형:
1. 알고리즘 선택 정보
   • 어떤 암호화 알고리즘 사용 중인지
   • 키 길이, 모드 선택 등

2. 처리 데이터 특성
   • 이미지 vs 텍스트 데이터 구별
   • 압축률, 엔트로피 추정

3. 사용자 행동 패턴
   • 로그인 시도 횟수
   • 메뉴 선택 패턴

완화 기법과 한계:

소프트웨어 완화:

코드 패딩:
• 모든 분기에서 동일한 페이지 접근 패턴 유지
• 더미 메모리 접근으로 패턴 은닉

실행 시간 정규화:
• 모든 함수가 동일한 시간 소요하도록 조정
• 더미 연산으로 시간 차이 은닉

한계:
• 성능 오버헤드 증가
• 완벽한 은닉 어려움
• 새로운 사이드 채널 발견 가능

하드웨어 완화:

Intel의 대응:
• SGX2: 동적 메모리 관리 개선
• 페이지 크기 확대 옵션
• 하드웨어 노이즈 추가

근본적 한계:
• 가상 메모리 추상화 의존성
• OS 불신 vs 페이지 테이블 의존성 모순
• 성능과 보안의 트레이드오프

장기적 영향:

SGX 적용 제약:
• 고도의 보안이 필요한 용도에서 사용 제한
• 사이드 채널 저항성 고려한 설계 필수
• 대안 기술 개발 촉진 (ARM TrustZone 등)

연구 방향:
• 사이드 채널 저항 프로그래밍 기법
• 하드웨어 기반 완화 기법
• 새로운 TEE 아키텍처 개발

4. SGX 프로그래밍 모델과 실용적 고려사항

문제: SGX 프로그래밍에서 코드 분할 모델과 라이브러리 포팅 모델의 차이점을 설명하고, 각각의 장단점과 적용 시나리오를 분석하시오.

모범답안:

코드 분할 모델 (Code Partitioning Model):

설계 원칙:

민감도 기반 분할:
1. 프로그램 비밀 식별
   • 암호화 키, 개인정보, 알고리즘 로직
   • 공개되면 안 되는 중요 데이터

2. 위험 함수 분석  
   • 비밀과 직접 상호작용하는 함수
   • 비밀을 노출할 가능성이 있는 함수
   • 보안 정책을 구현하는 함수

3. TCB 최소화
   • 신뢰해야 하는 코드 최소한으로 제한
   • 복잡한 로직은 가능한 한 외부로 분리

분할 예시:

패스워드 관리자 분할:

Trusted (Enclave):
┌─────────────────┐
│ 마스터 패스워드  │ ← 핵심 비밀
├─────────────────┤
│ 암호화/복호화   │ ← 비밀 처리 로직
├─────────────────┤
│ TLS 세션 키     │ ← 통신 보안
├─────────────────┤
│ 키 유도 함수    │ ← 암호학적 연산
└─────────────────┘

Untrusted (Application):
┌─────────────────┐
│ 사용자 인터페이스│ ← 복잡하지만 민감하지 않음
├─────────────────┤
│ 파일 I/O        │ ← OS 의존적 기능
├─────────────────┤
│ 네트워크 소켓   │ ← 시스템 리소스
├─────────────────┤
│ 설정 관리       │ ← 일반적 기능
└─────────────────┘

ECALL/OCALL 인터페이스:

Interface Design Language (EDL):

enclave {
    trusted {
        // 엔클레이브로 들어오는 호출
        public int ecall_encrypt_password([in, string] char* password);
        public int ecall_decrypt_password([out, size=maxlen] char* buffer, 
                                         size_t maxlen);
        public int ecall_derive_key([in, size=32] uint8_t* salt);
    };
    
    untrusted {
        // 엔클레이브에서 나가는 호출  
        int ocall_write_file([in, string] char* filename,
                            [in, size=len] uint8_t* data, size_t len);
        int ocall_read_file([in, string] char* filename,
                           [out, size=maxlen] uint8_t* buffer, size_t maxlen);
        void ocall_print_message([in, string] char* message);
    };
};

특징:
• 방향성 명시: [in], [out], [in,out]
• 버퍼 크기 지정: size=len
• 문자열 처리: [string]
• 컴파일러가 자동으로 마샬링 코드 생성

라이브러리 포팅 모델 (Library Porting Model):

포팅 전략:

전체 라이브러리 포팅:
• 기존 라이브러리를 SGX 환경으로 이식
• API 시그니처 최대한 유지
• 내부 구현은 SGX에 맞게 수정

포팅 대상 라이브러리:
• 암호화: OpenSSL, wolfSSL, mbedTLS
• 압축: zlib, lz4
• 이미지: libjpeg, libpng  
• 네트워킹: TLS 라이브러리
• 수학: 수치 연산 라이브러리

포팅 과정:

1. 시스템 의존성 분석:
   • 시스템 콜 사용 부분 식별
   • 파일 I/O, 네트워킹, 메모리 관리 등

2. OCALL 래퍼 구현:
   • malloc() → ocall_malloc() → 외부에서 실제 malloc()
   • printf() → ocall_printf() → 외부에서 실제 printf()
   • socket() → ocall_socket() → 외부에서 실제 socket()

3. 라이브러리 API ECALL로 노출:
   • SSL_connect() → ecall_ssl_connect()
   • AES_encrypt() → ecall_aes_encrypt()
   • 복잡한 매개변수는 직렬화/역직렬화

4. 빌드 시스템 수정:
   • SGX SDK 도구체인 사용
   • 특별한 컴파일 플래그 적용
   • 의존성 라이브러리 함께 포팅

모델별 비교 분석:

코드 분할 모델:

장점:
✓ TCB 크기 최소화
✓ 공격 표면 축소
✓ 명확한 보안 경계
✓ 세밀한 보안 제어
✓ 성능 최적화 가능

단점:
✗ 설계 복잡도 증가
✗ 인터페이스 설계 부담
✗ 기존 코드 대폭 수정 필요
✗ ECALL/OCALL 오버헤드
✗ 디버깅 어려움

적용 시나리오:
• 새로운 보안 애플리케이션 개발
• 명확한 보안 요구사항이 있는 경우
• 성능이 중요한 암호화 작업
• 소규모 핵심 기능 보호

라이브러리 포팅 모델:

장점:
✓ 기존 코드 재사용
✓ 개발 시간 단축
✓ API 호환성 유지
✓ 검증된 라이브러리 활용
✓ 팀 학습 곡선 완화

단점:
✗ 큰 TCB 크기
✗ 넓은 공격 표면
✗ 포팅 작업 복잡성
✗ 성능 오버헤드 증가
✗ 의존성 관리 어려움

적용 시나리오:
• 기존 애플리케이션의 SGX 마이그레이션
• 복잡한 라이브러리 의존성이 있는 경우
• 개발 리소스가 제한적인 상황
• 프로토타이핑과 빠른 개발 필요

실제 선택 기준:

보안 우선 시나리오:

코드 분할 모델 선택:
• 금융 거래 시스템
• 의료 데이터 처리
• 정부/군사 애플리케이션
• 개인키 관리 시스템

설계 고려사항:
• 최소 권한 원칙 적용
• 인터페이스 최소화
• 입력 검증 강화
• 사이드 채널 저항성 고려

개발 효율성 우선 시나리오:

라이브러리 포팅 모델 선택:
• 클라우드 서비스 마이그레이션
• 기존 시스템 보안 강화
• 개념 증명 (PoC) 개발
• 시장 출시 시간 중요한 경우

포팅 우선순위:
1. 핵심 비즈니스 로직 라이브러리
2. 암호화/보안 관련 라이브러리
3. 데이터 처리 라이브러리
4. 기타 유틸리티 라이브러리

하이브리드 접근법:

현실적 해결책:
• 핵심 보안 기능: 코드 분할 모델
• 지원 기능: 라이브러리 포팅 모델
• 점진적 마이그레이션: 포팅 → 분할

예시 아키텍처:
┌─────────────────┐
│   Application   │ ← 기존 코드 유지
├─────────────────┤
│ Crypto Library  │ ← 포팅된 라이브러리 (OpenSSL)
├─────────────────┤
│  Core Secrets   │ ← 분할된 핵심 보안 코드
└─────────────────┘

장점:
• 개발 효율성과 보안 모두 고려
• 단계적 보안 강화 가능
• 리스크 분산

핵심 요약

• 시스템 보안은 하드웨어부터 애플리케이션까지 모든 계층의 접근 제어를 포함하며, TCB 최소화와 권한 분리가 핵심 원칙
• x86 권한 링 구조와 페이징 시스템을 통해 하드웨어 수준에서 메모리 접근 제어와 특권 명령어 실행 제한 구현
• 커널 루트킷은 최고 권한으로 모든 보안 메커니즘을 무력화할 수 있어 하드웨어 기반 보안 솔루션의 필요성 증대
• Intel SGX는 "CPU만 신뢰" 모델로 엔클레이브를 통해 OS/하이퍼바이저로부터도 코드와 데이터를 보호하는 혁신적 TEE 구현
• **EPC(Enclave Page Cache)**와 EPCM을 통한 하드웨어 기반 메모리 보호로 소프트웨어 공격 원천 차단
• **원격 증명(Remote Attestation)**을 통해 클라우드 환경에서도 신뢰할 수 있는 실행 환경 검증 가능
• 사이드 채널 공격(페이지 테이블, 캐시)은 SGX의 주요 한계로, 메모리 접근 패턴을 통한 정보 유출 위험 존재
• SGX 프로그래밍 모델은 코드 분할(보안 우선)과 라이브러리 포팅(개발 효율성 우선)으로 나뉘며, 각각 장단점과 적용 시나리오가 다름

💡 중요: SGX는 클라우드 기밀 컴퓨팅의 핵심 기술이지만 사이드 채널 공격과 보안 I/O 한계 등으로 완벽하지 않습니다. 현실적으로는 위험 분석 기반의 적절한 보안 모델 선택과 다층 방어 전략이 필요하며, ARM TrustZone 등 대안 기술과의 비교 검토도 중요합니다.