Secure Boot 심화

Secure Boot 심화: UEFI 키 계층과 모드 상태, dbx/SBAT 폐기, Shim/MOK, UKI, UEFI HTTP Boot와 서명된 iPXE, 모듈 서명, TPM/LUKS2, OVMF 실습, 배포판 운영 패턴, dm-verity/fs-verity, Lockdown을 다룹니다.

UEFI Secure Boot 신뢰 체인, Setup/User/Audit/Deployed 모드, Authenticode 서명 구조, SBAT 폐기 메커니즘, UKI(systemd-stub), 커널 모듈 서명, IMA/EVM, TPM Measured Boot, dm-verity/fs-verity — 부트에서 런타임까지 이어지는 무결성 계층을 소스 코드 수준에서 분석합니다.

Secure Boot 아키텍처 개요

UEFI Secure Boot는 플랫폼 펌웨어가 부팅 과정에서 실행하는 모든 EFI 바이너리의 디지털 서명을 검증하여, 신뢰할 수 없는 코드의 실행을 차단하는 보안 메커니즘입니다. 이 검증은 PKI(Public Key Infrastructure) 기반의 신뢰 체인(Chain of Trust)으로 구현됩니다.

보안 목표와 신뢰 경계

Secure Boot를 정확히 쓰려면 "무엇을 보장하고 무엇을 보장하지 않는지"를 먼저 분리해야 합니다. Secure Boot는 허용된 EFI 이미지 실행에는 강하지만, 펌웨어 취약점 자체나 런타임 파일 변조까지 자동으로 해결해 주지는 않습니다.

Secure Boot UEFI 변수

Secure Boot의 핵심은 NVRAM에 저장된 인증된(authenticated) UEFI 변수들입니다:

Secure Boot 모드 전이

UEFI 2.10은 Secure Boot 상태를 단순히 켜짐/꺼짐으로만 보지 않습니다. 실제 운영에서는 Setup Mode, User Mode, Audit Mode, Deployed Mode 네 상태를 이해해야 키 등록, 검증 우회, 현장 복구 절차를 정확히 설명할 수 있습니다.

EFI_VARIABLE_AUTHENTICATION_2 구조체

Secure Boot 변수(db, dbx, KEK 등)는 인증된 업데이트만 허용합니다. 변수를 수정하려면 EFI_VARIABLE_AUTHENTICATION_2 래퍼로 감싸야 합니다:

typedef struct {
    EFI_TIME                    TimeStamp;    /* 재전송 방지용 타임스탬프 */
    WIN_CERTIFICATE_UEFI_GUID   AuthInfo;     /* PKCS#7 서명 래퍼 */
} EFI_VARIABLE_AUTHENTICATION_2;

typedef struct {
    UINT32    dwLength;          /* 인증서 전체 크기 */
    UINT16    wRevision;         /* WIN_CERT_REVISION = 0x0200 */
    UINT16    wCertificateType;  /* WIN_CERT_TYPE_EFI_GUID */
    EFI_GUID  CertType;          /* EFI_CERT_TYPE_PKCS7_GUID */
    UINT8     CertData[1];       /* DER 인코딩된 PKCS#7 SignedData */
} WIN_CERTIFICATE_UEFI_GUID;

Authenticode 서명 형식

UEFI 실행 파일(shimx64.efi, grubx64.efi, vmlinuz.efi)은 PE/COFF(Portable Executable) 형식이며, Authenticode 서명으로 무결성이 검증됩니다.

PE/COFF 서명 구조

Authenticode 해시 계산

Authenticode 해시는 일반적인 파일 해시와 다릅니다. 서명 자체와 체크섬 필드를 제외하고 해시를 계산합니다:

/* Authenticode 해시에서 제외되는 영역:
 * 1. PE Optional Header의 Checksum 필드 (4 bytes)
 * 2. Data Directory[4] Certificate Table 엔트리 (8 bytes)
 *    — PE32/PE32+ 공통 인덱스(구조적 정의).
 *      파일 내 절대 오프셋은 Optional Header 크기에 따라 다름:
 *      PE32(32-bit):  Certificate Table → 오프셋 0x98
 *      PE32+(64-bit): Certificate Table → 오프셋 0xA8
 *      → 절대 오프셋 대신 PE 헤더 파서의 구조적 필드 접근 필요
 * 3. WIN_CERTIFICATE 영역 전체 (서명 데이터)
 *
 * 나머지 모든 바이트가 해시에 포함됨
 */

# sbsign으로 커널 서명
$ sbsign --key db.key --cert db.crt --output vmlinuz.signed vmlinuz.efi

# 서명 검증
$ sbverify --cert db.crt vmlinuz.signed
Signature verification OK

# Authenticode 해시 확인
$ pesign -i vmlinuz.signed -h -P
# SHA-256 해시 출력

# 서명 정보 상세 출력
$ pesign -i vmlinuz.signed -S
---------------------------------------------
certificate address is 0x...
Content was not encrypted.
Content is a detached PKCS#7 signature
Signing time: ...
Signer's common name: My Secure Boot Key
...

서명 도구 비교

폐기 메커니즘: dbx와 SBAT

취약점이 발견된 부트로더나 커널을 차단하려면 폐기(revocation) 메커니즘이 필요합니다. UEFI는 두 가지 방식을 제공합니다.

dbx (전통적 방식)

dbx는 차단할 바이너리의 해시 또는 서명 인증서를 기록합니다:

# dbx 현재 내용 확인
$ efi-readvar -v dbx
Variable dbx, length 13588
dbx: List 0, type SHA256
    Hash: a4:6f:0c:2e:...  # 차단된 바이너리 해시

# dbx 업데이트 (KEK로 서명된 업데이트 적용)
$ efi-updatevar -f dbx-update.auth dbx

# dbx에 새 해시 추가 (Linux fwupd 사용)
$ fwupdmgr get-updates
$ fwupdmgr update

SBAT (Secure Boot Advanced Targeting)

SBAT는 dbx의 확장성 문제를 해결하기 위해 도입된 세대 기반(generation-based) 폐기 메커니즘입니다. 개별 해시 대신 컴포넌트의 보안 세대 번호를 비교합니다.

