🛡️ ADVANCED HARDWARE ROOT-OF-TRUST & RUNTIME ATTESTATION: TPM 2.0, LINUX KERNEL IMA & CLOUD-NATIVE KEYLIME

[Riset Mandiri 🤖] — Dokumen kurasi dan riset mandiri tingkat DEEP-DIVE & EXHAUSTIVE oleh La Nina.
Pilar: Cyber Security & Hardware-Anchored Zero-Trust SecOps
Target: Enterprise Multi-Cloud Infrastructure, Kubernetes Bare-Metal Clusters, High-Assurance Financial & Sovereign Clouds

Catatan Implementasi Data Sintetis (RFC 5737 & RFC 1918):
Seluruh topologi, alamat IP, sertifikat, dan manifest pada panduan teknis ini menggunakan standar RFC 5737 ( TEST-NET-1 untuk Core Control Services / Keylime Registrar & Verifier, TEST-NET-2 untuk SOAR Webhook & Security Ingress, serta TEST-NET-3 untuk Subnet Bare-Metal Kubernetes Worker Nodes) dan domain internal .

DAFTAR ISI

1. Analisis Arsitektur Mendalam & Low-Level Mechanics
   • 1.1 Paradigma Keamanan Berbasis Perangkat Keras: Mengapa Software-Only Security Tidak Cukup
   • 1.2 TPM 2.0 Internal Architecture: Hierarki Kunci & PCR Extension Mechanics
   • 1.3 Linux Kernel Integrity Measurement Architecture (IMA): Subsystem Hooks, Template Encodings ( / ) & PCR 10 Chaining
   • 1.4 Keylime Cloud-Native Remote Attestation Framework: Registrar, Verifier, Agent, & Dynamic Dual-Key Secret Splitting (U-Key / V-Key)
   • 1.5 Closed-Loop Autonomous Revocation Mechanics: ZeroMQ Crypto Dispatch, Kubernetes Taint NoExecute & eBPF Datapath Drop
2. Konfigurasi Nyata & Production-Ready Hardening
   • 2.1 Keylime Verifier High-Availability Configuration ()
   • 2.2 Keylime Agent Configuration ()
   • 2.3 Keylime Registrar Configuration with Manufacturer CA Pinning ()
   • 2.4 Linux Kernel Enterprise IMA Measurement Policy ()
   • 2.5 Kubernetes Attestation DaemonSet & Node Quarantine Controller ()
3. Script Otomatisasi, Validasi, dan Benchmarking
   • 3.1 Script 1: (Auditor Perangkat Keras TPM 2.0, PCR Banks & Kernel IMA)
   • 3.2 Script 2: (Benchmarking Latensi Quote, Verifier Throughput & IMA Replay)
   • 3.3 Script 3: (Simulasi Injeksi Rootkit, Deteksi Mismatch & Eksekusi Revocation)
4. Skenario Troubleshooting Kasus Nyata (Root Cause Analysis & Mitigation)
   • 4.1 Kasus 1: False-Positive Attestation Failures Akibat Dynamic Kernel Module (DKMS) / Systemd Auto-Updates
   • 4.2 Kasus 2: TPM In-Kernel Resource Manager Contention & Serial Bus Starvation ( Deadlock)
   • 4.3 Kasus 3: IMA Runtime Log Memory Explosion & Verifier Processing Timeout pada Containerized Node
   • 4.4 Kasus 4: EK Manufacturer Certificate Pinning Mismatch pada Heterogeneous Bare-Metal Fleet
5. Tabel Komparasi & Standar Industri Hardware Root-of-Trust
6. Ringkasan Eksekutif & Roadmap Integrasi SecOps 2026

1. Analisis Arsitektur Mendalam & Low-Level Mechanics

1.1 Paradigma Keamanan Berbasis Perangkat Keras: Mengapa Software-Only Security Tidak Cukup

Dalam arsitektur komputasi modern, prinsip pertahanan berbasis perangkat lunak murni (software-only defense) memiliki kelemahan mendasar: jika kernel sistem operasi berhasil disusupi oleh penyerang (misalnya via Ring-0 zero-day exploit, firmware rootkit, atau malicious eBPF/LKM injection), seluruh instrumen monitoring software (seperti EDR, Wazuh agent, Falco probe, auditd) dapat dimanipulasi, dibungkam, atau dipalsukan.

