SoC BootROM·eFuse·OTP — 부팅의 0단계 분석

#한 줄 요약

“BootROM과 eFuse는 수정도 회수도 안 되는 0단계입니다.” — mask ROM에 굳어진 코드가 첫 명령을 실행하고, eFuse에 한 번 박힌 비트가 그 코드의 동작 정책을 영원히 정합니다. 이 단계에서 잘못 굳히면 SoC 한 개가 벽돌이 됩니다.

#왜 0단계가 따로 있어야 하는가

Ch 1: 부트로더가 푸는 문제에서 BootROM의 자리를 언급했습니다. 시리즈의 다른 챕터들이 우리가 짜는 코드를 다룬다면, 이 챕터는 우리가 절대 못 건드리는 코드와 한 번만 쓸 수 있는 비트를 다룹니다.

전원 인가 직후의 CPU는 어떤 코드를 실행할지 모릅니다. RAM도 없고, eMMC도 깨어나지 않았고, SPI flash조차 클럭이 안 잡혀 있습니다. 이 상태에서 어딘가의 명령을 가져와 실행해야 합니다. SoC 설계자는 이 최초의 한 줌의 코드를 die 안에 물리적으로 새겨 출하합니다. 이게 BootROM입니다.

BootROM이 어떻게 동작할지는 출하 시점에 정해집니다. 하지만 몇 가지 정책만은 보드 제조사가 결정해야 합니다. SD에서 부팅할지 eMMC에서 부팅할지, secure boot을 켤지 끌지, 어느 키로 서명된 펌웨어만 허용할지. 이 정책을 보드 제조사가 한 번 굳히는 자리가 eFuse·OTP입니다.

이 0단계의 두 요소는 영구성이 핵심입니다. BootROM은 die에 박힌 채 회로가 죽을 때까지 그대로 있고, eFuse는 한 비트라도 0→1로 바꾼 순간 되돌릴 수 없습니다.

#BootROM의 동작 순서

전원 인가부터 BootROM이 SPL로 점프하기까지의 순서를 i.MX 8M 계열 기준으로 풀어 보면 다음과 같습니다.

1
[POR 신호 LOW → HIGH]
2
   │
3
   ▼
4
[PMIC voltage rail 안정 — 수십 ms]
5
   - VDD_CORE, VDD_SOC, VDD_DRAM 순서대로 상승
6
   - 각 rail이 target voltage 도달 신호 대기
7
   │
8
   ▼
9
[reference clock PLL lock]
10
   - 24 MHz xtal 기반 PLL 안정화 (수 ms)
11
   │
12
   ▼
13
[CPU reset deassert]
14
   - cortex-a53 #0 만 unhalt, 나머지는 WFE
15
   - PC = 0x00910000 (i.MX 8M ROM base)
16
   │
17
   ▼
18
[BootROM 실행 시작 — mask ROM 안의 코드]
19
   - SP를 OCRAM(0x00900000)에 설정
20
   - eFuse OCOTP bank를 읽어 정책 결정
21
   - boot mode strap (BOOT_MODE[3:0]) 샘플링
22
   │
23
   ▼
24
[boot device 결정]
25
   - SD/eMMC/QSPI/USB OTG 중 하나
26
   - boot container header (4 KB)를 OCRAM에 적재
27
   - 헤더에서 SPL 오프셋·크기·서명 위치 파싱
28
   │
29
   ▼
30
[secure boot check — HAB enabled bit가 켜진 경우]
31
   - eFuse SRK_HASH와 container 안 SRK table 해시 비교
32
   - container 안 CSF(Command Sequence File) 서명 검증
33
   - 실패 시 USB 복구 모드로 전환 (Serial Downloader)
34
   │
35
   ▼
36
[SPL 적재 + 점프]
37
   - SPL을 OCRAM(0x00910000~) 또는 TCM에 적재
38
   - PC = SPL entry point, 인계 완료

이 시점에서 우리가 짠 코드(SPL)가 처음 한 줄을 실행합니다. 그 전까지 모든 일은 우리가 못 건드리는 영역입니다.

흔히 오해하는 지점이 있습니다. BootROM은 bootloader가 아닙니다. BootROM은 다음 단계를 어디서 얼마나 적재할지 정하고, 점프만 합니다. DDR 초기화, 환경 변수 처리, 커널 적재 같은 일은 모두 SPL 이후의 책임입니다.

#boot mode 결정 — strap pin과 fuse

BootROM이 “어디서 부팅할지” 정하는 입력은 두 군데입니다.