/* SBAT 메타데이터 (.sbat 섹션, CSV 형식)
 *
 * shimx64.efi의 .sbat 섹션 예시:
 */
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
shim,4,UEFI shim,shim,1,https://github.com/rhboot/shim
shim.ubuntu,2,Canonical Ltd.,shim,15.8,https://launchpad.net/ubuntu/+source/shim

/* GRUB2의 .sbat 섹션 예시: */
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,4,Free Software Foundation,grub,2.12,https://www.gnu.org/software/grub/
grub.ubuntu,2,Canonical Ltd.,grub2,2.12-1ubuntu1,https://launchpad.net/ubuntu/+source/grub2

SBAT 폐기 정책은 SbatLevel 변수에 저장됩니다. upstream shim 저장소의 2025년 5월 10일 기준 샘플은 이미 2024년 shim 취약점, 2025년 GRUB 취약점, 특정 배포판별 추가 폐기를 반영하고 있습니다:

# SbatLevel 확인
$ mokutil --list-sbat-revocations
sbat,1,2025051000
shim,4
grub,5
grub.peimage,2
grub.proxmox,2

# 해석:
# - shim 세대가 4 미만이면 거부
# - grub 전역 세대가 5 미만이면 거부
# - grub.proxmox 세대가 2 미만이면 해당 제품 계열만 추가 거부

SBAT vs dbx 비교

Shim과 MOK 인프라

대부분의 Linux 배포판은 Microsoft UEFI CA가 서명한 Shim 부트로더를 1단계로 사용합니다. Shim은 자체 키 데이터베이스(MOK)를 관리하여 배포판별 2단계 부트로더와 커널을 검증합니다.

Shim 검증 로직

/*
 * shim의 EFI 바이너리 검증 순서 (verify_buffer 함수):
 *
 * 1. dbx (UEFI 폐기 목록) 확인 → 해시/인증서 매치 시 거부
 * 2. SBAT 검증 → SbatLevel 미달 시 거부
 * 3. db (UEFI 허용 목록) 검증 → 매치 시 허용
 * 4. MOK (Machine Owner Key) 검증 → 매치 시 허용
 * 5. shim 내장 인증서 검증 → 매치 시 허용
 * 6. 모두 실패 → 거부
 */

/* shim 소스 코드에서의 핵심 검증 흐름 (간략화): */
static EFI_STATUS
verify_buffer(char *data, int datasize,
              PE_COFF_LOADER_IMAGE_CONTEXT *context)
{
    /* Step 1: dbx 확인 (차단 목록) */
    if (check_denylist(context, data, datasize) == FOUND)
        return EFI_ACCESS_DENIED;

    /* Step 2: SBAT 확인 */
    if (verify_sbat_section(data, datasize) != EFI_SUCCESS)
        return EFI_SECURITY_VIOLATION;

    /* Step 3-5: 허용 목록 순서대로 확인 */
    if (check_allowlist(context, data, datasize) == FOUND)
        return EFI_SUCCESS;

    return EFI_ACCESS_DENIED;
}

MOK 관리

# 자체 서명 키 생성
$ openssl req -new -x509 -newkey rsa:2048 -keyout MOK.key \
    -out MOK.crt -nodes -days 3650 \
    -subj "/CN=My Secure Boot MOK"

# DER 형식으로 변환 (MOK 등록에 필요)
$ openssl x509 -in MOK.crt -outform DER -out MOK.der

# MOK 등록 요청 (다음 부팅 시 MokManager에서 확인)
$ mokutil --import MOK.der
# 비밀번호 입력 → 재부팅 시 MokManager UI에서 동일 비밀번호 입력

# 등록된 MOK 목록 확인
$ mokutil --list-enrolled
[key 1]
SHA1 Fingerprint: ab:cd:ef:...
Subject: CN = My Secure Boot MOK
Issuer:  CN = My Secure Boot MOK

# MOK 삭제
$ mokutil --delete MOK.der

# Secure Boot 상태 확인
$ mokutil --sb-state
SecureBoot enabled
SecureBoot validation is enabled in shim

MOK UEFI 변수

Secure Boot와 네트워크 부팅 체인

PXE나 HTTP Boot는 EFI 이미지를 어디서 가져올지를 정하는 전달 경로이고, Secure Boot는 그 이미지를 실행해도 되는지를 서명으로 판단하는 정책입니다. 따라서 UEFI 네트워크 부팅에서는 "전송 경로"와 "신뢰 체인"을 분리해서 봐야 합니다. 실무에서 가장 흔한 경로는 firmware db가 shimx64.efi를 검증하고, shim이 grubx64.efi 또는 서명된 ipxe.efi를 검증한 뒤, 그 다음 단계 로더가 설치 커널이나 UKI를 넘기는 구조입니다.

UKI (Unified Kernel Image)와 최신 Linux 부트 체인

최근 Linux 배포판은 UKI(Unified Kernel Image)를 적극 채택하고 있습니다. UKI는 커널, initrd, 커맨드라인, SBAT, PCR 정책 정보를 하나의 PE/COFF UEFI 애플리케이션에 묶어서 Secure Boot 검증 단위를 단순화합니다.

UKI 구성 요소

UAPI Group UKI 명세는 UKI를 IMAGE_SUBSYSTEM_EFI_APPLICATION을 가진 PE/COFF 파일로 정의합니다. 최소 필수 섹션은 .linux이고, 여기에 운영 정보와 보안 메타데이터를 추가합니다.

# UKI 내부 섹션 확인
$ objdump -h vmlinuz.efi | grep -E "\\.(linux|initrd|cmdline|osrel|uname|sbat|pcrsig|pcrpkey)"

# SBAT 섹션만 추출
$ objcopy --dump-section .sbat=/tmp/sbat.csv vmlinuz.efi

# PE 서명 검증
$ sbverify --list vmlinuz.efi

UKI와 TPM PCR 11/12/13