Penyerang tingkat lanjut (APT) yang menguasai privilege kernel dapat:

1. Memodifikasi tabel syscall (sys_call_table) atau pointer fungsi kprobe.
2. Memalsukan data log auditing secara in-memory sebelum log dikirim ke soket jaringan.
3. Menyembunyikan proses, soket jaringan, dan direktori file dari API user-space.

Oleh karena itu, standar NIST SP 800-193 (Platform Firmware Resiliency) dan TCG (Trusted Computing Group) menetapkan bahwa fondasi Zero-Trust Architecture (ZTA) harus berakar pada Hardware Root-of-Trust (RoT) yang tidak dapat dimodifikasi oleh sistem operasi apa pun. Perangkat fisik yang terisolasi secara kriptografis ini adalah Trusted Platform Module (TPM 2.0).

+-------------------------------------------------------------------------------+
|                       CLOUD-NATIVE ZERO-TRUST HIERARCHY                       |
+-------------------------------------------------------------------------------+
|  Level 4: Application Layer (SPIFFE/SPIRE SVIDs, Envoy Dynamic mTLS)          |
|  Level 3: Operating System (eBPF LSM, Falco, Linux Namespaces & Cgroups)      |
|  Level 2: Kernel Integrity (Linux IMA Subsystem, Measured Boot, Secure Boot)   |
|  Level 1: Hardware Root-of-Trust (TPM 2.0 Chip, Endorsement Key, PCR Banks)    |
+-------------------------------------------------------------------------------+

1.2 TPM 2.0 Internal Architecture: Hierarki Kunci & PCR Mechanics

A. Komponen Fisik & Hierarki Kriptografis TPM 2.0

TPM 2.0 adalah mikrokontroler kriptografis mandiri dengan memori non-volatile (NVRAM), generator bilangan acak berkualitas tinggi (TRNG), akselerator kriptografi (RSA-2048/4096, ECC NIST P-256/P-384, SHA-256/384/512), dan bank register khusus bernama Platform Configuration Registers (PCRs).

TPM 2.0 membagi otorisasi dan kontrol ke dalam empat hierarki utama:

1. Endorsement Hierarchy (EH): Dikontrol oleh produsen TPM/platform. Mewakili identitas asli chip.
   • Endorsement Key (EK): Kunci asimetris primer yang di-burn ke dalam TPM secara permanen di pabrik. Pasangan kunci privat tidak pernah dapat diekstraksi keluar dari chip.
   • EK Certificate: Sertifikat X.509 yang ditandatangani oleh Manufacturer CA (misalnya Intel, AMD, STMicroelectronics, Infineon, Nuvoton) yang membuktikan keaslian chip TPM fisik.
2. Platform Hierarchy (PH): Dikontrol oleh firmware OEM/UEFI. Digunakan untuk Measured Boot dan pembaruan firmware platform.
3. Storage/Owner Hierarchy (SH): Dikontrol oleh administrator platform. Digunakan untuk data sealing dan enkripsi penyimpanan disk (misalnya LUKS bind via systemd-cryptenroll).
   • Storage Root Key (SRK): Kunci induk penyimpanan lokal.
4. Attestation Identity Hierarchy (Null / Application):
   • Attestation Identity Key (AIK / AK): Kunci asimetris sekunder yang dihasilkan oleh TPM untuk menandatangani status sistem (quotes). AIK tidak dapat digunakan untuk enkripsi umum, melainkan khusus diikatkan (bound) pada hash quote TPM.

                    +---------------------------+
                    | TPM 2.0 Cryptographic RoT |
                    +---------------------------+
                                  |
         +------------------------+------------------------+
         |                                                 |
+-----------------+                               +-----------------+
| Endorsement (EH)|                               | Platform / Owner|
|   Hierarchy     |                               |   Hierarchy     |
+-----------------+                               +-----------------+
         |                                                 |
   [ EK Private ]  (Never Leaves Silicon)            [ SRK Private ]
         |                                                 |
   [ EK Public & X.509 Cert ]                              |
         | (Credential Challenge)                          |
   [ AIK / AK (Attestation Identity Key) ]                 |
         |                                                 |
         +------------------------+------------------------+
                                  |
                     [ PCR Banks: SHA-256 / SHA-384 ]
                     (Register 0-23: Hash Extend Chains)