개발 단계에서는 strap pin이 우선입니다. SD 카드에 SPL을 굽고, DIP switch를 SD 위치에 두면 BootROM이 SD를 읽습니다. eMMC를 끼우면 strap만 바꿔 eMMC 부팅으로 전환합니다.

양산 단계에서는 부팅 매체를 fuse로 고정합니다. 그래야 strap pin이 흔들리거나 누가 wire를 잘못 박아도 부팅이 동일하게 진행됩니다.

1
# i.MX 8M Plus — eMMC 부팅으로 lock하는 fuse 시퀀스 (U-Boot 안)
2
=> fuse prog -y 1 3 0x00002000      # BOOT_CFG[13] = 1 (eMMC select)
3
=> fuse prog -y 1 3 0x02000000      # BT_FUSE_SEL = 1 (strap 무시, fuse만 사용)
4
=> reset

fuse prog는 U-Boot의 명령으로, 내부적으로 OCOTP controller의 BLOW 시퀀스를 트리거합니다. 한 번 성공하면 되돌릴 방법이 없습니다. 양산 라인에서 이 명령을 자동으로 굽는 jig는 반드시 dry-run + verify 절차를 끼워야 합니다.

대표 SoC들의 boot mode 입력은 다음 표처럼 다릅니다.

Rockchip은 strap pin이 없는 대신 BootROM이 후보 매체를 순회합니다. SD가 꽂혀 있으면 SD, 없으면 eMMC, 없으면 SPI, 없으면 USB MaskROM 모드. 개발 편의성은 좋지만, 양산에서 원치 않는 SD가 꽂혀 있으면 그쪽으로 부팅하는 사고가 납니다.

#eFuse · OTP — 한 번 굳히면 끝

eFuse는 전기적으로 한 번만 0에서 1로 바꿀 수 있는 메모리입니다. 물리적으로는 polysilicon fuse 또는 anti-fuse 구조이고, 큰 전류를 흘려 작은 회로를 끊거나 잇는 방식입니다. 한 번 변형된 구조는 어떤 방법으로도 되돌릴 수 없습니다.

OTP(One-Time Programmable)는 더 일반적인 용어입니다. eFuse는 OTP의 한 구현체입니다. SoC 데이터시트에서는 OTP·eFuse·FCT(Field Configurable Tag) 같은 이름이 섞여 등장하지만, 의미는 같습니다. “한 번 쓰면 끝”.

eFuse가 저장하는 정보는 크게 네 분류입니다.

eFuse Bank Layout — i.MX 8M Plus (단순화):

이 영역을 한 번에 다 보고 싶으면 U-Boot에서 fuse sense로 읽을 수 있습니다.

1
=> fuse sense 6 0 8
2
Sensing bank 6:
3
Word 0x00000000: deadbeef cafebabe 12345678 9abcdef0
4
Word 0x00000004: 11223344 55667788 99aabbcc ddeeff00

각 word는 32 bit 단위로, 위 layout에 따라 256 bit짜리 SRK hash가 8 word에 걸쳐 있습니다.

#SoC별 fuse map 예

실제 칩의 fuse map을 한 번 보면 감이 잡힙니다. NXP i.MX 8M Plus의 OCOTP map을 일부 정리하면 다음 표가 됩니다.

SEC_CONFIG=11이 secure boot의 돌이킬 수 없는 전환점입니다. 이 두 비트가 11이 되면 서명 검증을 통과한 펌웨어만 부팅됩니다. 잘못된 키로 서명된 펌웨어는 BootROM이 거부합니다.

Rockchip RK3568의 OTP는 다른 layout을 가집니다.

TI K3 계열은 SOC_ID와 MPK(Manufacturer Public Key) hash가 e-Fuse에 있고, AM62x는 fuse 외에도 Tamper detection 비트로 enclosure를 열면 키가 자동 erase되는 메커니즘까지 갖춥니다.

#Root of Trust — PK hash를 어떻게 박는가

Secure boot의 출발점은 공개 키 한 개를 SoC에 영구히 박는 일입니다. 정확히는 키가 아니라 키의 SHA-256 해시를 박습니다. 키 자체는 펌웨어 이미지 안에 동봉되고, BootROM이 그 키의 해시가 eFuse의 값과 같은지 확인합니다.

NXP HABv4 기준의 절차는 다음과 같습니다.