Linux TPM PCR Registry는 systemd 기반 흐름에서 PCR 11을 UKI의 정적 구성 측정에, PCR 12를 커맨드라인/credential/add-on 입력에, PCR 13을 initrd 확장 이미지에 사용하는 패턴을 정리해 두고 있습니다.

GRUB 체인과 UKI 체인의 차이

systemd 기반 UKI 제작·서명·자동 등록

최근 systemd 도구 체인은 ukify, systemd-sbsign, bootctl, loader.conf를 조합해 GRUB 없이도 Secure Boot 체인을 구축할 수 있게 설계되어 있습니다. 특히 테스트용 가상 머신에서는 secure-boot-enroll=if-safe를 사용해 Setup Mode에서 자동 키 등록까지 실험할 수 있습니다.

# 1. UKI 빌드
$ ukify build \
    --linux=/usr/lib/modules/$(uname -r)/vmlinuz \
    --initrd=/boot/initramfs-$(uname -r).img \
    --cmdline=@/etc/kernel/cmdline \
    --os-release=@/etc/os-release \
    --secureboot-private-key=/etc/kernel/secureboot-private-key.pem \
    --secureboot-certificate=/etc/kernel/secureboot-certificate.pem \
    --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \
    --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem \
    --output=/efi/EFI/Linux/linux-$(uname -r).efi

# 2. 필요하면 별도 재서명
$ systemd-sbsign sign \
    --private-key=/etc/kernel/secureboot-private-key.pem \
    --certificate=/etc/kernel/secureboot-certificate.pem \
    --output=/efi/EFI/Linux/linux-$(uname -r).efi.signed \
    /efi/EFI/Linux/linux-$(uname -r).efi

# 3. sd-boot 설치 + auto-enroll payload 생성
$ bootctl install \
    --secure-boot-auto-enroll=yes \
    --certificate=/etc/kernel/secureboot-certificate.pem \
    --private-key=/etc/kernel/secureboot-private-key.pem

# 4. /efi/loader/loader.conf
default @saved
timeout 3
secure-boot-enroll if-safe
secure-boot-enroll-action reboot

커널 모듈 서명

Secure Boot 환경에서 커널 모듈은 로드 시 서명이 검증됩니다. 서명 정책은 CONFIG_MODULE_SIG 관련 설정으로 제어합니다.

커널 설정

# 모듈 서명 관련 커널 설정 (Security options → Module signature verification)
CONFIG_MODULE_SIG=y            # 모듈 서명 검증 활성화
CONFIG_MODULE_SIG_FORCE=y      # 서명 없는 모듈 로드 거부 (Secure Boot 시 필수)
CONFIG_MODULE_SIG_ALL=y        # 빌드 시 모든 모듈 자동 서명

# 서명 해시 알고리즘 선택
CONFIG_MODULE_SIG_SHA256=y     # SHA-256 (기본)
# CONFIG_MODULE_SIG_SHA384=y
# CONFIG_MODULE_SIG_SHA512=y
# CONFIG_MODULE_SIG_SHA3_256=y
# CONFIG_MODULE_SIG_SHA3_384=y
# CONFIG_MODULE_SIG_SHA3_512=y

# 서명 키 경로
CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"     # 서명용 개인키
CONFIG_SYSTEM_TRUSTED_KEYRING=y                   # 시스템 신뢰 키링
CONFIG_SYSTEM_TRUSTED_KEYS="certs/signing_key.pem" # 빌트인 인증서

# 추가 신뢰 키 소스
CONFIG_SECONDARY_TRUSTED_KEYRING=y                # 런타임 추가 키링
CONFIG_INTEGRITY_PLATFORM_KEYRING=y               # 플랫폼(Secure Boot) 키링

sign-file 도구

# 커널 빌드 시 자동으로 호출되는 모듈 서명 명령
$ scripts/sign-file sha256 \
    certs/signing_key.pem \
    certs/signing_key.x509 \
    drivers/my_driver.ko

# sign-file 내부 동작:
# 1. 모듈 ELF 바이너리 전체를 SHA-256으로 해시
# 2. 개인키로 PKCS#7 서명 생성
# 3. 서명을 모듈 파일 끝에 추가 (append)
# 4. module_signature 구조체를 맨 끝에 추가

# HSM/토큰을 쓰는 경우 PKCS#11 URI도 가능
$ scripts/sign-file sha512 \
    "pkcs11:token=KernelSigner;object=signing-key;type=private" \
    kernel-signing.x509 \
    drivers/my_driver.ko

모듈 서명 구조

/* include/linux/module_signature.h */
struct module_signature {
    u8    algo;          /* 공개키 알고리즘 (RSA, ECDSA ...) */
    u8    hash;          /* 해시 알고리즘 (SHA-256, SHA-512 ...) */
    u8    id_type;       /* 키 식별 타입 (PKEY_ID_PKCS7) */
    u8    signer_len;    /* 서명자 이름 길이 (PKCS#7에서는 0) */
    u8    key_id_len;    /* 키 ID 길이 (PKCS#7에서는 0) */
    u8    __pad[3];      /* 패딩 */
    __be32 sig_len;       /* 서명 데이터 길이 (빅 엔디안) */
};

/*
 * 모듈 파일 레이아웃:
 * (시각화는 아래 SVG 참고)
 */

모듈 서명 검증 흐름

/* kernel/module/signing.c - mod_verify_sig() 간략화 */
int mod_verify_sig(const void *mod, struct load_info *info)
{
    struct module_signature ms;
    size_t sig_len, modlen = info->len;

    /* 매직 문자열 확인 */
    if (memcmp(mod + modlen - 28,
              "~Module signature appended~\\n", 28) != 0)
        return -ENODATA;  /* 서명 없음 */

    /* module_signature 구조체 읽기 */
    memcpy(&ms, mod + modlen - 28 - sizeof(ms), sizeof(ms));
    sig_len = be32_to_cpu(ms.sig_len);

    /* PKCS#7 서명 검증 (시스템 키링의 인증서 사용) */
    return verify_pkcs7_signature(
        mod,                       /* 서명 대상 데이터 */
        modlen - sig_len - 28 - sizeof(ms), /* 데이터 길이 */
        mod + modlen - 28 - sizeof(ms) - sig_len,
        sig_len,
        VERIFY_USE_SECONDARY_KEYRING,  /* .secondary_trusted_keys */
        VERIFYING_MODULE_SIGNATURE,
        NULL, NULL);
}