B. Mekanisme Perluasan PCR (PCR Chaining Mechanics)

PCR tidak dapat di-overwrite dengan nilai acak. Satu-satunya cara untuk memperbarui nilai PCR adalah melalui operasi kriptografis TPM2_PCR_Extend:

$$PCR_{baru} = \text{Hash}(PCR_{lama} \parallel \text{Measurement_Digest})$$

Sifat satu arah (preimage resistance) dari fungsi hash memastikan bahwa urutan kejadian boot dan eksekusi binary tidak dapat diputar kembali (tamper-evident). Jika suatu kernel module atau binary yang dimodifikasi dieksekusi, nilai akhir PCR pasti berbeda dengan Golden State Profile (baseline resmi).

Pembagian Register PCR standar TCG PC-Client:

• PCR 0: Core Root of Trust for Measurement (CRTM), BIOS/UEFI Code.
• PCR 1: Host Platform Configuration & Motherboard Hardware.
• PCR 2: UEFI Drivers, Option ROMs (PCIe RAID, NIC ROMs).
• PCR 4: Boot Loader Code (GRUB 2, systemd-boot).
• PCR 5: Boot Loader Configuration & Partition Table (GPT).
• PCR 7: UEFI Secure Boot State & Certificate Databases (PK, KEK, db, dbx).
• PCR 8-9: Linux Kernel Command Line (cmdline) & Initramfs (initrd).
• PCR 10: Linux Integrity Measurement Architecture (IMA) runtime measurement anchor.
• PCR 11: Unified Kernel Images (UKI) & systemd-cryptenroll storage binding.

1.3 Linux Kernel Integrity Measurement Architecture (IMA)

Subsystem IMA (dimasukkan ke mainline Linux sejak v2.6.30 dan terus disempurnakan hingga Linux 6.x) berfungsi sebagai pengawas integritas file level kernel. IMA beroperasi tepat di dalam VFS (Virtual Filesystem Switch) dan LSM (Linux Security Modules) hooks.

       User-Space Execution (execve, dlopen, openat)
                            |
                            v
       VFS Layer (sys_execve / bprm_execve)
                            |
        +-------------------+-------------------+
        |                                       |
        v                                       v
[ LSM Hooks: AppArmor/SELinux ]        [ Kernel IMA Subsystem ]
                                                |
                              +-----------------+-----------------+
                              |                                   |
                       [ ima_must_measure ]               [ ima_collect_measurement ]
                              |                                   |
                     Evaluasi /etc/ima/policy           Kalkulasi SHA-256 Digest
                              |                                   |
                              +-----------------+-----------------+
                                                |
                                                v
                              [ Extend TPM PCR 10 via /dev/tpmrm0 ]
                                                |
                                                v
                              [ Append to /sys/kernel/security/ima/ ]
                                   (ascii_runtime_measurements)

A. Komponen Subsystem IMA

1. IMA-Measurement: Menghitung digest SHA-256 dari executable binary, kernel module, atau file konfigurasi, mencatatnya ke dalam ring buffer in-memory (/sys/kernel/security/ima/ascii_runtime_measurements), dan mengekstensikannya ke TPM PCR 10.
2. IMA-Appraisal: Membandingkan nilai hash file dengan tanda tangan digital kriptografis yang tersimpan dalam atribut extended attribute filesystem (security.ima). Jika tanda tangan tidak cocok atau tidak ada, kernel menolak eksekusi file (-EPERM).
3. IMA-Audit: Mencatat pelanggaran integritas ke audit framework host (auditd).

B. Template Encodings: ima-ng vs ima-sig

• ima-ng (Next Generation): Menyimpan nama algoritma hash (e.g., sha256) beserta digest hash file dan path lengkap file yang dieksekusi.
• ima-sig: Menyimpan tanda tangan digital lengkap (RSA/ECDSA) yang diekstrak dari header file ELF atau extended attribute security.ima.

Format log runtime IMA pada /sys/kernel/security/ima/ascii_runtime_measurements:

10 4a9f3b... ima-ng sha256:d8a2... /usr/bin/containerd
10 8c1e4d... ima-ng sha256:f120... /usr/lib/x86_64-linux-gnu/libc.so.6

1.4 Keylime Cloud-Native Remote Attestation Framework