1
# 1) PKI tree 생성 (CA + 4개의 SRK + CSF·IMG 서명용 키)
2
$ cd cst/keys
3
$ ./hab4_pki_tree.sh
4
+ Use existing CA key (y/n)?: n
5
+ Use Elliptic Curve Cryptography (y/n)?: n
6
+ Length of the RSA key in bits: 4096
7
+ Duration (years) of the keys: 10
8
+ Number of Super Root Keys (1-4): 4
9
... 생성 완료 ...
10

11
# 2) SRK table과 SRK hash 산출
12
$ ./srktool -h 4 -t SRK_1_2_3_4_table.bin \
13
            -e SRK_1_2_3_4_fuse.bin \
14
            -d sha256 -c \
15
            ../crts/SRK1_sha256_4096_65537_v3_ca_crt.pem,\
16
            ../crts/SRK2_sha256_4096_65537_v3_ca_crt.pem,\
17
            ../crts/SRK3_sha256_4096_65537_v3_ca_crt.pem,\
18
            ../crts/SRK4_sha256_4096_65537_v3_ca_crt.pem
19

20
# 3) SRK_1_2_3_4_fuse.bin (32 byte) 를 OCOTP에 박기
21
$ hexdump -C SRK_1_2_3_4_fuse.bin
22
00000000  9a b3 71 d5 6f 4e ...

이 32 byte SHA-256 값을 U-Boot에서 fuse word 단위로 굽습니다.

1
=> fuse prog -y 6 0 0x9ab371d5
2
=> fuse prog -y 6 1 0x6f4ec3a2
3
=> fuse prog -y 6 2 0x...
4
... 8 word 반복 ...
5
=> fuse sense 6 0 8                 # verify

8 word를 모두 굳히고 fuse sense로 다시 읽어 일치하는지 확인한 뒤에야 secure boot을 켤 수 있습니다. 마지막으로 SEC_CONFIG를 11로 만드는 순간 칩은 Closed 상태로 들어가고, 이 SRK_HASH로 검증되지 않는 펌웨어는 영원히 부팅 못 합니다.

Ch 27: Chain of Trust에서 이 키가 SPL → U-Boot → kernel로 전파되는 연쇄를 다룹니다.

#anti-rollback counter

펌웨어 v2에 보안 취약점을 고친 패치가 들어갔다면, 공격자가 v1으로 되돌리는 시도를 막아야 합니다. 같은 키로 서명됐기 때문에 secure boot은 v1도 유효한 펌웨어로 받아들입니다. 이 공백을 막는 게 anti-rollback counter입니다.

원리는 단순합니다.

부트 시 BootROM(또는 SPL)이 eFuse의 carved bit 개수와 펌웨어 헤더의 최소 요구 버전을 비교합니다. eFuse가 더 높으면 펌웨어 부팅을 거부합니다.

eFuse는 0→1 단방향이라 몇 비트가 굳어졌는지 = 카운터 값으로 사용합니다. monotonic counter라고 부르는 이유가 여기 있습니다.

1
// 의사 코드 — anti-rollback check
2
uint32_t fuse_counter = popcount(otp_read(BANK_SW_GP1));  // 굳은 bit 개수
3
uint32_t fw_min_ver  = image_header.min_version;
4

5
if (fw_min_ver > fuse_counter) {
6
    // 새 펌웨어 — 부팅 후 eFuse를 fw_min_ver까지 굳혀야 함
7
    burn_otp_bits(BANK_SW_GP1, fw_min_ver - fuse_counter);
8
} else if (fw_min_ver < fuse_counter) {
9
    // 구버전 펌웨어 — 거부
10
    panic("anti-rollback violation");
11
}

문제는 비트 개수가 유한하다는 점입니다. SW_GP1이 32 bit짜리 word라면 32번의 patch밖에 못 받습니다. 양산 펌웨어의 security version은 기능 버전과 별개로 아주 가끔만 올리는 정책이 필요합니다. 보통은 심각한 보안 patch에서만 +1.

#JTAG · 디버그 영구 비활성화

양산 단계의 마지막 단계 중 하나는 디버그 인터페이스를 잠그는 일입니다. 공격자가 JTAG으로 직접 메모리를 읽거나 PC를 바꾸면 secure boot이 무력해집니다.

i.MX 8M에서는 JTAG_DISABLE(1 bit)과 JTAG_SMODE(3 bit)로 정책을 정합니다.

1
# secure JTAG 모드로 전환 (challenge-response)
2
=> fuse prog -y 9 0 0x00000018       # JTAG_SMODE = 011 (secure)
3

4
# 완전 비활성화
5
=> fuse prog -y 9 0 0x00000004       # JTAG_DISABLE = 1