/*
 * 키링 검색 순서:
 * 1. .builtin_trusted_keys  (커널 빌드 시 내장된 인증서)
 * 2. .secondary_trusted_keys (런타임 추가, MOK에서 import된 키)
 * 3. .platform_keyring       (UEFI Secure Boot db에서 가져온 키)
 */

모듈 서명 실무 명령

# 모듈 서명 확인
$ modinfo drivers/my_driver.ko | grep sig
sig_id:         PKCS#7
signer:         Build time autogenerated kernel key
sig_key:        AB:CD:12:34:...
sig_hashalgo:   sha256

# 서명 유효성 검증 (kmod 도구)
$ modprobe --dump-modversions drivers/my_driver.ko

# 시스템 키링 확인
$ keyctl list %:.builtin_trusted_keys
1 key in keyring:
 123456789: ---lswrv     0     0 asymmetri: Build time autogenerated kernel key: ab:cd:...

$ keyctl list %:.secondary_trusted_keys
2 keys in keyring:
 234567890: ---lswrv     0     0 asymmetri: My Secure Boot MOK: 12:34:...

# DKMS 모듈 자동 서명 (MOK 키 사용)
# /etc/dkms/framework.conf:
# sign_tool="/etc/dkms/sign_helper.sh"
# mok_signing_key="/var/lib/shim-signed/mok/MOK.priv"
# mok_certificate="/var/lib/shim-signed/mok/MOK.der"

# 런타임 강제 여부 확인
$ cat /proc/cmdline | tr ' ' '\\n' | grep module.sig_enforce
module.sig_enforce=1

Kernel Lockdown LSM

Secure Boot의 신뢰 체인은 커널이 부팅된 후에도 유지되어야 합니다. Lockdown LSM은 커널 무결성을 우회할 수 있는 사용자 공간의 인터페이스를 제한합니다.

Lockdown 레벨

Lockdown 제한 항목

/* security/lockdown/lockdown.c - Lockdown이 차단하는 기능들 */

/* integrity 레벨에서 차단: */
LOCKDOWN_MODULE_SIGNATURE,          /* 서명 없는 모듈 로드 */
LOCKDOWN_DEV_MEM,                   /* /dev/mem, /dev/kmem 쓰기 */
LOCKDOWN_EFI_TEST,                  /* EFI 테스트 모드 변수 */
LOCKDOWN_KEXEC,                     /* 서명 없는 kexec 이미지 */
LOCKDOWN_HIBERNATION,               /* 하이버네이션 (이미지 변조 가능) */
LOCKDOWN_PCI_ACCESS,                /* PCI BAR 직접 접근 */
LOCKDOWN_IOPORT,                    /* I/O 포트 직접 접근 */
LOCKDOWN_MSR,                       /* MSR 쓰기 (/dev/cpu/*/msr) */
LOCKDOWN_ACPI_TABLES,               /* 커스텀 ACPI 테이블 로드 */
LOCKDOWN_DEVICE_TREE,               /* 디바이스 트리 오버레이 */
LOCKDOWN_PCMCIA_CIS,                /* PCMCIA CIS 오버라이드 */
LOCKDOWN_TIOCSSERIAL,               /* 시리얼 포트 I/O 변경 */
LOCKDOWN_MODULE_PARAMETERS,         /* 위험한 모듈 파라미터 */
LOCKDOWN_MMIOTRACE,                 /* MMIO 트레이싱 */
LOCKDOWN_DEBUGFS,                   /* debugfs 접근 */
LOCKDOWN_XMON_WR,                   /* PowerPC xmon 쓰기 */
LOCKDOWN_BPF_WRITE_USER,            /* BPF 사용자 메모리 쓰기 */
LOCKDOWN_DBG_WRITE_KERNEL,          /* /proc/kcore 등 커널 메모리 쓰기 */

/* confidentiality 레벨에서 추가 차단: */
LOCKDOWN_KPROBES,                   /* kprobes 사용 */
LOCKDOWN_TRACEFS,                   /* tracefs (ftrace) 접근 */
LOCKDOWN_PERF,                      /* perf 하드웨어 이벤트 */
LOCKDOWN_XMON_RW,                   /* PowerPC xmon 읽기/쓰기 */
LOCKDOWN_DBG_READ_KERNEL,           /* /proc/kcore 등 커널 메모리 읽기 */
LOCKDOWN_BPF_READ_KERNEL,           /* BPF 커널 메모리 읽기 */

Lockdown 상태 확인 및 제어

# Lockdown 상태 확인
$ cat /sys/kernel/security/lockdown
none [integrity] confidentiality

# dmesg에서 Lockdown 메시지
$ dmesg | grep -i lockdown
Lockdown: Kernel is locked down from EFI Secure Boot mode; see man kernel_lockdown.7
Lockdown: debugfs: restricted; see man kernel_lockdown.7
Lockdown: tracefs: restricted; see man kernel_lockdown.7

# 커널 커맨드라인에서 Lockdown 설정
# lockdown=integrity    (integrity 모드 강제)
# lockdown=confidentiality (confidentiality 모드 강제)

# 커널 설정
CONFIG_SECURITY_LOCKDOWN_LSM=y
CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y
CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT=y  # Secure Boot 시 자동 integrity

IMA/EVM — 런타임 무결성 검증

IMA(Integrity Measurement Architecture)와 EVM(Extended Verification Module)은 부팅 이후 파일 시스템 수준에서 무결성을 보장합니다. Secure Boot가 부팅 체인의 무결성을 보장하면, IMA는 런타임 파일 접근의 무결성을 보장합니다.

IMA 아키텍처

IMA 동작 모드

IMA 정책

# 커널 커맨드라인 IMA 옵션
ima_policy=tcb                # 기본 TCB 정책 (실행 파일, 라이브러리, 모듈)
ima_policy=appraise_tcb       # TCB + appraise 모드
ima_policy=secure_boot        # Secure Boot 연동 정책
ima_appraise=enforce          # appraise 실패 시 파일 접근 거부
ima_appraise=log              # appraise 실패 시 로그만 기록