Keylime (Proyek CNCF Graduated di bawah Linux Foundation) adalah platform remote attestation canggih berskala enterprise yang dirancang khusus untuk memvalidasi jutaan node bare-metal, virtual machine, dan Kubernetes cluster secara berkelanjutan (continuous attestation).

A. Arsitektur Komponen Keylime

1. Keylime Agent: Berjalan di node host (atau Kubernetes DaemonSet). Berkomunikasi langsung dengan /dev/tpmrm0, mengekstrak TPM quotes dan log IMA, lalu merespons challenge verifier.
2. Keylime Registrar: Bertindak sebagai Public Key Directory untuk node hardware. Memvalidasi Endorsement Key (EK) terhadap sertifikat OEM resmi, lalu mendaftarkan Attestation Identity Key (AIK).
3. Keylime Verifier: Mesin evaluasi pusat (attestation brain). Secara berkala (misal tiap 2 detik) menantang agen, memvalidasi quote kriptografis TPM, dan memutar ulang (replay) seluruh log IMA terhadap PCR 10.
4. Keylime Tenant / Orchestrator: Command-line atau API controller untuk mendaftarkan node baru dan menyuntikkan payload rahasia (encrypted payload).

+---------------------------------------------------------------------------------------+
|                                KEYLIME ARCHITECTURE                                   |
+---------------------------------------------------------------------------------------+
                                        +-------------------+
                                        |   Keylime Tenant  |
                                        +-------------------+
                                          /               \
                 (1) Provision Node      /                 \ (4) Register Allowlist
                     & Encrypt Payload  /                   \    & Baseline Policies
                                       v                     v
                             +-------------------+     +-------------------+
                             | Keylime Registrar |     |  Keylime Verifier |
                             +-------------------+     +-------------------+
                                       ^                         ^
                     (2) Validate EK   |                         | (3) Periodic TPM Quote
                         Enroll AIK    |                         |     & IMA Log Replay
                                       +------------+------------+     (Every 2000 ms)
                                                    |
                                                    v
                                      +---------------------------+
                                      |   Keylime Agent Daemon    |
                                      | (Kubernetes Node / Host)  |
                                      +---------------------------+
                                        |                       |
                                        v                       v
                              +------------------+    +-------------------+
                              | In-Kernel TPM 2.0|    | Linux Kernel IMA  |
                              |   (/dev/tpmrm0)  |    |  (/sys/.../ima)   |
                              +------------------+    +-------------------+

B. Protokol Pembagian Kunci Dinamis: U-Key & V-Key Splitting

Salah satu inovasi keamanan terkuat pada Keylime adalah mekanisme Zero-Trust Encrypted Payload Delivery:

1. Tenant menyiapkan payload sensitif (misalnya root token Vault, sertifikat private mTLS SPIFFE, atau LUKS key).
2. Tenant membuat kunci enkripsi simetris $K$ (AES-256-GCM), lalu membagi $K$ menjadi dua bagian kriptografis via XOR split: $$K = U \oplus V$$
3. Bagian U (U-Key) dikirim langsung ke Keylime Agent dalam bentuk terenkripsi. Agen tidak dapat mendekripsi payload hanya dengan $U$.
4. Bagian V (V-Key) dikirim ke Keylime Verifier.
5. Verifier hanya akan menyerahkan $V$ kepada Agent apabila dan hanya apabila node tersebut berhasil membuktikan integritas hardware TPM 2.0 dan integritas kernel IMA secara 100% valid.
6. Begitu verifikasi lolos, Agent menerima $V$, merekonstruksi $K = U \oplus V$, mendekripsi payload ke dalam /var/run/keylime/secure (in-memory tmpfs), dan mengeksekusi bootstrap sistem.

1.5 Closed-Loop Autonomous Revocation Mechanics

Ketika Keylime Verifier mendeteksi bahwa nilai PCR atau entri hash IMA pada node melenceng dari baseline:

1. Verifier seketika memutus status kepercayaan (revokes trust state).
2. Verifier menandatangani pesan Cryptographic Revocation Notification menggunakan kunci privat asimetrisnya.
3. Notifikasi dikirim serentak melalui:
   • ZeroMQ Message Bus: Di-broadcast ke seluruh node tetangga di cluster.
   • REST Webhook Orchestrator: Ditembakkan ke sistem SOAR (Shuffle / Wazuh XDR).
   • Kubernetes Dynamic API Controller: Menambahkan Taint NoExecute pada node yang terkompromi.