JTAG을 완전 비활성화한 칩은 벽돌이 됐을 때 살릴 방법이 없습니다. 양산 첫 lot에서는 Secure JTAG 정도로 두고, 시장 안정성이 검증된 뒤에 Disabled로 전환하는 단계적 접근이 안전합니다.

#흔한 실수

eFuse는 실수가 가장 치명적인 영역입니다. 양산 라인에서 자주 발생하는 사고를 분류해 두면 다음과 같습니다.

가장 흔한 사고는 SEC_CONFIG를 먼저 굳히는 것입니다. 양산 fuse 시퀀스에서 순서가 결정적입니다. 다음 순서를 dry-run으로 검증해 두는 게 안전합니다.

1
[양산 fuse 순서 — 권장]
2
 1. unique ID·MAC·serial 굳기 (필요 시)
3
 2. SRK_HASH 8 word 굳기 + verify
4
 3. BOOT_CFG·BT_FUSE_SEL 굳기 + verify (boot device lock)
5
 4. JTAG_SMODE = secure (개발 회복 여지 유지)
6
 5. SEC_CONFIG = 11 (Closed 전환) — 마지막
7
 6. ※ 모든 단계마다 fuse sense로 verify

또 한 가지 흔한 실수는 fuse prog의 비트 위치 착오입니다. NXP의 OCOTP는 word 단위, Rockchip OTP는 byte 단위로 주소 체계가 다릅니다. SoC 데이터시트의 fuse map과 fuse 명령의 인자 의미를 교차 검증하지 않은 채 대량 굳히기에 들어가면 lot 전체가 폐기됩니다.

마지막으로 production fuse profile 자체를 잊는 경우입니다. 개발에서 strap pin으로만 동작 검증한 뒤 양산에서 동일한 strap을 가정합니다. 그러나 양산 환경의 strap pull-up 저항 편차로 0.5%의 보드에서 부팅이 실패하는 사고가 보고됩니다. fuse로 lock하면 이 변동을 완전히 차단합니다.

#정리

• BootROM은 SoC die에 물리적으로 새겨진 코드입니다. 출하 후 어떤 방법으로도 수정할 수 없으며, POR → reset vector → boot mode 결정 → SPL 적재 → 점프의 짧은 시퀀스만 수행합니다.
• BootROM의 동작 정책은 strap pin과 eFuse로 결정됩니다. 개발 단계는 strap 우선, 양산 단계는 BT_FUSE_SEL 같은 비트로 fuse가 우선이 되도록 lock합니다.
• eFuse·OTP는 0→1 단방향입니다. 한 비트라도 굳히면 회수 불가능하므로 모든 굳히기 시퀀스는 dry-run + verify를 반복해야 합니다.
• secure boot의 시작은 Root of Trust Public Key의 SHA-256 해시를 SRK_HASH 영역에 굳히는 일이며, NXP HABv4의 경우 8 word 256 bit입니다.
• anti-rollback counter는 굳은 bit 개수 = 버전 번호로 사용하는 monotonic counter입니다. 펌웨어 헤더의 minimum version과 비교해 구버전 부팅을 거부합니다.
• JTAG은 Secure JTAG과 완전 비활성화 두 단계로 잠글 수 있습니다. 양산 초반에는 Secure JTAG, 안정 후 완전 비활성화가 단계적 접근입니다.
• 양산 fuse 순서는 SRK_HASH 먼저, SEC_CONFIG 마지막입니다. 거꾸로 굳히면 칩 한 개가 즉시 벽돌이 됩니다.
• fuse 사고는 되돌릴 수 없고, 양산 line의 jig에는 반드시 verify 단계가 들어가야 합니다.

#다음 장 예고

다음 편은 Ch 24: SPL · TPL 깊이에서 BootROM이 적재해 점프한 다음 단계의 코드를 풉니다. SRAM 안 50 KB에서 동작해야 하는 SPL이 어떻게 DDR을 깨우고 U-Boot Proper를 적재하는지 다룹니다.

#관련 항목

• Ch 1: 부트로더가 푸는 문제 — BootROM의 자리
• Ch 24: SPL · TPL 깊이 — BootROM 다음 단계
• Ch 27: Chain of Trust — SRK_HASH가 부트 체인 전반으로 전파되는 흐름
• Buildroot Ch 18: 보안 기능 — 빌드 시스템 관점의 secure boot
• 원문 — NXP HABv4 Reference Manual (AN4581)
• 원문 — i.MX 8M Plus OCOTP fuse map (RM)