# 런타임 정책 파일 (/etc/ima/ima-policy 또는 securityfs)
# 정책 형식: action condition [condition ...]

# 실행되는 모든 파일 측정
measure func=BPRM_CHECK

# root가 실행하는 파일의 서명 검증 강제
appraise func=BPRM_CHECK uid=0 appraise_type=imasig

# 커널 모듈 로드 시 서명 검증
appraise func=MODULE_CHECK appraise_type=imasig

# 펌웨어 로드 시 서명 검증
appraise func=FIRMWARE_CHECK appraise_type=imasig

# kexec 커널 이미지 서명 검증
appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig

# 특정 라벨의 파일만 측정 (SELinux 연동)
measure func=FILE_MMAP obj_type=lib_t

# 정책 로드 (securityfs)
$ cat /etc/ima/ima-policy > /sys/kernel/security/ima/policy

IMA 확장 속성

# IMA 확장 속성 확인
$ getfattr -m ^security -d /sbin/init
security.ima=0x...    # IMA 서명 또는 해시
security.evm=0x...    # EVM HMAC 또는 서명

# IMA 서명 설정 (evmctl 사용)
$ evmctl ima_sign -k /path/to/private_key.pem /sbin/init

# IMA 해시 설정
$ evmctl ima_hash /sbin/init

# 측정 목록 확인
$ cat /sys/kernel/security/ima/ascii_runtime_measurements
10 abc123... ima-sig sha256:def456... /sbin/init

# 위반 목록 확인
$ cat /sys/kernel/security/ima/violations
0

EVM (Extended Verification Module)

EVM은 IMA 확장 속성 자체의 무결성을 보호합니다. 공격자가 security.ima 속성을 위변조하는 것을 방지합니다:

/*
 * EVM 보호 대상 확장 속성:
 * - security.ima     (IMA 해시/서명)
 * - security.selinux (SELinux 라벨)
 * - security.SMACK64 (SMACK 라벨)
 * - security.capability (파일 capability)
 *
 * EVM은 이 속성들의 HMAC 또는 디지털 서명을
 * security.evm에 저장하여 변조를 감지합니다.
 */

# EVM 초기화 (HMAC 모드 — TPM 기반 키)
$ echo 1 > /sys/kernel/security/evm

# EVM 서명 모드 (공개키 기반)
$ evmctl sign -k /path/to/evm-key.pem /sbin/init

# 커널 설정
CONFIG_EVM=y
CONFIG_EVM_ATTR_FSUUID=y          # 파일시스템 UUID도 HMAC에 포함
CONFIG_EVM_ADD_XATTRS=y           # 추가 xattr을 EVM 보호에 포함

TPM과 Measured Boot

Secure Boot(검증 부팅)과 Measured Boot(측정 부팅)는 상호 보완적인 메커니즘입니다. Secure Boot는 신뢰할 수 없는 코드의 실행을 차단하고, Measured Boot는 실행된 코드의 해시를 기록하여 사후 검증을 가능하게 합니다.

TPM PCR (Platform Configuration Register)

/*
 * TPM PCR 할당 (TCG PC Client 규격):
 *
 * PCR  0: SRTM, BIOS, 호스트 플랫폼 Extension, 임베디드 옵션 ROM
 * PCR  1: 호스트 플랫폼 설정
 * PCR  2: 옵션 ROM 코드
 * PCR  3: 옵션 ROM 설정 및 데이터
 * PCR  4: IPL 코드 (부트로더), MBR
 * PCR  5: IPL 코드 설정 및 데이터
 * PCR  6: 상태 전이 및 Wake 이벤트
 * PCR  7: Secure Boot 정책 — PK, KEK, db, dbx,
 *         SecureBoot 변수, 부트 관리자 측정
 * PCR  8-15: OS 정의 — Linux에서는:
 * PCR  8: GRUB2 커맨드라인/설정
 * PCR  9: GRUB2에서 로드한 파일 (커널, initrd)
 * PCR 10: IMA 측정 목록
 * PCR 11-13: (배포판별 정의)
 * PCR 14: MOK 인증서/키
 */

# TPM PCR 값 읽기
$ tpm2_pcrread sha256:0,1,4,7,10
  sha256:
    0 : 0x3A5F...   # BIOS 측정
    1 : 0xA2B1...   # 플랫폼 설정
    4 : 0xF1E2...   # 부트로더 측정
    7 : 0xC3D4...   # Secure Boot 정책
   10 : 0xE5F6...   # IMA 측정

# PCR 확장(Extend) 원리:
# PCR_new = Hash(PCR_old || measurement)
# → 한번 확장되면 이전 값으로 되돌릴 수 없음 (단방향)
# → 부팅 체인의 모든 측정이 누적된 해시로 표현됨

TCG 이벤트 로그

# 이벤트 로그 확인 (개별 측정 이벤트)
$ tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements
---
- EventNum: 0
  PCRIndex: 0
  EventType: EV_S_CRTM_VERSION
  DigestCount: 1
  Digests:
  - AlgorithmId: sha256
    Digest: "3a5f..."
  Event: ...

- EventNum: 15
  PCRIndex: 7
  EventType: EV_EFI_VARIABLE_DRIVER_CONFIG
  Digests:
  - AlgorithmId: sha256
    Digest: "c3d4..."
  Event:
    UnicodeName: SecureBoot
    VariableData: 01    # Secure Boot 활성

# 커널에서 이벤트 로그 접근
$ ls /sys/kernel/security/tpm0/
binary_bios_measurements   # 바이너리 형식
ascii_bios_measurements    # 텍스트 형식

원격 증명 (Remote Attestation)