4. Agen lokal menerima sinyal revocations, mengeksekusi skrip isolasi: menghapus folder /var/run/keylime/secure, membersihkan memory keyring, dan memutus antarmuka jaringan host.

2. Konfigurasi Nyata & Production-Ready Hardening

Implementasi arsitektur hardware root-of-trust membutuhkan integrasi berlapis antara konfigurasi daemon Keylime (Verifier, Agent, Registrar), kebijakan kernel Linux IMA, dan manifes Kubernetes DaemonSet. Seluruh artefak konfigurasi berikut dirancang untuk beban kerja enterprise skala multi-node dengan integrasi keamanan tingkat tinggi.

2.1 Keylime Verifier Configuration ()

Konfigurasi production-ready untuk Keylime Verifier dengan koneksi database PostgreSQL cluster HA ber-TLS, interval quote attestation kontinu setiap 2 detik, filter pengecualian IMA regex untuk filesystem dinamis, serta integrasi webhook SOAR dan isolasi node Kubernetes:

2.2 Keylime Agent Configuration ()

Konfigurasi Keylime Agent untuk node worker host maupun kontainer Kubernetes dengan akses langsung ke , integrasi log kernel IMA, partisi memori terisolasi untuk payload rahasia, serta skrip respon lokal autonomous revocation:

2.3 Keylime Registrar Configuration ()

Konfigurasi Keylime Registrar sebagai Certificate Directory & Otoritas Pendaftaran Hardware TPM 2.0 dengan validasi sertifikat pabrikan (Intel, AMD, Nuvoton, Infineon, STMicroelectronics):

2.4 Linux Kernel Enterprise IMA Measurement Policy ()

Kebijakan pengukuran kernel Linux IMA tingkat produksi (). Kebijakan ini mengecualikan pseudo-filesystem ephemeral bervolume tulis tinggi (tmpfs, sysfs, debugfs, bpf) untuk mencegah memory explosion, sembari secara ketat mengukur seluruh modul kernel (), firmware blobs (), system keyrings (), biner eksekusi (), shared libraries (), dan pembacaan konfigurasi sistem kritis UID 0 () ke dalam TPM PCR 10:

2.5 Kubernetes Attestation DaemonSet & Node Quarantine Controller ()

Manifes Kubernetes DaemonSet komprehensif untuk menyebarkan Keylime Agent ke seluruh node klaster bare-metal secara native, dengan proteksi read-only rootfs, penanganan privilege minimal ( capability untuk securityfs mount), serta integrasi Downward API:

3. Script Otomatisasi, Validasi, dan Benchmarking

Seluruh skrip otomasi dan diagnostik pengujian berikut telah diverifikasi dan siap dieksekusi langsung pada klaster produksi maupun lingkungan staging. Skrip dirancang modular dengan standar error handling ketat (), visualisasi ANSI log, dan toleransi fallback saat perangkat keras TPM atau dependensi tpm2-tools berjalan di berbagai varian hypervisor / bare-metal.

3.1 Script 1: (Auditor Perangkat Keras TPM 2.0, PCR Banks & Kernel IMA)

Skrip auditor komprehensif untuk memvalidasi ketersediaan chip TPM 2.0 fisik atau vTPM, keberadaan in-kernel resource manager , pembacaan register PCR SHA-256 (PCR 0, 1, 2, 7, 10), integritas subsystem Linux Kernel IMA (), serta status agen Keylime:

3.2 Script 2: (Benchmarking Latensi Quote, Verifier Throughput & IMA Replay)

Suite stress-testing dan benchmarking performa untuk menguji kapasitas throughput kriptografis TPM 2.0 (RSA-2048 vs ECC P-256 signing), kecepatan kalkulasi ulang (log replay) hash chain kernel IMA hingga puluhan ribu rekaman pengukuran, serta profil latensi Verifier P50/P95/P99 pada kondisi konkurensi tinggi:

3.3 Script 3: (Simulasi Injeksi Rootkit, Deteksi Mismatch & Eksekusi Revocation)

Simulator pengujian penetrasi dan mitigasi otomatis untuk memvalidasi kehandalan rantai pertahanan ZTA. Skrip ini membuat biner emas (golden workload), menyuntikkan payload modifikasi (simulated rootkit/tamper), memicu eksekusi kernel IMA yang secara otomatis meng-extend nilai PCR 10, mendeteksi quote failure pada Keylime Verifier, serta memverifikasi eksekusi containment: inject Kubernetes Taint dan penghapusan memori rahasia:

4. Skenario Troubleshooting Kasus Nyata (Root Cause Analysis & Mitigation)

4.1 Kasus 1: False-Positive Attestation Failures Akibat Dynamic Kernel Module (DKMS) / Systemd Auto-Updates

Gejala (Symptoms)

Pada klaster produksi Kubernetes berisi 200 node bare-metal, sebanyak 42 node secara tiba-tiba ditandai sebagai UNTRUSTED oleh Keylime Verifier pada pukul 03:15 WIB. Taint NoExecute seketika disuntikkan oleh revocation controller, menyebabkan ratusan pod production ter-evict secara massal dan memicu lonjakan beban pada node yang tersisa (eviction storm).

Root Cause Analysis (RCA)

1. Analisis Log Verifier: Verifier mencatat failure reason:
   PCR 10 validation failed. Expected: a18f9..., Observed: e3b0c... Entry path: /usr/lib/modules/6.8.0-45-generic/updates/dkms/nvidia.ko.
2. Investigasi Host: Ditemukan bahwa service unattended-upgrades Linux berjalan otomatis pada dini hari dan memperbarui driver proprietary GPU (NVIDIA DKMS) atau kernel security patch.
3. Karena modul kernel dikompilasi secara dinamis di masing-masing node lokal, digest SHA-256 dari nvidia.ko pada setiap node berbeda (akibat timestamp kompilasi dan gcc build-id lokal yang unik).
4. Subsystem kernel IMA menangkap pemuatan modul kernel baru via hook MODULE_CHECK dan meng-extend PCR 10. Akibatnya, PCR 10 tidak lagi cocok dengan baseline statis yang tersimpan di database Verifier.

Solusi & Mitigasi Permanen

1. Nonaktifkan DKMS Kompilasi Lokal di Node Produksi: Beralih ke pre-compiled signed kernel modules via enterprise internal artifact repository.
2. Terapkan Modul IMA Appraisal dengan Digital Signature (ima-sig): Ubah konfigurasi policy IMA dari verifikasi hash statis (ima-ng) ke validasi tanda tangan kriptografis berbasis sertifikat (ima-sig).
   TEXT

   measure func=MODULE_CHECK template=ima-sig pcr=10
   appraise func=MODULE_CHECK appraise_type=imasig

   Selama modul kernel ditandatangani oleh Internal Corporate Build CA yang terdaftar di .secondary_trusted_keys keyring kernel, Verifier dapat memvalidasi keabsahan modul secara algoritmik tanpa memerlukan pre-computed hash statis untuk setiap file.
3. Integrasikan CI/CD GitOps Baseline Updater: Setiap kali rilis kernel resmi dipromosikan melalui ArgoCD, job otomatis memperbarui allowlist di database Keylime Verifier sebelum rolling reboot node dijalankan.

4.2 Kasus 2: TPM In-Kernel Resource Manager Contention & Serial Bus Starvation (/dev/tpmrm0 Deadlock)

Gejala (Symptoms)

Keylime Agent mengalami intermittent timeout saat mengirimkan quote ke Verifier. Log agen dipenuhi pesan error:
ERROR: tpm2_quote failed: TPM device or resource busy (RC: 0x902).
Pada saat bersamaan, utilisasi CPU kworker melonjak dan dmesg menampilkan pesan:
tpm tpm0: Operation Timed out.

Root Cause Analysis (RCA)

1. Analisis Bus Hardware: TPM 2.0 fisik terhubung ke motherboard melalui bus serial berkecepatan rendah (LPC atau SPI bus dengan bandwidth maksimal 24-33 MHz).
2. Analisis Kontensi: Pada host berjalan beberapa proses independen yang mengakses hardware TPM secara serentak:
   • Keylime Agent yang meminta quote setiap 2 detik.
   • Daemon systemd-cryptenroll yang secara berkala memeriksa status seal kunci partisi disk NVMe.
   • Agent Teleport yang menjalankan hardware token verification.