/*
 * 원격 증명 흐름:
 *
 * 1. 검증 서버(Verifier)가 난스(nonce)를 전송
 * 2. 클라이언트가 TPM에 Quote 요청:
 *    - TPM이 PCR 값들에 AIK(Attestation Identity Key)로 서명
 *    - 난스를 포함하여 재전송 공격 방지
 * 3. Quote + 이벤트 로그를 검증 서버에 전송
 * 4. 검증 서버가:
 *    a. AIK 서명 검증
 *    b. 이벤트 로그를 재연하여 PCR 값 재계산
 *    c. 재계산된 PCR과 Quote의 PCR 비교
 *    d. 개별 이벤트를 알려진 양호값(golden values)과 비교
 */

# TPM Quote 생성
$ tpm2_createak -C 0x81010001 -c ak.ctx -G rsa -g sha256
$ tpm2_quote -c ak.ctx -l sha256:0,1,4,7,10 \
    -q "nonce_from_verifier" -m quote.msg -s quote.sig

# IMA 측정 목록 (원격 증명에 사용)
$ head -5 /sys/kernel/security/ima/ascii_runtime_measurements
10 a1b2c3... ima-ng sha256:d4e5f6... /sbin/init
10 b2c3d4... ima-ng sha256:e5f6a7... /usr/lib64/ld-linux-x86-64.so.2
10 c3d4e5... ima-ng sha256:f6a7b8... /usr/lib64/libc.so.6

TPM2와 LUKS2 봉인 실무

실제 운영에서는 TPM 봉인을 두 가지 방식으로 나눠 생각해야 합니다. 하나는 현재 PCR 값에 직접 묶는 방식(--tpm2-pcrs=)이고, 다른 하나는 서명된 PCR 정책에 묶는 방식(--tpm2-public-key-pcrs=)입니다. systemd 문서는 후자가 소프트웨어 업데이트와 훨씬 잘 맞는다고 설명합니다.

# 1. 예상 PCR 11 값 서명 JSON 생성
$ systemd-measure sign \
    --linux=/usr/lib/modules/$(uname -r)/vmlinuz \
    --initrd=/boot/initramfs-$(uname -r).img \
    --cmdline="root=UUID=... rw quiet" \
    --private-key=/etc/systemd/tpm2-pcr-private-key.pem \
    --public-key=/etc/systemd/tpm2-pcr-public-key.pem \
    > /etc/systemd/tpm2-pcr-signature.json

# 2. LUKS2 슬롯에 서명된 PCR 정책 등록
$ systemd-cryptenroll --tpm2-device=auto \
    --tpm2-public-key=/etc/systemd/tpm2-pcr-public-key.pem \
    --tpm2-public-key-pcrs=11 \
    --tpm2-signature=/etc/systemd/tpm2-pcr-signature.json \
    --tpm2-pcrs="" \
    /dev/nvme0n1p3

# 해시 트리 생성
$ veritysetup format /dev/sda2 /dev/sda3
VERITY header information for /dev/sda3
UUID:            a1b2c3d4-...
Hash type:       1
Data blocks:     262144
Data block size: 4096
Hash block size: 4096
Hash algorithm:  sha256
Salt:            abc123...
Root hash:       5f8c3d2a1b4e7f9c0d6a3b8e5f2c1d4a7b0e3f6c9d2a5b8e1f4c7d0a3b6e9f

# verity 장치 활성화
$ veritysetup open /dev/sda2 verified-root /dev/sda3 \
    5f8c3d2a1b4e7f9c0d6a3b8e5f2c1d4a7b0e3f6c9d2a5b8e1f4c7d0a3b6e9f

# 마운트
$ mount /dev/mapper/verified-root /mnt -o ro

# 커널 커맨드라인에서 root dm-verity 설정
# root=/dev/dm-0
# dm-mod.create="verified-root,,,ro,0 262144 verity 1 /dev/sda2 /dev/sda3 4096 4096 262144 1 sha256 ROOT_HASH SALT"

# 커널 설정
CONFIG_DM_VERITY=y
CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG=y  # 루트 해시 서명 검증
CONFIG_DM_VERITY_FEC=y                  # Forward Error Correction

# 파일을 read-only로 만든 뒤 fs-verity 활성화
$ chmod 0444 /usr/libexec/myhelper
$ fsverity enable /usr/libexec/myhelper

# 파일 digest 확인 (상수 시간)
$ fsverity digest /usr/libexec/myhelper

# 커널 설정
CONFIG_FS_VERITY=y
CONFIG_FS_VERITY_BUILTIN_SIGNATURES=y  # 선택: in-kernel builtin signature

# 커널 설정
CONFIG_SECURITY_LOADPIN=y

# 일반적인 부트 파라미터
loadpin.enforce=1

# 모듈과 kexec는 자체 서명 검증을 쓰고, 나머지만 LoadPin으로 묶는 예
loadpin.exclude=kernel-module,kexec-image

# dm-verity로 서명 검증된 루트와 initramfs만 허용하는 IPE 정책 예
policy_name=Secure_Appliance policy_version=1.0.0
DEFAULT action=DENY

op=EXECUTE boot_verified=TRUE action=ALLOW
op=EXECUTE dmverity_signature=TRUE action=ALLOW
op=EXECUTE fsverity_signature=TRUE action=ALLOW

# 서명된 kexec (Secure Boot 환경에서 허용)
$ kexec -l /boot/vmlinuz-signed --initrd=/boot/initrd.img \
    --command-line="root=/dev/sda1" --kexec-file-syscall

# kexec_file_load() 시스템 콜에서의 서명 검증:
# 1. PE 헤더 파싱 (bzImage는 PE/COFF 형식)
# 2. Authenticode 서명 추출
# 3. 시스템 키링(.builtin_trusted_keys, .platform_keyring)으로 검증
# 4. IMA 정책에 의한 추가 검증 (func=KEXEC_KERNEL_CHECK)

/* arch/x86/kernel/kexec-bzimage64.c - 서명 검증 흐름 */
static int bzImage64_verify_sig(const char *kernel, unsigned long kernel_len)
{
    return verify_pefile_signature(
        kernel, kernel_len,
        VERIFY_USE_SECONDARY_KEYRING,  /* 보조 키링 검색 */
        VERIFYING_KEXEC_PE_SIGNATURE); /* 용도 표시 */
}