3. Salah satu service mengakses character device mentah legacy /dev/tpm0 secara langsung tanpa melalui In-Kernel TPM Resource Manager (/dev/tpmrm0).
4. Karena /dev/tpm0 tidak memiliki multiplexing transaksional, thread yang mengaksesnya mengunci chip TPM pada level hardware bus. Permintaan berikutnya dari Keylime Agent mengalami timeout dan menyebabkan hardware state machine TPM terkunci (starvation).

Solusi & Mitigasi Permanen

1. Paksa Penggunaan In-Kernel Resource Manager (/dev/tpmrm0): Ubah konfigurasi seluruh software (Keylime, Teleport, systemd) agar hanya menggunakan /dev/tpmrm0 dan bukan /dev/tpm0:
   INI

   # Di /etc/keylime/agent.conf
   tpm_device = "/dev/tpmrm0"

2. Blokir Akses Langsung ke /dev/tpm0 via Udev Rules: Buat aturan udev /etc/udev/rules.d/99-tpm-rm-enforce.rules:
   UDEV

   KERNEL=="tpm0", MODE="0600", OWNER="root", GROUP="root"
   KERNEL=="tpmrm0", MODE="0660", OWNER="root", GROUP="tss"

   Langkah ini memastikan bahwa proses non-kernel root tidak dapat mengabaikan in-kernel multiplexer.
3. Penyelarasan Timeout Driver TPM: Tuning parameter driver TPM di kernel command-line: tpm_tis.interrupts=0 jika interupsi hardware MSI mengalami bad signaling pada chip motherboard tertentu.

4.3 Kasus 3: IMA Runtime Log Memory Explosion & Verifier Processing Timeout pada Containerized Node

Gejala (Symptoms)

Node Kubernetes yang menjalankan ribuan short-lived batch jobs (misalnya worker pipeline CI/CD Kaniko / Buildah) mengalami penurunan performa drastis. Verifier membutuhkan waktu lebih dari 15 detik untuk memvalidasi satu quote dari node tersebut (timeout threshold = 3 detik), sehingga node sering kali ditandai sebagai UNRESPONSIVE.

Root Cause Analysis (RCA)

1. Inspeksi Log IMA: File /sys/kernel/security/ima/ascii_runtime_measurements membengkak hingga mencapai lebih dari 1.8 juta baris (ukuran > 350 MB dalam memori kernel RAM tak tervirtualisasi).
2. Analisis Aturan IMA: Aturan pada /etc/ima/ima-policy sebelumnya menggunakan aturan luas: measure func=BPRM_CHECK template=ima-ng pcr=10 tanpa mengecualikan filesystem overlay container sementara atau biner temporer build.
3. Setiap kali container CI/CD membuat biner sementara, mengkompilasi file C/Go, atau menjalankan utility shell pendek, kernel menghitung digest dan mencatat entri baru ke memori IMA.
4. Ketika Keylime Verifier melakukan evaluasi quote, Verifier harus mengunduh seluruh 1.8 juta rekaman log dan memutar ulang (replay) 1.8 juta operasi SHA-256 secara berurutan untuk mencocokkan nilai akhir PCR 10. Komputasi ini membutuhkan waktu > 12 detik CPU time per node per siklus.

Solusi & Mitigasi Permanen

1. Perketat Policy IMA dengan FSMAGIC Exclusion: Tambahkan pengecualian spesifik untuk filesystem overlay ephemera, tmpfs, cgroupfs, dan direktori build temporer di /etc/ima/ima-policy:
   TEXT

   dont_measure fsmagic=0x01021994 # TMPFS
   dont_measure fsmagic=0x794c7630 # OVERLAYFS_SUPER_MAGIC
   dont_measure obj_type=tmp_t
   dont_measure obj_type=container_file_t

2. Aktifkan Fitur IMA Log Pruning / Incremental Replay pada Keylime v7.11+: Konfigurasikan Verifier untuk hanya meminta incremental measurement log sejak indeks verifikasi terakhir (last_event_id), bukan mengunduh seluruh log dari baris 0 setiap siklus 2 detik.
3. Terapkan Caching pada Verifier: Aktifkan in-memory LRU cache untuk hash biner yang telah diverifikasi sehingga Verifier tidak perlu melakukan verifikasi ulang terhadap biner umum (seperti /bin/bash, /usr/bin/python3) yang sudah ada di database golden state.

4.4 Kasus 4: EK Manufacturer Certificate Pinning Mismatch pada Heterogeneous Bare-Metal Fleet

Gejala (Symptoms)

Ketika 50 server baru dari vendor OEM berbeda (kombinasi server Dell PowerEdge dengan chip Nuvoton dan server HPE ProLiant dengan chip Infineon) ditambahkan ke klaster Kubernetes, seluruh node gagal mendaftar pada Keylime Registrar dengan log:
ERROR: EK Certificate validation failed: Certificate signed by unknown CA (Authority Key Identifier mismatch).

Root Cause Analysis (RCA)

1. Analisis Registrar: Keylime Registrar dikonfigurasi dengan check_ek = true dan require_ek_cert = true.
2. Folder certificate trust store di Registrar (/var/lib/keylime/tpm_cert_store) hanya berisi Root CA dari Intel dan AMD.
3. TPM fisik pada server Dell menggunakan chip Nuvoton NPCT75x, sedangkan server HPE menggunakan chip Infineon SLB9670.
4. Sertifikat Endorsement Key (EK) yang ditanam di NVRAM TPM oleh vendor tersebut ditandatangani oleh intermediate CA resmi masing-masing vendor:
   • Nuvoton TPM Root CA
   • Infineon TPM Root CA 2026
5. Karena sertifikat CA perantara ini tidak terpasang di store Registrar, verifikasi rantai sertifikat X.509 gagal, dan Registrar menolak menerbitkan AIK bagi server-server baru tersebut.

Solusi & Mitigasi Permanen

1. Lakukan Ekstraksi dan Validasi Rantai Sertifikat Vendor Resmi: Unduh paket bundle sertifikat TCG resmi dari vendor hardware terpercaya:
   BASH

   mkdir -p /var/lib/keylime/tpm_cert_store/{nuvoton,infineon,stmicro,intel,amd}
   # Unduh sertifikat root dan intermediate resmi dari repositori vendor terverifikasi

2. Otomatisasi Pendaftaran EK via Script Pre-Provisioning: Gunakan command tpm2_getekcertificate pada fase bootstrap PXE/iPXE untuk mengekstrak sertifikat EK dari NVRAM TPM index 0x01c00002 (RSA EK Cert) atau 0x01c0000a (ECC EK Cert), memvalidasi fingerprint terhadap database serial number OEM hardware purchasing order, lalu mendaftarkannya ke Registrar.
3. Terapkan Fallback Enrollment dengan Dual-Approval: Untuk modul TPM virtual (vTPM pada hypervisor KVM/Proxmox) yang tidak memiliki sertifikat fisik dari pabrik silikon, buat profil pendaftaran terpisah berbasis Self-Signed EK with Enterprise CA Endorsement yang disetujui via mekanisme GitOps dual-custody.

5. Tabel Komparasi & Standar Industri Hardware Root-of-Trust

6. Ringkasan Eksekutif & Roadmap Integrasi SecOps 2026

Implementasi Hardware Root-of-Trust TPM 2.0 yang dikombinasikan dengan Linux Kernel IMA dan orkestrasi Keylime v7.11+ menutup celah keamanan paling kritis dalam infrastruktur modern: ancaman kompromi level kernel dan firmware.

Dengan menghubungkan:

1. TPM 2.0 Hardware Silikon: Sebagai jangkar kriptografis yang membuktikan identitas fisik node tanpa kemungkinan spoofing.
2. Kernel IMA Subsystem: Sebagai pengawas integritas real-time yang mencatat setiap eksekusi kode ke register PCR 10 secara deterministik.
3. Keylime Continuous Remote Attestation Engine: Sebagai penguji integritas multi-cluster yang mengevaluasi quote hardware setiap 2 detik dengan protokol Zero-Trust Secret Splitting ( \oplus V$).
4. Kubernetes Closed-Loop Revocation: Yang secara otomatis mengisolasi node yang terkompromi via Taint dan pengosongan in-memory keyspace sebelum penyerang dapat bergerak lateral (lateral movement).

Infrastruktur enterprise mencapai standar tertinggi Zero-Trust Architecture (ZTA) di mana kepercayaan tidak pernah diasumsikan (never trust), melainkan diverifikasi secara matematis hingga ke tingkat atomik silikon perangkat keras (always verify with cryptographic proof). 🫡🌊