/* 관련 커널 설정 */
CONFIG_KEXEC_FILE=y               # kexec_file_load() 시스템 콜
CONFIG_KEXEC_SIG=y                # kexec 서명 검증 활성화
CONFIG_KEXEC_SIG_FORCE=y          # 서명 없으면 kexec 거부
CONFIG_KEXEC_BZIMAGE_VERIFY_SIG=y # bzImage 서명 검증

# 1. 키 생성 (RSA 2048 또는 4096)
# PK (Platform Key)
$ openssl req -new -x509 -newkey rsa:4096 -keyout PK.key \
    -out PK.crt -nodes -days 3650 \
    -subj "/CN=My Platform Key"

# KEK (Key Exchange Key)
$ openssl req -new -x509 -newkey rsa:4096 -keyout KEK.key \
    -out KEK.crt -nodes -days 3650 \
    -subj "/CN=My Key Exchange Key"

# db (Signature Database Key)
$ openssl req -new -x509 -newkey rsa:4096 -keyout db.key \
    -out db.crt -nodes -days 3650 \
    -subj "/CN=My Signature Database Key"

# 2. EFI Signature List (ESL) 형식으로 변환
$ cert-to-efi-sig-list PK.crt PK.esl
$ cert-to-efi-sig-list KEK.crt KEK.esl
$ cert-to-efi-sig-list db.crt db.esl

# 3. 인증된 업데이트 파일 생성 (EFI_VARIABLE_AUTHENTICATION_2)
$ sign-efi-sig-list -k PK.key -c PK.crt PK PK.esl PK.auth
$ sign-efi-sig-list -k PK.key -c PK.crt KEK KEK.esl KEK.auth
$ sign-efi-sig-list -k KEK.key -c KEK.crt db db.esl db.auth

# 4. UEFI Setup Mode에서 키 등록
# (Setup Mode: PK가 없는 상태 → 누구나 변수 수정 가능)
$ efi-updatevar -f db.auth db        # db 먼저
$ efi-updatevar -f KEK.auth KEK      # KEK 다음
$ efi-updatevar -f PK.auth PK        # PK 마지막 (Setup Mode 종료)

# 5. 커널/부트로더를 자체 키로 서명
$ sbsign --key db.key --cert db.crt \
    --output vmlinuz.signed vmlinuz
$ sbsign --key db.key --cert db.crt \
    --output grubx64.efi.signed grubx64.efi

# db 키 교체 시나리오:
# 1. 새 db 키 생성
$ openssl req -new -x509 -newkey rsa:4096 -keyout db-new.key \
    -out db-new.crt -nodes -days 3650 \
    -subj "/CN=My New DB Key 2026"

# 2. 새 키를 db에 추가 (기존 키 유지, append 모드)
$ cert-to-efi-sig-list db-new.crt db-new.esl
$ sign-efi-sig-list -a -k KEK.key -c KEK.crt db db-new.esl db-append.auth
$ efi-updatevar -a -f db-append.auth db

# 3. 새 키로 커널/부트로더 재서명
$ sbsign --key db-new.key --cert db-new.crt --output vmlinuz.signed vmlinuz

# 4. 검증 후 구 키 제거 (선택)
# → 새 db를 만들어 덮어씀 (구 키 미포함)

# PK 교체:
# 현재 PK로 새 PK를 서명하여 업데이트
$ sign-efi-sig-list -k PK-old.key -c PK-old.crt PK PK-new.esl PK-new.auth
$ efi-updatevar -f PK-new.auth PK

/* security/integrity/platform_certs/load_uefi.c
 *
 * Secure Boot db에서 인증서를 로드하여 .platform_keyring에 추가
 * 커널 초기화 시 자동으로 호출됨
 */
static int __init load_uefi_certs(void)
{
    efi_guid_t secure_var = EFI_IMAGE_SECURITY_DATABASE_GUID;
    efi_guid_t mok_var = EFI_SHIM_LOCK_GUID;
    void *db = NULL, *dbx = NULL, *mok = NULL;
    unsigned long dbsize, dbxsize, moksize;

    /* UEFI db 변수에서 인증서 로드 → .platform_keyring */
    db = get_cert_list(L"db", &secure_var, &dbsize);
    if (db) {
        add_to_platform_keyring("UEFI:db", db, dbsize);
        kfree(db);
    }

    /* UEFI dbx 변수에서 폐기 목록 로드 → .blacklist_keyring */
    dbx = get_cert_list(L"dbx", &secure_var, &dbxsize);
    if (dbx) {
        add_to_blacklist_keyring("UEFI:dbx", dbx, dbxsize);
        kfree(dbx);
    }

    /* Shim MOK 변수에서 인증서 로드 → .platform_keyring */
    mok = get_cert_list(L"MokListRT", &mok_var, &moksize);
    if (mok) {
        add_to_platform_keyring("UEFI:MokListRT", mok, moksize);
        kfree(mok);
    }

    return 0;
}
late_initcall(load_uefi_certs);

/*
 * Linux 커널 키링 계층 (아래 SVG 참고)
 */

# 키링 내용 확인
$ keyctl show %:.builtin_trusted_keys
Keyring
 123456 ---lswrv 0 0 asymmetric: Build time autogenerated kernel key: ab:cd:...

$ keyctl show %:.platform_keyring
Keyring
 234567 ---lswrv 0 0 asymmetric: Microsoft UEFI CA 2011: ...
 345678 ---lswrv 0 0 asymmetric: Windows UEFI CA 2023: ...
 456780 ---lswrv 0 0 asymmetric: Canonical Ltd. Secure Boot Signing: ...

$ keyctl show %:.blacklist_keyring
Keyring
 567890 ---lswrv 0 0 blacklist: tbs:abc123...

# 1. OVMF 변수 저장소는 복사본 사용
$ cp /usr/share/OVMF/OVMF_VARS.fd ./OVMF_VARS.secboot.fd

# 2. swtpm 시작 (QEMU 공식 문서 예시)
$ mkdir -p /tmp/mytpm1
$ swtpm socket --tpmstate dir=/tmp/mytpm1 \
    --ctrl type=unixio,path=/tmp/mytpm1/swtpm-sock \
    --tpm2 \
    --log level=20 &

# 3. QEMU 시작 (x86_64 + Q35 + TPM TIS)
$ qemu-system-x86_64 \
    -machine q35,accel=kvm \
    -cpu host \
    -m 4096 \
    -drive if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE.secboot.fd \
    -drive if=pflash,format=raw,file=./OVMF_VARS.secboot.fd \
    -chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock \
    -tpmdev emulator,id=tpm0,chardev=chrtpm \
    -device tpm-tis,tpmdev=tpm0 \
    -drive file=secureboot-lab.qcow2,format=qcow2,if=virtio \
    -serial mon:stdio

# 게스트 내부에서 Secure Boot / TPM / PCR 확인
$ mokutil --sb-state
$ bootctl status
$ efi-readvar -v PK
$ tpm2_pcrread sha256:7,11
$ dmesg | grep -iE "efi|secure|tpm|lockdown"

# Setup Mode 시험 시
$ od -An -tx1 /sys/firmware/efi/efivars/SetupMode-*

# auto-enroll 후 다시 부팅하여 User Mode 전환 확인
$ od -An -tx1 /sys/firmware/efi/efivars/SecureBoot-*
$ od -An -tx1 /sys/firmware/efi/efivars/VendorKeys-*

# ============ Secure Boot 상태 확인 ============
# Secure Boot 활성 여부
$ mokutil --sb-state
SecureBoot enabled

# UEFI 변수 직접 확인
$ od -An -tx1 /sys/firmware/efi/efivars/SecureBoot-*
06 00 00 00 01
#              ^^ 01 = enabled, 00 = disabled

# Setup Mode 확인
$ od -An -tx1 /sys/firmware/efi/efivars/SetupMode-*
06 00 00 00 00
#              ^^ 00 = User Mode, 01 = Setup Mode

# Audit / Deployed / VendorKeys
$ for v in AuditMode DeployedMode VendorKeys; do od -An -tx1 /sys/firmware/efi/efivars/${v}-*; done

# ============ 키/인증서 확인 ============
# UEFI 보안 변수 목록
$ efi-readvar
Variable PK, length 862
PK: List 0, type X509
    Signature 0, size 834, owner ...
        Subject: CN=...
Variable KEK, length 1532
...

# 등록된 MOK 확인
$ mokutil --list-enrolled

# SBAT 폐기 목록
$ mokutil --list-sbat-revocations

# ============ 커널 키링 ============
$ keyctl show %:.builtin_trusted_keys
$ keyctl show %:.secondary_trusted_keys
$ keyctl show %:.platform_keyring
$ keyctl show %:.blacklist_keyring

# ============ 부팅 로그 ============
$ dmesg | grep -iE "secure.boot|lockdown|integrity|efi.*cert|ima|evm"
secureboot: Secure boot enabled
Lockdown: Kernel is locked down from EFI Secure Boot mode
integrity: Platform Keyring initialized
integrity: Loading X.509 certificate: UEFI:db
ima: policy update completed

# ============ 모듈 서명 ============
# 특정 모듈의 서명 정보
$ modinfo -F signer 
$ modinfo -F sig_hashalgo 

# 서명 없는 모듈 찾기
$ for mod in $(find /lib/modules/$(uname -r) -name "*.ko"); do
    if ! modinfo -F signer $mod &>/dev/null; then
        echo "Unsigned: $mod"
    fi
done

# ===== Secure Boot 관련 커널 설정 종합 =====

# -- 기본 EFI 지원 --
CONFIG_EFI=y
CONFIG_EFI_STUB=y
CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE=y

# -- Lockdown LSM --
CONFIG_SECURITY_LOCKDOWN_LSM=y
CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y
CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT=y

# -- 모듈 서명 --
CONFIG_MODULE_SIG=y
CONFIG_MODULE_SIG_FORCE=y
CONFIG_MODULE_SIG_ALL=y
CONFIG_MODULE_SIG_SHA256=y
CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"

# -- 키링/인증서 --
CONFIG_SYSTEM_TRUSTED_KEYRING=y
CONFIG_SYSTEM_TRUSTED_KEYS="certs/signing_key.pem"
CONFIG_SECONDARY_TRUSTED_KEYRING=y
CONFIG_INTEGRITY_PLATFORM_KEYRING=y

# -- 비대칭키/서명 검증 --
CONFIG_ASYMMETRIC_KEY_TYPE=y
CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y
CONFIG_X509_CERTIFICATE_PARSER=y
CONFIG_PKCS7_MESSAGE_PARSER=y
CONFIG_PKCS7_TEST_KEY=y
CONFIG_SIGNED_PE_FILE_VERIFICATION=y

# -- kexec 서명 --
CONFIG_KEXEC_FILE=y
CONFIG_KEXEC_SIG=y
CONFIG_KEXEC_SIG_FORCE=y
CONFIG_KEXEC_BZIMAGE_VERIFY_SIG=y

# -- IMA/EVM --
CONFIG_INTEGRITY=y
CONFIG_INTEGRITY_SIGNATURE=y
CONFIG_IMA=y
CONFIG_IMA_MEASURE_PCR_IDX=10
CONFIG_IMA_APPRAISE=y
CONFIG_IMA_APPRAISE_MODSIG=y
CONFIG_EVM=y

# -- dm-verity --
CONFIG_DM_VERITY=y
CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG=y
CONFIG_DM_VERITY_FEC=y

# -- fs-verity / LoadPin / IPE --
CONFIG_FS_VERITY=y
CONFIG_FS_VERITY_BUILTIN_SIGNATURES=y
CONFIG_SECURITY_LOADPIN=y
CONFIG_SECURITY_IPE=y

# -- TPM --
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS=y
CONFIG_TCG_CRB=y

# Secure Boot 상태
mokutil --sb-state
bootctl status | grep -i secure

# MOK 등록 키 확인
mokutil --list-enrolled

# 커널 lockdown 상태
cat /sys/kernel/security/lockdown

# 모듈 서명 정보 확인
modinfo -F signer mymodule.ko
dmesg | grep -Ei "secure|lockdown|module verification"