하드웨어 난수 생성기 (hwrng / TRNG)

hwrng 경로를 커널 엔트로피 품질과 암호학적 안전성 관점에서 심층 분석합니다. hwrng 프레임워크와 드라이버 등록(Driver Registration) 모델, 하드웨어 난수 소스 신뢰도 평가, 엔트로피 풀 혼합과 credit 정책, 커널 CSPRNG(ChaCha20) 초기화·재시드 동작, 부팅 초기 entropy starvation 대응, 가상화(Virtualization)/임베디드 환경의 난수 공급 이슈, rngd와 userspace 연계, 품질 검증과 장애 진단 절차까지 안전한 난수 인프라 구축에 필요한 핵심을 다룹니다.

hwrng 서브시스템 개요

Linux 커널의 hwrng(Hardware Random Number Generator) 서브시스템은 다양한 하드웨어 난수 생성기를 통일된 인터페이스로 추상화합니다. SoC 내장 TRNG, CPU RNG 명령, TPM 2.0, USB/PCIe 외장 RNG 등 모든 하드웨어 RNG는 동일한 struct hwrng API를 통해 커널 엔트로피 풀에 기여합니다.

아래 다이어그램은 엔트로피 수집부터 난수 생성·사용까지 커널 RNG 전체 파이프라인과 핵심 알고리즘 구현 함수를 한눈에 보여줍니다. hwrng·input_pool(Blake2s)· ChaCha20 CRNG(출력 풀)·get_random_bytes()·getrandom() 시스템 콜과 vDSO 빠른 경로, /dev/random·/dev/urandom·/dev/hwrng 장치까지 모든 경로를 총망라합니다.

난수 생성기 분류

TRNG — 하드웨어 기반 진난수 생성기

TRNG(True Random Number Generator)는 열역학적·전기적 물리 현상의 본질적 불확실성을 이용하여 결정론적 알고리즘 없이 난수를 생성합니다. TRNG의 출력은 어떤 수학적 모델로도 완전히 예측할 수 없으며, 이는 소프트웨어 PRNG와 근본적으로 다른 점입니다. Linux 커널에서 hwrng 서브시스템으로 관리되는 대부분의 장치가 TRNG에 해당합니다.

열잡음(Thermal Noise, Johnson-Nyquist Noise): 도체 내 자유 전자의 열적 요동(Brownian Motion)에 의해 발생하는 전압 변동으로, 전력 스펙트럼 밀도가 S(f) = 4kTR(k: 볼츠만 상수, T: 절대온도, R: 저항)로 주어집니다. 이 잡음은 주파수에 무관한 백색 잡음(White Noise)이며, 고전적 열역학 법칙에 의해 예측 불가능합니다. 아날로그 TRNG 칩(예: Intel 82802 FWH, Broadcom BCM2835)은 이 열잡음을 증폭하고 비교기(Comparator)로 디지털 비트를 생성합니다.

/* drivers/char/hw_random/bcm2835-rng.c — Raspberry Pi 열잡음 기반 TRNG */

static int bcm2835_rng_read(struct hwrng *rng, void *buf,
                              size_t max, bool wait)
{
    struct bcm2835_rng_priv *priv = to_rng_priv(rng);
    u32 max_words = max / sizeof(u32);
    u32 num_words, count;

    /* RNG 상태 레지스터에서 사용 가능한 워드 수 확인 */
    while ((rng_readl(priv, RNG_STATUS) >> 24) == 0) {
        if (!wait)
            return 0;
        cpu_relax();  /* 열잡음 축적 대기 */
    }

    num_words = rng_readl(priv, RNG_STATUS) >> 24;
    if (num_words > max_words)
        num_words = max_words;

    for (count = 0; count < num_words; count++)
        ((u32 *)buf)[count] = rng_readl(priv, RNG_DATA);

    return num_words * sizeof(u32);
}

클록 지터(Clock Jitter): 오실레이터의 주기적 신호에서 발생하는 시간 변동(Phase Noise)을 이용합니다. 두 개의 독립 링 오실레이터(Ring Oscillator)를 동시에 구동하고, 한쪽의 상승 에지(Rising Edge)에서 다른 쪽의 상태를 샘플링하면 수 ps~ns 단위의 지터가 비결정적 비트로 변환됩니다. Intel의 RDRAND/RDSEED 명령어 내부에 이 방식의 TRNG가 탑재되어 있습니다.

/* arch/x86/include/asm/archrandom.h — Intel RDRAND 접근 */

static inline bool __must_check rdrand_long(unsigned long *v)
{
    bool ok;
    unsigned int retry = RDRAND_RETRY_LOOPS;  /* 10회 재시도 */

    do {
        asm volatile(RDRAND_LONG
            "\n\tsetc %1"
            : "=a"(*v), "=qm"(ok));
        if (ok)
            return true;
    } while (--retry);

    return false;
}

/*
 * RDRAND vs RDSEED 차이:
 * - RDRAND: TRNG → AES-CBC-MAC 컨디셔닝 → DRBG → 출력 (후처리된 결정론적 출력)
 * - RDSEED: TRNG → AES-CBC-MAC 컨디셔닝 → 직접 출력 (풀 엔트로피 비결정론적)
 * Linux 커널은 RDSEED를 우선 사용하고, 실패 시 RDRAND로 폴백합니다.
 */

준안정 플립플롭(Metastable Flip-Flop): 래치(Latch) 회로의 셋업 타임(Setup Time) 위반 시 발생하는 준안정 상태(Metastable State)를 이용합니다. 비동기 클록으로 D 플립플롭의 입력을 토글(Toggle)하면 출력이 "0"과 "1" 사이에서 진동하다가 최종 안정 상태로 수렴하는데, 어느 쪽으로 수렴할지는 트랜지스터(Transistor) 레벨의 열잡음에 의해 결정됩니다. FPGA 기반 TRNG에서 흔히 사용되며, Xilinx/Intel FPGA의 LUT를 링 오실레이터로 구성하여 구현합니다.

jitterentropy — 소프트웨어 TRNG: 하드웨어 TRNG가 없는 환경(가상 머신, 임베디드)에서 CPU 타이밍 지터만으로 엔트로피를 생성하는 소프트웨어 TRNG입니다. Linux 커널의 crypto/jitterentropy.c에 구현되어 있으며, 메모리 접근 시간, CPU 명령어 실행 시간의 나노초 단위 변동을 엔트로피로 수집합니다.

/* crypto/jitterentropy.c — CPU 타이밍 지터 기반 엔트로피 수집 */

static u64 jent_loop_shuffle(struct rand_data *ec,
                              unsigned int bits, unsigned int min)
{
    u64 time = 0;
    u64 shuffle = 0;

    /* 메모리 접근 루프 — 캐시 미스에 의한 지터 수집 */
    jent_memaccess(ec, min);

    /* 고해상도 타임스탬프 읽기 (TSC/CNTVCT) */
    jent_get_nstime(&time);

    /* 타이밍 차이(delta)에서 엔트로피 추출 */
    if ((centered & 1) == 0)
        shuffle = time;   /* 홀수/짝수 비트 — 타이밍 비결정성 */

    return shuffle;
}

/*
 * jitterentropy가 커널에 제공하는 인터페이스:
 * - crypto_alloc_rng("jitterentropy_rng") → crypto RNG API 통합
 * - CRNG 초기 씨드로 자동 사용 (CONFIG_RANDOM_TRUST_CPU 비활성 시)
 * - FIPS 140-3 환경에서 독립 엔트로피 소스로 인정
 */

PRNG — 의사 난수 생성기

PRNG(Pseudo Random Number Generator)는 결정론적 알고리즘으로 난수처럼 보이는 수열을 생성합니다. 동일한 씨드(Seed)를 입력하면 항상 동일한 출력 수열이 나오므로 재현 가능합니다. 이 특성은 시뮬레이션, 게임, 테스트에서는 장점이지만 보안 용도에는 절대 사용해서는 안 됩니다 — 씨드를 알면 전체 출력을 예측할 수 있기 때문입니다.

선형 합동 생성기(LCG, Linear Congruential Generator): 가장 단순한 PRNG로, Xn+1 = (a·Xn + c) mod m 공식을 사용합니다. C 표준 라이브러리의 rand(), glibc의 random()이 LCG 변형을 사용합니다. 주기(Period)가 최대 m으로 제한되며, 하위 비트의 품질이 특히 나쁩니다. 하위 k비트의 주기는 2^k에 불과하여 rand() % 2는 0과 1이 교대로 나올 수 있습니다.

/* glibc — rand() 구현 (TYPE_0 모드, 단순 LCG) */

/* 파라미터: a = 1103515245, c = 12345, m = 2^31 */
static int32_t __random_r(struct random_data *buf, int32_t *result)
{
    int32_t val = buf->state[0];
    val = ((int32_t)(val * 1103515245) + 12345) & 0x7fffffff;
    buf->state[0] = val;
    *result = val;
    return 0;
}

/* 문제점: 씨드를 알면 전체 수열 예측 가능
 * 2^31 = ~21억 주기 — 현대 GPU로 수 초 만에 전수 탐색
 * rand() 출력 연속 3개만 관찰하면 내부 상태 완전 복원 가능 (Knuth 알고리즘) */

메르센 트위스터(Mersenne Twister, MT19937): 623차원에서 균등분포를 보장하는 PRNG로, 주기가 2¹⁹⁹³⁷-1(메르센 소수)입니다. 624개의 32비트 워드(2,496바이트)를 내부 상태로 사용하며, SIMD 최적화(SFMT)를 통해 매우 빠른 난수 생성이 가능합니다. Python의 random 모듈, Ruby, R, MATLAB 등 대부분의 언어 기본 PRNG가 MT19937입니다.

/* Mersenne Twister 핵심 알고리즘 (개념 코드) */

#define N 624      /* 상태 벡터 크기 */
#define M 397      /* 재귀 오프셋 */

static u32 mt[N];   /* 내부 상태 (2,496바이트) */
static int mti;

/* 상태 갱신 (twist) — 624워드 소진 시 일괄 갱신 */
static void generate_numbers(void)
{
    u32 y;
    for (int i = 0; i < N; i++) {
        y = (mt[i] & 0x80000000) | (mt[(i+1) % N] & 0x7fffffff);
        mt[i] = mt[(i + M) % N] ^ (y >> 1);
        if (y & 1)
            mt[i] ^= 0x9908b0df;  /* 매직 상수 */
    }
}

/* 출력 템퍼링 (tempering) — 균등분포 개선 */
static u32 extract_number(void)
{
    u32 y = mt[mti++];
    y ^= (y >> 11);                     /* 우시프트 11 */
    y ^= (y << 7) & 0x9d2c5680;       /* 좌시프트 7 + AND */
    y ^= (y << 15) & 0xefc60000;      /* 좌시프트 15 + AND */
    y ^= (y >> 18);                     /* 우시프트 18 */
    return y;
}

/*
 * 보안 취약점: 연속 출력 624개를 관찰하면 템퍼링을 역산하여
 * 내부 상태 624워드를 100% 복원 가능 → 이후 모든 출력 예측
 * MT19937은 암호학적으로 완전히 안전하지 않습니다.
 */

xoshiro/xorshift 계열: Blackman-Vigna가 설계한 최신 PRNG 계열로, 메르센 트위스터보다 빠르고 상태 크기가 작습니다. xoshiro256**는 256비트(32바이트) 상태로 2²⁵⁶-1 주기를 제공하며, BigCrush 통계 테스트를 모두 통과합니다. V8(Chrome JavaScript 엔진)의 Math.random()이 xorshift128+를 사용합니다.

/* xoshiro256** — 현대적 고속 PRNG */

static u64 s[4];  /* 256비트 상태 */

static inline u64 rotl(u64 x, int k) { return (x << k) | (x >> (64 - k)); }

static u64 xoshiro256ss(void)
{
    u64 result = rotl(s[1] * 5, 7) * 9;  /* starstar 출력 함수 */
    u64 t = s[1] << 17;

    s[2] ^= s[0];
    s[3] ^= s[1];
    s[1] ^= s[2];
    s[0] ^= s[3];

    s[2] ^= t;
    s[3] = rotl(s[3], 45);

    return result;
}

/* 성능 비교 (cycles per byte, x86-64):
 *   LCG rand():       ~4 cpb
 *   MT19937:          ~2.5 cpb
 *   xoshiro256**:     ~0.8 cpb (SIMD 미사용)
 *   ChaCha20-CRNG:    ~2.0 cpb (CSPRNG, 보안 보장)
 */

Linux 커널에서 PRNG의 변천: 과거 Linux 커널은 prandom_u32()라는 비보안 PRNG를 네트워킹 해시(Hash), 타이머(Timer) 지터 등에 사용했습니다. 이 함수는 Tausworthe 생성기(LCG 변형)를 사용하여 빠르지만 예측 가능했습니다. Linux 5.19에서 일부 prandom_u32() 호출처가 get_random_u32()로 변경되었으며, 현재 커널에서는 비보안 PRNG를 사용할 수 있는 경로가 거의 없습니다. 이 변경은 커널 내부의 ASLR, 네트워크 시퀀스 번호 등이 PRNG를 통해 예측 공격에 노출되던 문제를 근본적으로 해결했습니다.

CSPRNG — 암호학적 안전 의사 난수 생성기

CSPRNG(Cryptographically Secure PRNG)는 PRNG에 두 가지 보안 속성을 추가한 것입니다. 첫째, 다음 비트 예측 불가(Next-Bit Unpredictability) — 출력의 처음 k비트를 알아도 (k+1)번째 비트를 다항식 시간(Polynomial Time) 내에 50% 이상의 확률로 예측할 수 없습니다. 둘째, 역추적 저항(Backtracking Resistance) — 내부 상태가 노출되더라도 과거에 생성한 출력을 복원할 수 없습니다. 이 두 속성은 IND-CPA(선택 평문 공격 하 구별 불가능성) 안전성을 보장하며, 현대 암호 시스템의 기반이 됩니다.

Linux ChaCha20-CRNG: Linux 커널의 핵심 CSPRNG입니다. Daniel Bernstein이 설계한 ChaCha20 스트림 암호를 per-CPU 키 상태와 결합하여 높은 성능과 보안을 동시에 달성합니다. 32바이트 키와 12바이트 논스로 초기화된 ChaCha20 블록 함수가 64바이트 출력 중 앞 32바이트를 즉시 새 키로 교체(Fast Key Erasure)하여 메모리 노출 시에도 이전 출력을 역추적할 수 없게 합니다.

/* drivers/char/random.c — ChaCha20 CRNG Fast Key Erasure (핵심 메커니즘) */

static void crng_fast_key_erasure(u8 key[CHACHA_KEY_SIZE],
                                    struct chacha_state *chacha_state,
                                    u8 *random_data, size_t random_data_len)
{
    u8 first_block[CHACHA_BLOCK_SIZE];  /* 64바이트 */

    /* ChaCha20 state 조립: 상수 + 키 + 카운터(0) + 논스(0) */
    chacha_init_consts(chacha_state);
    memcpy(&chacha_state->x[4], key, CHACHA_KEY_SIZE);
    memset(&chacha_state->x[12], 0, sizeof(u32) * 4);

    /* ChaCha20 1블록 생성 (카운터 0에서 시작) */
    chacha20_block(chacha_state, first_block);

    /* 앞 32바이트 = 새 키로 교체 (Forward Secrecy 보장) */
    memcpy(key, first_block, CHACHA_KEY_SIZE);

    /* 나머지 32바이트 = 난수 출력으로 사용 */
    memcpy(random_data, first_block + CHACHA_KEY_SIZE, random_data_len);

    /* 중간 데이터 즉시 소거 */
    memzero_explicit(first_block, sizeof(first_block));
}

/*
 * per-CPU 구조로 동작:
 *   CPU 0: [key_0][nonce_0] → ChaCha20 → 출력 + 새 key_0
 *   CPU 1: [key_1][nonce_1] → ChaCha20 → 출력 + 새 key_1
 *   ...
 * → 락(Lock) 경합 없이 병렬 난수 생성, NUMA 친화적
 * → 약 60초마다 또는 세대 갱신 필요 시 input_pool에서 재씨딩(reseed)
 */

Fortuna (FreeBSD/macOS): Niels Ferguson과 Bruce Schneier가 설계한 CSPRNG으로, 32개의 독립 엔트로피 풀을 사용하여 부분 상태 노출에 대한 복원력을 제공합니다. 풀 k는 2^k번째 재씨드마다 참여하므로 공격자가 일부 풀을 제어하더라도 장기적으로 엔트로피가 축적됩니다. FreeBSD의 /dev/random, macOS의 SecRandomCopyBytes()가 Fortuna 기반입니다.

다른 운영체제의 CSPRNG:

DRBG — 결정론적 난수 비트 생성기 (NIST 표준)

DRBG(Deterministic Random Bit Generator)는 NIST SP 800-90A 표준에서 정의한 CSPRNG의 공식 명칭입니다. "결정론적"이라는 이름이 붙었지만 이는 내부 알고리즘이 결정론적이라는 의미이며, 외부에서 공급받는 엔트로피 씨드에 의해 출력의 예측 불가능성이 보장됩니다. DRBG는 FIPS 140-2/3 인증 환경에서 필수적으로 요구되며, 미국 정부 시스템, 금융 기관, 의료 기기 등에서 사용됩니다.

NIST SP 800-90A의 3가지 DRBG 메커니즘:

CTR-DRBG 동작 원리: AES-CTR 모드를 기반으로 동작합니다. 내부 상태는 AES 키(Key)와 카운터(V)로 구성되며, 씨딩(Seed) 시 Key ⊕ entropy, V ⊕ entropy로 상태를 갱신합니다. 난수 생성 시 V를 1씩 증가시키며 AES-ECB로 암호화한 결과를 출력합니다. 10만 번 요청(Request)마다 또는 2⁴⁸비트 생성마다 재씨딩이 필수입니다.

/* Linux 커널의 DRBG 사용 — crypto API를 통한 CTR-DRBG */

#include <crypto/drbg.h>
#include <crypto/rng.h>

static int fips_generate_key(u8 *key, size_t keylen)
{
    struct crypto_rng *rng;
    int ret;

    /* FIPS 모드에서는 DRBG를 명시적으로 사용
     * "drbg_nopr_ctr_aes256" = CTR-DRBG, AES-256, 예측 저항 없음(No PR)
     * "drbg_pr_ctr_aes256"   = CTR-DRBG, AES-256, 예측 저항 활성(PR)
     */
    rng = crypto_alloc_rng("drbg_nopr_ctr_aes256", 0, 0);
    if (IS_ERR(rng))
        return PTR_ERR(rng);

    /* DRBG 씨딩은 커널이 자동 수행 (input_pool에서 추출) */

    /* 난수 생성 — 최대 요청 크기: 2^16 바이트 */
    ret = crypto_rng_get_bytes(rng, key, keylen);

    crypto_free_rng(rng);
    return ret;
}

/*
 * Linux 커널 DRBG 구현 위치: crypto/drbg.c
 *
 * 사용 가능한 DRBG 알고리즘 목록:
 *   drbg_nopr_ctr_aes128    — CTR-DRBG, AES-128, No Prediction Resistance
 *   drbg_nopr_ctr_aes256    — CTR-DRBG, AES-256, No Prediction Resistance
 *   drbg_pr_ctr_aes128      — CTR-DRBG, AES-128, Prediction Resistance
 *   drbg_pr_ctr_aes256      — CTR-DRBG, AES-256, Prediction Resistance
 *   drbg_nopr_hmac_sha256   — HMAC-DRBG, SHA-256
 *   drbg_nopr_hmac_sha512   — HMAC-DRBG, SHA-512
 *   drbg_nopr_sha256        — Hash-DRBG, SHA-256
 *   drbg_nopr_sha512        — Hash-DRBG, SHA-512
 *
 * 참고: FIPS 140-3 인증에서는 CTR-DRBG(AES-256)가 권장됩니다.
 */

HMAC-DRBG의 특수 용도 — 결정론적 서명: RFC 6979는 HMAC-DRBG를 사용하여 ECDSA/DSA 서명의 k값(논스)을 결정론적으로 생성합니다. 이 방식은 서명할 때마다 동일한 메시지에 대해 동일한 k값이 나오므로 PRNG 실패로 인한 개인 키 노출 위험을 제거합니다(Sony PS3 ECDSA 사고가 이 취약점(Vulnerability)의 대표 사례입니다). Linux 커널의 crypto/ecdsa.c에서 이 방식을 활용합니다.

예측 저항(Prediction Resistance) 모드: DRBG의 PR 모드(drbg_pr_*)는 매 요청마다 엔트로피 소스에서 새 씨드를 받아 재씨딩합니다. 이는 내부 상태가 노출되더라도 다음 출력부터 즉시 안전성이 회복되므로 가장 높은 보안 수준을 제공하지만, 성능 비용이 큽니다. FIPS 140-3 Level 4(물리적 보안) 환경에서 요구됩니다.

양자 기반 난수 방식별 비교

커널 내 hwrng 위치 — 아키텍처 다이어그램

QRNG와 양자 기반 TRNG 물리 원리

QRNG(Quantum Random Number Generator)는 양자 역학의 고유한 비결정성(inherent randomness)을 활용하여 원리적으로 예측 불가능한 진난수(True Random Number)를 생성합니다. 고전적 TRNG(열잡음, 지터)는 환경 조건에 따라 편향이 발생할 수 있지만, QRNG는 양자역학 법칙 자체가 비결정성을 보장하므로 어떤 물리적 모델로도 예측할 수 없습니다. 상용 QRNG는 주로 광자·진공 요동·레이저 위상 잡음 같은 광학적 양자 현상을 엔트로피 원천으로 사용합니다. 방사성 붕괴도 양자역학적 비결정성을 이용하는 진난수 원천이지만, 일반적으로 광학 기반 QRNG 제품군보다는 별도의 양자 기반 TRNG 또는 연구용 난수 소스로 구분하는 편이 정확합니다.

빔 분리기(Beam Splitter) 방식

빔 분리기 방식은 가장 직관적인 QRNG 원리입니다. 단일 광자를 50:50 빔 스플리터(Half Mirror)에 입사시키면, 양자역학의 중첩(Superposition) 원리에 의해 광자는 투과 경로와 반사 경로 중 하나를 완전히 비결정적으로 선택합니다. 이때 두 경로에 각각 배치된 단일 광자 검출기(SPD, Single Photon Detector)가 어느 쪽에서 검출되었는지에 따라 "0" 또는 "1" 비트를 생성합니다.

이 과정의 비결정성은 하이젠베르크 불확정성 원리(Heisenberg Uncertainty Principle)에서 직접 비롯됩니다. 광자의 편광 상태를 비직교 기저(Non-orthogonal Basis)로 측정하면 결과는 본질적으로 확률적이며, 어떤 숨은 변수(Hidden Variable)로도 예측할 수 없음이 벨 부등식(Bell's Inequality) 위반 실험으로 증명되었습니다. 대표 제품인 ID Quantique Quantis는 이 방식으로 4~16 Mbps의 진난수를 생성하며, USB/PCIe 폼팩터로 Linux hwrng 서브시스템에 직접 등록됩니다.

진공 요동(Vacuum Fluctuation) 방식

양자전기역학(QED)에 따르면 완전한 진공 상태에서도 전자기장의 에너지는 영점 에너지(Zero-Point Energy)라는 최소값을 가지며, 이 영점 에너지 주위로 양자 요동(Quantum Fluctuation)이 끊임없이 발생합니다. 진공 요동 QRNG는 이 양자 요동을 호모다인 검출(Homodyne Detection) 기법으로 측정합니다.

로컬 오실레이터(Local Oscillator) 레이저와 진공 상태의 신호를 50:50 빔 스플리터에서 간섭시키면, 출력 포트에서 측정되는 광전류의 차이(차동 전류)가 바로 진공 요동을 반영합니다. 이 차동 신호를 고속 ADC(Analog-to-Digital Converter)로 디지털화하면 가우시안 분포를 따르는 원시 난수가 됩니다. 에너지-시간 불확정성 관계(ΔE·Δt ≥ ℏ/2)가 이 요동의 하한을 보장합니다.

진공 요동 방식의 핵심 장점은 높은 처리량(Throughput)입니다. 광대역 호모다인 검출기는 GHz 대역폭(Bandwidth)을 가질 수 있어 100 Mbps 이상의 난수 생성이 가능합니다. QuintessenceLabs의 qStream은 이 방식으로 1 Gbps 이상의 출력을 달성하며, 서버 랙 마운트(Mount) 형태로 데이터센터 환경에 적합합니다.

광자 도착 시간(TOAD) 방식

약한 코히어런트 광원(Weak Coherent Source)에서 방출되는 광자의 수는 포아송 분포(Poisson Distribution)를 따릅니다. 평균 광자 수 μ가 1보다 훨씬 작은 감쇠 레이저를 사용하면, 대부분의 시간 슬롯에서 0개의 광자가 방출되고 드물게 1개의 광자가 방출됩니다. 이때 연속된 광자 검출 이벤트 사이의 시간 간격(Δt)은 양자역학적으로 비결정적이며, 이 시간 정보를 디지털화하여 난수 비트를 생성합니다.

TOAD(Time-Of-Arrival Detector) 방식은 파동-입자 이중성(Wave-Particle Duality)을 엔트로피 원천으로 활용합니다. 광자의 방출 시점은 자발 방출(Spontaneous Emission)에 의해 결정되므로 원리적으로 예측 불가능합니다. 한국의 EYL(이와이엘)은 이 방식의 QRNG를 CMOS 반도체 칩으로 집적하여 스마트폰 내장이 가능한 초소형 폼팩터(1mm² 이하)를 구현하였습니다. Samsung Galaxy Quantum 시리즈에 탑재된 QRNG 칩이 이 방식입니다.

레이저 위상 잡음(Laser Phase Noise) 방식

반도체 레이저의 발진 과정에서 자발 방출(Spontaneous Emission)은 유도 방출(Stimulated Emission)과 무관하게 레이저 위상에 무작위 섭동(Random Perturbation)을 발생시킵니다. 이 위상 확산(Phase Diffusion) 현상의 스펙트럼 폭은 Schawlow-Townes 선폭 공식으로 기술되며, 양자역학적 원천을 가집니다.

레이저 위상 잡음 QRNG는 지연(Latency) 간섭계(Delay-Line Interferometer)를 통해 위상 잡음을 진폭 변동으로 변환합니다. 두 팔 사이의 위상 차이가 비결정적이므로 간섭계 출력 광강도의 변동도 비결정적이며, 이를 고속 포토디텍터와 ADC로 디지털화합니다. 이 방식의 최대 장점은 극한의 처리량입니다. 광통신용 변조기(Modulator)와 동일한 대역폭을 활용할 수 있어 이론적으로 10 Gbps 이상의 난수 생성이 가능합니다. Toshiba와 Quside가 이 방식의 상용화를 선도하고 있습니다.

방사성 붕괴(Radioactive Decay) 기반 TRNG

방사성 붕괴는 가장 오래된 양자 난수 원천으로, 불안정한 원자핵이 알파 입자나 베타 입자를 방출하는 시점이 양자 터널링(Quantum Tunneling)에 의해 결정됩니다. 가이거-뮐러(Geiger-Müller) 계수관이 개별 붕괴 이벤트를 검출하며, 연속된 이벤트 사이의 시간 간격을 비트로 변환합니다.

이 방식은 양자역학의 비결정성이 명확하게 드러나는 원리이지만, 광학 QRNG 제품군과 달리 방사성 동위원소와 계수관을 쓰는 양자 기반 TRNG로 보는 것이 더 정확합니다. 붕괴율이 물리적으로 제한되어 처리량이 kbps 수준으로 매우 낮습니다. 또한 방사성 물질의 취급에 규제가 따르므로 상용 제품보다는 연구용으로 주로 활용됩니다. 대표적으로 Hotbits 프로젝트는 세슘-137 감마선 소스를 사용하여 인터넷을 통해 양자 난수를 제공합니다.

QRNG 및 양자 기반 TRNG 방식별 종합 비교

엔트로피 풀 메커니즘

커널 엔트로피 풀은 drivers/char/random.c에 구현된 핵심 난수 인프라입니다. Linux 5.17~5.18에서 Jason Donenfeld(WireGuard 저자)의 대규모 재작성을 통해 기존의 LFSR(Linear Feedback Shift Register) 기반 SHA-1 믹싱 구조가(SHA-1→Blake2s 전환: 5.17) 단일 input_pool + Blake2s 해시 기반 256비트 상태로 전면 교체되었습니다(구조 재작성: 5.18). 이 변경으로 코드량이 절반 이하로 줄었고, 암호학적 안전성이 크게 향상되었습니다. 현재 구조에서는 모든 엔트로피 소스(hwrng, 인터럽트 지터, 디스크 I/O 등)가 단일 풀에 혼합된 후 ChaCha20-CRNG로 추출되는 단순하고 검증 가능한 파이프라인(Pipeline)을 형성합니다.

/dev/random vs /dev/urandom — 현대 커널의 통합

엔트로피 소스와 수집 경로

/* drivers/char/random.c — 엔트로피 수집 함수들 */

/* 1. 인터럽트 지터 — 가장 풍부한 소프트웨어 엔트로피 소스 */
void add_interrupt_randomness(int irq)
{
    struct fast_pool *fast_pool = this_cpu_ptr(&irq_randomness);
    struct pt_regs *regs = get_irq_regs();
    unsigned long now = jiffies;
    cycles_t cycles = random_get_entropy();  /* TSC or 아키텍처별 타이머 */

    fast_mix(fast_pool->pool, irq, now ^ cycles,
             regs ? instruction_pointer(regs) : _RET_IP_);

    /* 64회 인터럽트마다 input_pool에 기여 */
    if (++fast_pool->count < 64 && !time_after(now, fast_pool->last + HZ))
        return;
    add_interrupt_bench(cycles);
    mix_interrupt_randomness(fast_pool);
}

/* 2. hwrng 기여 — hw_random 코어가 자동으로 호출 */
void add_hwgenerator_randomness(const void *buf, size_t len,
                                size_t entropy, bool sleep_after)
{
    _mix_pool_bytes(buf, len);          /* input_pool에 혼합 */
    credit_init_bits(entropy);          /* 엔트로피 추정값 증가 */
    wake_up_interruptible(&random_wait); /* 대기 중인 getrandom() 깨움 */

    if (sleep_after && !kthread_should_stop() &&
        (crng_ready() || !entropy))
        schedule_timeout_interruptible(crng_reseed_interval());
}

/* 3. 시스템 이벤트 기여 */
void add_device_randomness(const void *buf, size_t len)  /* MAC 주소, 시리얼 번호 등 */
void add_input_randomness(unsigned int type, unsigned int code, unsigned int val)  /* 키보드/마우스 */
void add_disk_randomness(struct gendisk *disk)  /* 디스크 I/O 완료 타이밍 */

getrandom() 시스템 콜 흐름

/* 사용자 공간에서 사용 */
#include <sys/random.h>

unsigned char key[32];
ssize_t ret = getrandom(key, sizeof(key), 0);  /* 0 = 블록킹 모드 */
if (ret < 0) {
    perror("getrandom");  /* EINTR, EFAULT 가능 */
    return -1;
}

/* GRND_NONBLOCK: CRNG 초기화 전에도 블록하지 않음 (EAGAIN 반환) */
ret = getrandom(key, sizeof(key), GRND_NONBLOCK);

/* GRND_RANDOM: 현대 커널(5.18+)에서는 no-op (레거시 호환용) */
ret = getrandom(key, sizeof(key), GRND_RANDOM);

/* 커널 내부: get_random_bytes() 계열 */
get_random_bytes(buf, nbytes);              /* 범용 */
u32 r = get_random_u32();                   /* 32비트 */
u64 r = get_random_u64();                   /* 64비트 */
u32 r = get_random_u32_below(100);         /* 0~99, 편향 없음 */
u32 r = get_random_u32_inclusive(1, 6);   /* 주사위 1~6 */

엔트로피 예산 계산 — quality 파라미터의 역할

hwrng 코어는 hwrng_fillfn() 커널 스레드(Kernel Thread)를 통해 지속적으로 rng->read()를 호출하고, 읽은 바이트 수와 quality 값을 곱해 엔트로피 기여량을 계산합니다.

/* drivers/char/hw_random/core.c — hwrng_fillfn() 핵심 로직 */
static int hwrng_fillfn(void *unused)
{
    long rc;

    while (!kthread_should_stop()) {
        struct hwrng *rng;
        mutex_lock(&rng_mutex);
        rng = get_current_rng_nolock();
        mutex_unlock(&rng_mutex);

        if (!rng) { msleep(1000); continue; }

        /* read() 호출 — 최대 RNGD_BUFF_SIZE(4096)바이트 */
        rc = rng->read(rng, rng_buffer, rng_buffer_size, true);
        if (rc <= 0) { msleep(500); continue; }

        /* 엔트로피 기여량 계산:
         *   entropy_bits = bytes_read × quality × 8 / 1024
         *   예) 4096바이트 × quality=1024 × 8 / 1024 = 32768비트
         *   예) 4096바이트 × quality=512  × 8 / 1024 = 16384비트
         *   예) 4096바이트 × quality=0    × 8 / 1024 = 0비트 (기여 없음) */
        add_hwgenerator_randomness(rng_buffer, rc,
                                    (rc * rng->quality * 8) >> 10,
                                    true);
    }
    hwrng_put(rng);
    return 0;
}

hwrng 엔트로피 공급 주기

hwrng_fillfn() 커널 스레드는 읽기 성공 시 add_hwgenerator_randomness(..., true) 를 호출합니다. 현대 커널에서는 CRNG 초기화 이후 또는 엔트로피 credit 이 없는 경우 crng_reseed_interval() 만큼 throttle 되므로, 실제 공급 주기는 하드웨어 처리율과 커널 재시드 정책의 영향을 함께 받습니다:

• Intel RDRAND: 마이크로초 (μs) 단위 (~1 GB/s)
• PCIe hwrng 장치: 마이크로초 (μs) 단위 (~100 MB/s)
• USB hwrng 장치: 밀리초 (ms) 단위 (~1 MB/s)
• BCM2835 (라즈베리파이): 밀리초 (ms) 단위 (~200 KB/s)

이와 별개로 CRNG 는 약 60초마다 input_pool 에서 재시드됩니다 (CRNG_RESEED_INTERVAL = 60 * HZ).

credit 메커니즘 심층 분석 — mix와 credit의 분리

현대 리눅스 커널 RNG 설계에서 가장 중요한 개념 중 하나는 데이터 혼합(mix)과 엔트로피 크레딧(credit)이 서로 분리되어 있다는 점입니다. 모든 엔트로피 소스는 input_pool에 바이트를 섞을 수 있지만, 그 바이트를 "얼마만큼의 엔트로피로 신뢰할 것인가"를 선언하는 credit 동작은 별도로 수행됩니다. 이 분리가 없다면 신뢰할 수 없는 소스(예: 조작된 가상 RNG)가 input_pool을 가득 채워 CRNG를 거짓으로 "준비됨(ready)" 상태로 만들 수 있습니다.

mix와 credit의 역할 분담

credit_init_bits() — 초기화 단계 크레딧

credit_init_bits()는 커널 RNG의 유일한 엔트로피 크레딧 함수입니다. 이름은 함수처럼 보이지만 실제로는 매크로이며, crng_ready()가 false일 때만 _credit_init_bits() 구현 함수를 호출합니다 — CRNG 초기화 완료 후에는 크레딧이 no-op가 됩니다. _credit_init_bits()는 input_pool.init_bits 카운터를 lock-free try_cmpxchg로 원자적 갱신하며, 두 단계 임계치를 거쳐 CRNG를 초기화합니다: 128비트 도달 시 CRNG_EARLY (조기 단계), 256비트 도달 시 CRNG_READY (완전 준비) 전환.

/* drivers/char/random.c — 엔트로피 크레딧 (유일한 크레딧 경로) */

#define POOL_BITS        BLAKE2S_HASH_SIZE * 8   /* 256 */
#define POOL_READY_BITS  POOL_BITS             /* 256 — CRNG_READY 전환 */
#define POOL_EARLY_BITS  POOL_READY_BITS / 2  /* 128 — CRNG_EARLY 전환 */

/* 매크로: CRNG가 이미 준비된 상태면 크레딧 자체를 수행하지 않음
 *   런타임 재시드는 60초 주기 delayed_work (crng_reseed)가 독립 처리 */
#define credit_init_bits(bits) if (!crng_ready()) _credit_init_bits(bits)

static void _credit_init_bits(size_t bits)
{
    unsigned int new, orig, add;

    if (!bits)
        return;                        /* 0비트 credit — 의미 없음 */

    add = min_t(size_t, bits, POOL_BITS);

    /* lock-free 원자적 갱신: try_cmpxchg로 경쟁 없이 init_bits 클램프 누적
     *   spin_lock이 아닌 CAS(Compare-And-Swap) 사용 — 경합 최소화 */
    orig = READ_ONCE(input_pool.init_bits);
    do {
        new = min_t(unsigned int, POOL_BITS, orig + add);
    } while (!try_cmpxchg(&input_pool.init_bits, &orig, new));

    /* 임계치 1: 128비트 도달 — CRNG_EARLY (조기 단계)
     *   input_pool에서 즉시 키를 추출하여 기본 CRNG에 주입
     *   아직 getrandom()은 블록하지만 커널 내부 get_random_bytes() 사용 가능 */
    if (orig < POOL_EARLY_BITS && new >= POOL_EARLY_BITS) {
        if (crng_init == CRNG_EMPTY) {
            extract_entropy(base_crng.key, sizeof(base_crng.key));
            crng_init = CRNG_EARLY;
        }
    }

    /* 임계치 2: 256비트 도달 — CRNG_READY (완전 준비)
     *   crng_reseed()가 input_pool에서 최종 시드 추출 → base_crng.key 갱신
     *   이후 getrandom() 블로킹 해제, 대기 프로세스 웨이크업, vDSO 갱신 */
    if (orig < POOL_READY_BITS && new >= POOL_READY_BITS) {
        crng_reseed(NULL);           /* CRNG 키를 input_pool에서 추출하여 갱신 */
        queue_work(system_dfl_wq, &set_ready);
        wake_up_interruptible(&crng_init_wait);
        pr_notice("crng init done\n");
    }
}

단일 크레딧 함수 — credit_init_bits()만 존재

현대 리눅스 커널(5.18+)에는 credit_entropy_bits() 같은 별도의 런타임 크레딧 함수가 존재하지 않습니다. 모든 엔트로피 소스 — hwrng kthread, 인터럽트 경로, 디바이스/디스크 이벤트, 부트로더 시드 — 가 동일한 credit_init_bits() 매크로 하나를 공통으로 호출합니다.

이 매크로의 핵심 설계는 if (!crng_ready()) 가드입니다. CRNG가 한 번 CRNG_READY 상태에 도달하면, 이후의 모든 credit_init_bits() 호출은 no-op가 됩니다 — 런타임 재시드는 credit_init_bits()가 아니라 60초 주기의 delayed_work 타이머가 독립적으로 crng_reseed()를 호출하여 처리합니다. 이 설계로 인해 크레딧 경로와 재시드 경로가 명확히 분리됩니다.

quality → credit 변환 공식 상세

hwrng 코어는 드라이버의 quality 파라미터(0~1024)와 읽은 바이트 수를 곱하여 credit할 엔트로피 비트 수를 계산합니다. 핵심 변환 공식은 다음과 같습니다.

/* drivers/char/hw_random/core.c — quality → credit 변환 */

/*
 * entropy_bits = bytes_read × quality × 8 / 1024
 *
 * 풀어서 설명:
 *   bytes_read     — hwrng read() 콜백이 반환한 바이트 수
 *   × 8            — 바이트를 비트로 변환 (1바이트 = 8비트)
 *   × quality      — 비트당 엔트로피 밀도 (0~1024 스케일)
 *   / 1024         — quality 스케일 정규화 (1024 = 1.0 비트/비트)
 *
 * 비트당 엔트로피 밀도 = quality / 1024
 *   quality=1024 → 1.0 비트/비트 (이론적 최대, 완벽한 TRNG)
 *   quality=512  → 0.5 비트/비트  (50% 효율)
 *   quality=0    → 0.0 비트/비트  (엔트로피 없음, PRNG 출력)
 */
size_t hwrng_entropy_bits(const struct hwrng *rng, size_t bytes_read)
{
    /* (rc * rng->quality * 8) >> 10
     *   >> 10 은 / 1024 와 동일 (비트 시프트로 정수 연산) */
    return (bytes_read * rng->quality * 8) >> 10;
}

/* hwrng_fillfn()에서의 실제 호출 */
size_t entropy = hwrng_entropy_bits(rng, rc);
add_hwgenerator_randomness(rng_buffer, rc, entropy, true);
/*   내부적으로:
 *     mix_pool_bytes(rng_buffer, rc)          ← 데이터 섞기
 *     credit_init_bits(entropy)               ← 엔트로피 크레딧
 *     wake_up_interruptible(&random_wait)     ← getrandom() 대기자 깨우기 */

소스별 credit 정책 비교

커널은 각 엔트로피 소스에 대해 서로 다른 credit 정책을 적용합니다. 이 정책 차이가 "보수적 크레딧(conservative credit)" 철학의 핵심입니다.

quality → credit 변환 파이프라인

다음 다이어그램은 hwrng 드라이버의 read() 콜백부터 init_bits 누적까지의 전체 파이프라인을 보여줍니다. 각 단계에서 수행되는 연산과 데이터 변환을 추적할 수 있습니다.

보수적 credit 철학과 random.trust_cpu

커널은 RDRAND와 같은 CPU 내장 DRBG 출력에 대해 기본적으로 보수적 credit 정책을 적용합니다. RDRAND는 하드웨어 내부의 DRBG(결정론적 PRNG) 출력이므로, 원시 물리 엔트로피가 아닙니다. 따라서 커널은 RDRAND 출력을 input_pool에 섞되(mix), 단독으로 init_bits 256에 도달할 수 있는 전량 credit는 부여하지 않습니다.

이 정책은 random.trust_cpu 부트 파라미터로 변경할 수 있습니다:

cat /proc/cmdline | grep -o 'random.trust_cpu=[0-9]'
# 출력이 없으면 기본값(0) 적용 중

credit 관측 — ftrace와 /proc

credit 동작은 런타임에 ftrace tracepoint와 /proc/sys/kernel/random/ 인터페이스로 관측할 수 있습니다. 운영 중 credit이 어떤 소스에서 얼만큼 부여되고 있는지 추적하면 엔트로피 기반 보안 진단에 직접 활용할 수 있습니다.

# 1. kprobe: _credit_init_bits 추적 (5.18+에서 tracepoint 제거됨)
#    구버전(5.17 이전)에서는 events/random/credit_entropy_bits tracepoint 사용
cd /sys/kernel/tracing
echo 'p:cred _credit_init_bits bits=%x0:u64' > kprobe_events
echo 1 > events/kprobes/cred/enable
echo 1 > tracing_on

# credit 추적 결과 — 각 소스가 부여한 엔트로피 비트 수 확인
cat trace_pipe | head -30
# 출력 예:
#   hwrng-123    cred: (_credit_init_bits+0x0/0x120) bits=256
#   irq/24-eth0  cred: (_credit_init_bits+0x0/0x120) bits=1
#   kworker-45   cred: (_credit_init_bits+0x0/0x120) bits=12

# 2. /proc: 현재 엔트로피 가용량 확인 (init_bits 기반)
cat /proc/sys/kernel/random/entropy_avail
# 출력 예: 256 (CRNG 초기화 완료, 충분한 엔트로피)
#   0~256 범위 — 256이면 CRNG ready

# 3. bpftrace: 소스별 credit 비트 수 집계
cat > /tmp/credit_trace.bt << 'EOF'
kprobe:_credit_init_bits
{
    @credit_bits = hist(arg0);
    @credit_count = count();
}
EOF
bpftrace /tmp/credit_trace.bt
# Ctrl+C 후 출력:
# @credit_bits:
# [0, 1]       8472 |   인터럽트 (max(1u,...))
# [16, 32)      132 |   jitterentropy
# [128, 256)     15 |   RDSEED
# [256, 512)      3 |   hwrng (quality=1024, 32바이트 읽기)

DRBG vs CRNG vs CSRNG vs CSPRNG 용어 정리

암호학적 난수 생성기 분야에서는 DRBG, CRNG, CSRNG, CSPRNG 네 용어가 혼용되어 사용됩니다. 이 용어들은 대부분 같은 대상을 가리키지만, 정의한 기관, 결정론적(Deterministic) vs 비결정론적(Non-deterministic) 구분, 그리고 "의사(Pseudo)"라는 수식어 포함 여부에 따라 미묘한 차이가 있습니다. 정확한 용어 이해는 표준 문서(NIST SP 800-90, RFC 4086, FIPS 140)를 읽거나 커널 소스에서 RNG 관련 코드를 추적할 때 필수적입니다.

각 용어의 정의

DRBG (Deterministic Random Bit Generator)

DRBG(결정론적 난수 비트 생성기)는 NIST SP 800-90A에서 정의한 표준 용어입니다. "결정론적(Deterministic)"이라는 수식어가 붙은 이유는, 동일한 시드(Seed)를 입력하면 항상 동일한 출력 시퀀스를 생성하기 때문입니다. 즉, DRBG 자체는 내부에 물리적 엔트로피 소스를 가지지 않으며, 외부에서 주입된 엔트로피(시드)를 기반으로 결정론적 알고리즘을 통해 난수 비트 스트림을 확장(extend)합니다. NIST SP 800-90A는 세 가지 승인된 DRBG 메커니즘을 정의합니다:

• Hash-DRBG — SHA-2/SHA-3 해시 함수 기반 (SP 800-90A §10.1.1)
• HMAC-DRBG — HMAC-SHA-2 기반 (SP 800-90A §10.1.2)
• CTR-DRBG — AES-CTR 모드 기반 (SP 800-90A §10.2.1)

Linux 커널의 ChaCha20 CRNG는 NIST 승인 DRBG 중 하나는 아니지만, 구조적으로 DRBG와 동일한 패턴(엔트로피 시드 → 결정론적 확장 → 주기적 재시드)을 따릅니다. 정확히는 NIST SP 800-90A/C/D 전체 프레임워크를 따르지 않고 독자 설계를 유지하지만, 보안 속성(예측 불가능성, 역추적 방지)은 DRBG 요구사항을 만족합니다.

CSPRNG (Cryptographically Secure Pseudo Random Number Generator)

CSPRNG(암호학적으로 안전한 의사난수 생성기)는 학술적으로 가장 널리 사용되는 용어로, "Pseudo(의사)"라는 수식어가 핵심입니다. "의사"라는 말은 출력이 결정론적 알고리즘의 산물임을 명시하며, 진정한 물리적 무작위성이 아니라 알고리즘에 의해 확장된 난수라는 뜻입니다. CSPRNG가 "암호학적으로 안전(Cryptographically Secure)"하려면 다음 두 가지 속성을 만족해야 합니다:

• 다음 비트 예측 불가능성(Next-bit unpredictability) — 지금까지 출력된 비트 시퀀스를 알아도 다음 비트를 1/2 확률 이상으로 예측할 수 없어야 합니다.
• 역추적 불가능성(Backtracking resistance / Forward secrecy) — 현재 내부 상태가 노출되더라도 과거에 생성된 난수를 역산할 수 없어야 합니다.

DRBG는 NIST 표준 관점에서 CSPRNG의 구체적 구현 명세로 볼 수 있습니다. 즉, 모든 DRBG는 CSPRNG의 요구사항을 만족하지만, 모든 CSPRNG가 NIST 승인 DRBG인 것은 아닙니다 (Linux ChaCha20 CRNG가 그 예입니다).

CRNG (Cryptographic Random Number Generator)

CRNG(암호학적 난수 생성기)는 "Pseudo" 수식어가 생략된 용어입니다. 이 생략은 의도적일 수도 있고 단순한 관행일 수도 있습니다:

• 좁은 의미: CSPRNG와 동의어로 사용. "Cryptographic"이 이미 "의사난수 중 암호학적으로 안전한 것"을 함의한다고 보는 관행.
• 넓은 의미: 결정론적 의사난수 생성기뿐 아니라 물리적 TRNG(진난수 생성기)를 포함한 모든 암호학적 난수 생성 장치를 통칭. 이 경우 CSPRNG보다 상위 개념이 됩니다.

Linux 커널 소스에서는 struct crng, crng_reseed(), crng_fast_key_extraction() 등 CRNG라는 명칭을 일관되게 사용합니다. 이는 위 "좁은 의미"에 해당하며, ChaCha20 기반 CSPRNG 구현체를 지칭합니다. 커널 문서(Documentation/crypto/drbg.rst)에서는 NIST DRBG를 별도로 다루고, drivers/char/random.c의 CRNG는 독자 설계로 분류합니다.

CSRNG (Cryptographically Secure Random Number Generator)

CSRNG(암호학적으로 안전한 난수 생성기)는 CSPRNG에서 "Pseudo"를 제거한 형태입니다. "Pseudo"가 없다는 것은 결정론적 의사난수에 국한하지 않고, 비결정론적 TRNG도 포함한다는 의미입니다. 즉, CSRNG는 가장 넓은 의미의 용어로, 다음을 모두 포함합니다:

• 물리적 엔트로피 소스 기반 TRNG (비결정론적)
• TRNG 시드를 받아 결정론적 확장을 수행하는 DRBG/CSPRNG (결정론적)
• TRNG + DRBG 하이브리드 구조 (NIST SP 800-90C에서 정의하는 "Root DRBG + Prediction-Resistant DRBG" 결합 형태)

CSRNG라는 명칭은 FIPS 140-3과 Common Criteria(CC) 인증 문서에서 전체 난수 생성 시스템을 지칭할 때 자주 사용됩니다. 반면 학술 논문이나 일반 프로그래밍 문서에서는 CSPRNG가 더 흔하게 쓰이며, CSRNG는 상대적으로 덜 보편적입니다.

용어 비교 표

개념 계층 구조

네 용어의 포함 관계를 벤다이어그램으로 나타내면 다음과 같습니다. 가장 바깥쪽이 CSRNG(가장 넓은 의미), 가장 안쪽이 DRBG(가장 구체적인 표준 명세)입니다:

Linux 커널에서의 매핑

Linux 커널에서 이 네 용어가 실제 코드에 어떻게 대응되는지 정리합니다:

핵심 요약

• DRBG — NIST SP 800-90A 표준 명세. "결정론적"이라는 수식어가 핵심. 세 가지 승인 메커니즘(Hash, HMAC, CTR)이 있음.
• CSPRNG — 학술적 일반 용어. "Pseudo"가 포함되어 결정론적 의사난수만 지칭. DRBG는 CSPRNG의 NIST 표준화 버전.
• CRNG — "Pseudo"가 생략된 명칭. Linux 커널에서는 ChaCha20 CSPRNG 구현체의 공식 명칭으로 사용. 문맥에 따라 TRNG까지 포함하는 넓은 의미로도 쓰임.
• CSRNG — "Pseudo"가 제거된 가장 넓은 의미. 결정론적 CSPRNG와 비결정론적 TRNG를 모두 포함. FIPS 140-3, Common Criteria 인증 문서에서 전체 시스템을 지칭.
• 포함 관계: DRBG ⊂ CSPRNG ⊂ CSRNG, CRNG ≈ CSPRNG (구현체 명칭) 또는 CRNG ⊂ CSRNG (넓은 의미).
• 실무 팁: 표준 문서를 읽을 때는 DRBG, 일반 기술 문서에서는 CSPRNG, 커널 소스에서는 CRNG라는 명칭을 접하게 됩니다. 세 용어가 동일한 보안 속성을 논의하고 있을 가능성이 높으니, 문맥에서 "어떤 구현체를 가리키는가"를 확인하는 것이 중요합니다.

커널 CSPRNG 내부

Linux 커널은 ChaCha20 기반 CRNG(Cryptographically secure Random Number Generator)를 사용합니다. 커밋 1e7f583903b(v5.17)부터 per-CPU ChaCha20 CRNG로 완전히 전환되었습니다. ChaCha20가 AES-CTR 대신 선택된 이유는 세 가지입니다. 첫째, 순수 소프트웨어 구현으로도 상수 시간(constant-time) 동작이 보장되어 AES-NI 같은 하드웨어 가속 명령어가 없는 ARM 임베디드 환경에서도 타이밍 부채널(Side-Channel)에 안전합니다. 둘째, 20라운드라는 넉넉한 보안 마진(Security Margin)을 가지며, 현재까지 8라운드 ChaCha까지만 공격이 알려져 있습니다. 셋째, SIMD(SSE2, AVX2, NEON) 최적화가 용이하여 대량 난수 생성 시 AES와 동등하거나 더 빠른 성능을 보입니다.

ChaCha20-CRNG 상태 구조

/* include/linux/random.h, drivers/char/random.c */

/* per-CPU CRNG 상태 — 64바이트 (ChaCha20 키 크기) */
struct crng {
    u8 key[CHACHA_KEY_SIZE];  /* 32바이트 키 */
    unsigned long generation;   /* 리시드 세대 번호 */
    local_lock_t lock;           /* per-CPU 경량 락 */
};

/* 전역 초기화 완료 플래그 */
static bool crng_ready = false;  /* 256비트 엔트로피 수집 후 true */
static u64 base_crng_generation; /* 전역 세대 카운터 */

/* CRNG 초기화 — 256비트 엔트로피 누적 시 _credit_init_bits()가 crng_reseed() 호출 */
/* crng_reseed()가 extract_entropy()로 input_pool에서 시드 추출 → base_crng.key 갱신 */

crng_reseed() — 주기적 갱신 메커니즘

/* 약 60초마다 또는 충분한 엔트로피 누적 시 호출 */
static void crng_reseed(struct crng *crng)
{
    u8 key[CHACHA_KEY_SIZE];

    /* input_pool에서 32바이트 추출 (Blake2s 해시 압축) */
    extract_entropy(key, sizeof(key));

    /* 새 키로 교체 (Fast Key Erasure) — 이전 키는 더 이상 사용되지 않아 forward secrecy 보장 */
    memcpy(&crng->key, key, sizeof(key));
    WRITE_ONCE(crng->generation, base_crng_generation);
    memzero_explicit(key, sizeof(key));  /* 스택 잔류 키 소거 */
}

/* 난수 생성 — ChaCha20 state 조립 + 1블록 생성 + Fast Key Erasure */
static void crng_fast_key_erasure(u8 key[CHACHA_KEY_SIZE],
                                    struct chacha_state *chacha_state,
                                    u8 *random_data, size_t random_data_len)
{
    u8 first_block[CHACHA_BLOCK_SIZE];

    /* ChaCha20 state 조립: 상수 + 키 + 카운터(0) + 논스(0) */
    chacha_init_consts(chacha_state);
    memcpy(&chacha_state->x[4], key, CHACHA_KEY_SIZE);
    memset(&chacha_state->x[12], 0, sizeof(u32) * 4);

    /* 1블록 생성 (카운터 0에서 시작) */
    chacha20_block(chacha_state, first_block);

    /* Fast Key Erasure: 출력의 앞 32바이트를 새 키로 사용 */
    /* → 이전 출력으로 키를 역추적 불가 (forward secrecy) */
    memcpy(key, first_block, CHACHA_KEY_SIZE);
    memcpy(random_data, first_block + CHACHA_KEY_SIZE, random_data_len);
    memzero_explicit(first_block, sizeof(first_block));
}

input_pool — Blake2s 압축 함수

/* input_pool: Blake2s 해시 상태 기반 엔트로피 수집 */
struct blake2s_state {
    u32 h[8];   /* 256비트 해시 상태 */
    u32 t[2];   /* 처리된 바이트 카운터 */
    u32 f[2];   /* 최종화 플래그 */
    u8  buf[BLAKE2S_BLOCK_SIZE];  /* 입력 버퍼 (64바이트) */
    size_t buflen;
    u8  outlen;
};

/* 엔트로피 혼합 — Blake2s 압축으로 되돌릴 수 없음 */
static void _mix_pool_bytes(const void *buf, size_t len)
{
    blake2s_update(&input_pool, buf, len);  /* 단방향 해시 업데이트 */
}

/* 엔트로피 추출 — 풀 상태를 변경하며 키 생성 */
static void extract_entropy(void *buf, size_t nbytes)
{
    struct blake2s_state recovery = input_pool;  /* 풀 스냅샷 */
    blake2s_final(&recovery, buf);              /* 최종 해시 출력 */
    blake2s_update(&input_pool, buf, nbytes);   /* 출력을 풀에 재혼합 */
}

hwrng 드라이버 개발

hwrng 서브시스템의 드라이버 API는 단순합니다. struct hwrng 구조체(Struct)를 초기화하고 hwrng_register()를 호출하면 됩니다. 등록이 완료되면 프레임워크가 /dev/hwrng 캐릭터 디바이스 생성, /sys/class/misc/hw_random/ sysfs 엔트리 관리, 그리고 hwrng_fillfn() 커널 스레드를 통한 주기적 엔트로피 풀 공급을 모두 자동으로 처리합니다. 드라이버 개발자는 하드웨어에서 난수 바이트를 읽어오는 read() 콜백(Callback)만 구현하면 되며, 엔트로피 풀 주입, 크레딧 계산, 사용자 공간(User Space) 인터페이스는 코어 프레임워크가 담당합니다.

struct hwrng — 핵심 API

/* include/linux/hw_random.h */

struct hwrng {
    const char   *name;     /* 드라이버 이름 (/sys/class/misc/hw_random/rng_current) */
    int          (*init)(   struct hwrng *rng);           /* 선택사항: 초기화 */
    void         (*cleanup)(struct hwrng *rng);           /* 선택사항: 정리 */
    int          (*data_present)(struct hwrng *rng, int wait);  /* 데이터 준비 여부 */
    int          (*data_read)(  struct hwrng *rng, u32 *data);   /* 구형 API, 4바이트 */
    int          (*read)(       struct hwrng *rng, void *data,   /* 권장 API */
                                size_t max, bool wait);
    unsigned long priv;       /* 드라이버 사용 개인 데이터 */
    unsigned short quality;   /* 엔트로피 품질: 0(최저)~1024(최고) */
                               /* 1024 = 비트당 1.0비트 엔트로피 (물리적 최대) */
    /* 내부 사용 — 드라이버가 초기화 금지 */
    struct list_head list;
    struct kref     ref;
    struct completion cleanup_done;
    struct completion dying;
};

quality 파라미터 가이드

최소 hwrng 드라이버 골격

#include <linux/module.h>
#include <linux/hw_random.h>
#include <linux/platform_device.h>

struct myrng_priv {
    void __iomem *base;  /* MMIO 기주소 */
    struct clk  *clk;
};

/* 필수: 난수 읽기 콜백 */
static int myrng_read(struct hwrng *rng, void *data, size_t max, bool wait)
{
    struct myrng_priv *priv = (struct myrng_priv *)rng->priv;
    size_t read = 0;

    /* HW가 준비될 때까지 폴링 (실제는 인터럽트 권장) */
    while (read + 4 <= max) {
        /* 레지스터에서 FIFO 가득 찼는지 확인 */
        if (!(readl(priv->base + MYRNG_STATUS_REG) & MYRNG_READY_BIT)) {
            if (!wait)
                break;
            cpu_relax();
            continue;
        }
        /* 32비트 난수 읽기 */
        *(u32 *)((u8 *)data + read) = readl(priv->base + MYRNG_DATA_REG);
        read += 4;
    }
    return read;  /* 실제 읽은 바이트 수 반환 */
}

static int myrng_probe(struct platform_device *pdev)
{
    struct myrng_priv *priv;
    struct hwrng *rng;
    struct resource *res;
    int ret;

    priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
    if (!priv)
        return -ENOMEM;

    res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
    priv->base = devm_ioremap_resource(&pdev->dev, res);
    if (IS_ERR(priv->base))
        return PTR_ERR(priv->base);

    rng = devm_kzalloc(&pdev->dev, sizeof(*rng), GFP_KERNEL);
    if (!rng)
        return -ENOMEM;

    rng->name    = "myrng";
    rng->read    = myrng_read;
    rng->quality = 900;   /* 하드웨어 스펙에 따라 조정 */
    rng->priv    = (unsigned long)priv;

    platform_set_drvdata(pdev, priv);
    ret = devm_hwrng_register(&pdev->dev, rng);  /* devm 버전: 해제 자동화 */
    if (ret)
        return dev_err_probe(&pdev->dev, ret, "hwrng_register 실패\n");

    dev_info(&pdev->dev, "myrng 등록 완료 (quality=%u)\n", rng->quality);
    return 0;
}

static const struct of_device_id myrng_of_match[] = {
    { .compatible = "myvendor,myrng" },
    {}
};
MODULE_DEVICE_TABLE(of, myrng_of_match);

static struct platform_driver myrng_driver = {
    .probe  = myrng_probe,
    .driver = {
        .name           = "myrng",
        .of_match_table = myrng_of_match,
    },
};
module_platform_driver(myrng_driver);

MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Example hwrng driver");

외장 hwrng 드라이버 구현

외장 하드웨어 RNG 장치는 USB 또는 PCIe 인터페이스로 연결되어 hwrng 드라이버로 구현되는 경우가 많습니다. 장치 내부의 엔트로피 원천은 열잡음 TRNG, 애벌랜치 노이즈, 링 오실레이터 지터, 양자 광학 소스 등으로 다양하며, 커널 드라이버 관점에서는 모두 struct hwrng의 read() 콜백으로 난수 바이트를 제공하는 장치입니다. USB 방식은 벌크 전송(Bulk Transfer)으로 데이터를 수신하므로 구현이 단순하지만 지연 시간(Latency)이 ms 단위로 높고, 최대 처리량이 USB 대역폭(USB 2.0: ~40 MB/s)에 제한됩니다. 반면 PCIe 방식은 MMIO(Memory-Mapped I/O)를 통한 직접 레지스터(Register) 접근과 MSI(Message Signaled Interrupt)를 활용하여 μs 단위의 낮은 지연과 수 Gbps의 처리량을 달성할 수 있으나, 드라이버 복잡도가 상당히 높아집니다. 일반적으로 USB 외장 RNG는 quality = 600~800, PCIe 전용 RNG는 quality = 900~1024 범위를 설정할 수 있지만, 최종 값은 반드시 데이터시트와 NIST SP 800-90B 같은 엔트로피 평가 결과를 기준으로 정해야 합니다.

USB hwrng 드라이버 완전 예제

아래 코드는 USB 벌크 엔드포인트로 난수 블록을 제공하는 외장 하드웨어 RNG 장치의 드라이버 구조를 보여주는 예시입니다. 실제 상용 장치는 벤더별 프로토콜과 인증 절차가 다르므로 데이터시트에 맞게 엔드포인트, 명령, 헬스 테스트를 구현해야 합니다.

#include <linux/module.h>
#include <linux/usb.h>
#include <linux/hw_random.h>
#include <linux/slab.h>
#include <linux/completion.h>

#define USB_RNG_VENDOR_ID    0x1d50   /* 가상의 벤더 ID */
#define USB_RNG_PRODUCT_ID   0x6021
#define USB_RNG_BULK_IN_EP   0x81    /* Bulk IN 엔드포인트 */
#define USB_RNG_BUFFER_SIZE  4096   /* 한 번에 읽는 원시 난수 버퍼 크기 */
#define USB_RNG_QUALITY      900    /* 엔트로피 평가 결과에 따라 조정 */

struct usb_rng_dev {
    struct usb_device  *udev;
    struct usb_interface *interface;
    struct hwrng        hwrng;

    /* 비동기 Bulk 전송용 */
    struct urb         *urb;
    u8                  *buf;        /* DMA 가능 버퍼 */
    dma_addr_t          buf_dma;
    size_t              buf_len;     /* 사용 가능한 바이트 수 */
    size_t              buf_off;     /* 현재 읽기 오프셋 */
    struct mutex        lock;
    struct completion   urb_done;
    bool                disconnecting;
};

/* URB 완료 콜백 — 인터럽트 컨텍스트에서 호출됨 */
static void usb_rng_urb_complete(struct urb *urb)
{
    struct usb_rng_dev *qdev = urb->context;

    if (urb->status == 0) {
        qdev->buf_len = urb->actual_length;
        qdev->buf_off = 0;
    } else if (urb->status == -ENOENT || urb->status == -ECONNRESET ||
               urb->status == -ESHUTDOWN) {
        qdev->buf_len = 0;  /* 연결 해제 시 정상 종료 */
    }
    complete(&qdev->urb_done);
}

/* hwrng read 콜백 — 슬립 가능 컨텍스트 */
static int usb_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
{
    struct usb_rng_dev *qdev = container_of(rng, struct usb_rng_dev, hwrng);
    size_t available, to_copy;
    int ret;

    mutex_lock(&qdev->lock);

    /* 버퍼에 데이터가 없으면 USB 전송 시작 */
    if (qdev->buf_off >= qdev->buf_len) {
        if (!wait) {
            mutex_unlock(&qdev->lock);
            return 0;
        }

        reinit_completion(&qdev->urb_done);
        usb_fill_bulk_urb(qdev->urb, qdev->udev,
                          usb_rcvbulkpipe(qdev->udev, USB_RNG_BULK_IN_EP),
                          qdev->buf, USB_RNG_BUFFER_SIZE,
                          usb_rng_urb_complete, qdev);
        qdev->urb->transfer_dma = qdev->buf_dma;
        qdev->urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;

        ret = usb_submit_urb(qdev->urb, GFP_KERNEL);
        if (ret) {
            mutex_unlock(&qdev->lock);
            return ret;
        }

        mutex_unlock(&qdev->lock);
        wait_for_completion(&qdev->urb_done);  /* USB 전송 완료 대기 */
        mutex_lock(&qdev->lock);

        if (qdev->buf_len == 0) {
            mutex_unlock(&qdev->lock);
            return -EIO;
        }
    }

    /* 버퍼에서 요청량만큼 복사 */
    available = qdev->buf_len - qdev->buf_off;
    to_copy   = min(available, max);
    memcpy(data, qdev->buf + qdev->buf_off, to_copy);
    qdev->buf_off += to_copy;

    mutex_unlock(&qdev->lock);
    return to_copy;
}

static int usb_rng_probe(struct usb_interface *interface,
                       const struct usb_device_id *id)
{
    struct usb_rng_dev *qdev;
    int ret;

    qdev = kzalloc(sizeof(*qdev), GFP_KERNEL);
    if (!qdev)
        return -ENOMEM;

    qdev->udev      = interface_to_usbdev(interface);
    qdev->interface = interface;
    mutex_init(&qdev->lock);
    init_completion(&qdev->urb_done);

    qdev->urb = usb_alloc_urb(0, GFP_KERNEL);
    if (!qdev->urb) {
        ret = -ENOMEM;
        goto err_free;
    }

    /* DMA 가능 버퍼 할당 */
    qdev->buf = usb_alloc_coherent(qdev->udev, USB_RNG_BUFFER_SIZE,
                                    GFP_KERNEL, &qdev->buf_dma);
    if (!qdev->buf) {
        ret = -ENOMEM;
        goto err_free_urb;
    }

    /* hwrng 등록 */
    qdev->hwrng.name    = "usb-hwrng";
    qdev->hwrng.read    = usb_rng_read;
    qdev->hwrng.quality = USB_RNG_QUALITY;

    usb_set_intfdata(interface, qdev);
    ret = hwrng_register(&qdev->hwrng);
    if (ret) {
        dev_err(&interface->dev, "hwrng 등록 실패: %d\n", ret);
        goto err_free_buf;
    }

    dev_info(&interface->dev, "USB hwrng 연결됨 (quality=%u)\n", USB_RNG_QUALITY);
    return 0;

err_free_buf:
    usb_free_coherent(qdev->udev, USB_RNG_BUFFER_SIZE, qdev->buf,
                       qdev->buf_dma);
err_free_urb:
    usb_free_urb(qdev->urb);
err_free:
    kfree(qdev);
    return ret;
}

static void usb_rng_disconnect(struct usb_interface *interface)
{
    struct usb_rng_dev *qdev = usb_get_intfdata(interface);

    qdev->disconnecting = true;
    hwrng_unregister(&qdev->hwrng);       /* read() 완료 후 반환 보장 */
    usb_kill_urb(qdev->urb);              /* 진행 중인 URB 취소 */
    usb_free_urb(qdev->urb);
    usb_free_coherent(qdev->udev, USB_RNG_BUFFER_SIZE, qdev->buf,
                       qdev->buf_dma);
    kfree(qdev);
    dev_info(&interface->dev, "USB hwrng 분리됨\n");
}

static const struct usb_device_id usb_rng_id_table[] = {
    { USB_DEVICE(USB_RNG_VENDOR_ID, USB_RNG_PRODUCT_ID) },
    {}
};
MODULE_DEVICE_TABLE(usb, usb_rng_id_table);

static struct usb_driver usb_rng_driver = {
    .name       = "usb-hwrng",
    .probe      = usb_rng_probe,
    .disconnect = usb_rng_disconnect,
    .id_table   = usb_rng_id_table,
};
module_usb_driver(usb_rng_driver);

MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("USB hwrng driver");
MODULE_AUTHOR("Example Author");

메인라인 hwrng/TRNG 드라이버 예시

아래 항목은 Linux 메인라인 커널에서 확인할 수 있는 hwrng/TRNG 계열 드라이버 예시입니다. 상용 QRNG 전용 드라이버 목록이 아니며, 대부분 SoC 내장 TRNG, CPU RNG 명령, TPM, 가상 RNG 인터페이스입니다.

PCIe hwrng 드라이버

PCIe 기반 전용 RNG는 USB보다 높은 처리율과 낮은 지연을 제공합니다. MMIO(Memory-Mapped I/O) BAR를 통해 직접 하드웨어 레지스터에 접근하고, MSI(Message Signaled Interrupt) 인터럽트로 데이터 준비를 통지받습니다.

#include <linux/module.h>
#include <linux/pci.h>
#include <linux/hw_random.h>
#include <linux/interrupt.h>
#include <linux/wait.h>

#define PCIE_RNG_VENDOR    0x1234
#define PCIE_RNG_DEVICE    0xABCD
#define RNG_REG_STATUS     0x00   /* 상태 레지스터 */
#define RNG_REG_DATA       0x04   /* 난수 데이터 레지스터 (32비트) */
#define RNG_REG_FIFO_COUNT 0x08   /* FIFO 내 사용 가능 워드 수 */
#define RNG_STATUS_READY   BIT(0) /* FIFO에 데이터 있음 */
#define PCIE_RNG_QUALITY   900   /* 엔트로피 평가 결과에 따라 조정 */

struct pcie_rng_dev {
    void __iomem        *mmio_base;   /* BAR0 MMIO 기주소 */
    struct hwrng         hwrng;        /* hwrng 서브시스템 핸들 */
    struct pci_dev      *pdev;
    wait_queue_head_t    wait_q;       /* 인터럽트 대기 큐 */
    atomic_t             data_ready;   /* MSI 수신 플래그 */
};

/* MSI 인터럽트 핸들러 — 하드웨어가 FIFO에 데이터 채웠을 때 호출 */
static irqreturn_t pcie_rng_irq(int irq, void *dev_id)
{
    struct pcie_rng_dev *qdev = dev_id;
    u32 status = readl(qdev->mmio_base + RNG_REG_STATUS);

    if (!(status & RNG_STATUS_READY))
        return IRQ_NONE;

    atomic_set(&qdev->data_ready, 1);
    wake_up_interruptible(&qdev->wait_q);  /* read()에서 대기 중인 스레드 깨움 */
    return IRQ_HANDLED;
}

/* hwrng read 콜백 — MMIO BAR 직접 읽기 + MSI 인터럽트 대기 */
static int pcie_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
{
    struct pcie_rng_dev *qdev = container_of(rng, struct pcie_rng_dev, hwrng);
    size_t bytes = 0;
    u32 *out = data;
    int ret;

    while (bytes + sizeof(u32) <= max) {
        /* FIFO에 데이터가 없으면 MSI 인터럽트 대기 */
        if (!atomic_read(&qdev->data_ready)) {
            if (!wait)
                break;
            ret = wait_event_interruptible(qdev->wait_q,
                          atomic_read(&qdev->data_ready));
            if (ret)
                return bytes ? (int)bytes : -EINTR;
        }
        /* FIFO에서 32비트 읽기 */
        *out++ = readl(qdev->mmio_base + RNG_REG_DATA);
        bytes += sizeof(u32);
        if (readl(qdev->mmio_base + RNG_REG_FIFO_COUNT) == 0)
            atomic_set(&qdev->data_ready, 0);
    }
    return (int)bytes;
}

static int pcie_rng_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
    struct pcie_rng_dev *qdev;
    int ret;

    qdev = devm_kzalloc(&pdev->dev, sizeof(*qdev), GFP_KERNEL);
    if (!qdev)
        return -ENOMEM;

    init_waitqueue_head(&qdev->wait_q);
    atomic_set(&qdev->data_ready, 0);
    qdev->pdev = pdev;

    /* PCIe 활성화 + DMA 마스크 설정 */
    ret = pcim_enable_device(pdev);
    if (ret)
        return dev_err_probe(&pdev->dev, ret, "PCIe 활성화 실패\n");

    ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
    if (ret)
        return dev_err_probe(&pdev->dev, ret, "DMA 마스크 설정 실패\n");

    /* BAR0 MMIO 매핑 (devm: 언로드 시 자동 해제) */
    qdev->mmio_base = pcim_iomap(pdev, 0, 0);
    if (IS_ERR(qdev->mmio_base))
        return PTR_ERR(qdev->mmio_base);

    /* MSI 인터럽트 1개 할당 */
    ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSI);
    if (ret < 0)
        return dev_err_probe(&pdev->dev, ret, "MSI 할당 실패\n");

    ret = devm_request_irq(&pdev->dev, pci_irq_vector(pdev, 0),
                            pcie_rng_irq, 0, "pcie-hwrng", qdev);
    if (ret)
        return dev_err_probe(&pdev->dev, ret, "IRQ 등록 실패\n");

    /* hwrng 등록 */
    qdev->hwrng.name    = "pcie-hwrng";
    qdev->hwrng.read    = pcie_rng_read;
    qdev->hwrng.quality = PCIE_RNG_QUALITY;

    pci_set_drvdata(pdev, qdev);
    ret = devm_hwrng_register(&pdev->dev, &qdev->hwrng);
    if (ret)
        return dev_err_probe(&pdev->dev, ret, "hwrng 등록 실패\n");

    dev_info(&pdev->dev, "PCIe hwrng 등록 완료 (quality=%u)\n", PCIE_RNG_QUALITY);
    return 0;
}

static const struct pci_device_id pcie_rng_ids[] = {
    { PCI_DEVICE(PCIE_RNG_VENDOR, PCIE_RNG_DEVICE) },
    {}
};
MODULE_DEVICE_TABLE(pci, pcie_rng_ids);

static struct pci_driver pcie_rng_driver = {
    .name     = "pcie-hwrng",
    .id_table = pcie_rng_ids,
    .probe    = pcie_rng_probe,
};
module_pci_driver(pcie_rng_driver);

MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("PCIe hwrng driver with MSI interrupt");

NIST SP 800-90B 인증

NIST SP 800-90B(Recommendation for the Entropy Sources Used for Random Bit Generation)는 2018년 1월 발행된 미국 표준으로, 난수 생성기(RBG)가 사용하는 엔트로피 소스(Entropy Source)의 설계 원칙과 검증 요구사항을 정의합니다. 핵심 지표는 min-entropy(H_∞)이며, 이는 가장 발생 확률이 높은 출력값의 확률 pmax로부터 계산되는 가장 보수적인 엔트로피 측정값입니다. 커널 hwrng의 quality 파라미터는 이 표준의 min-entropy 측정값에서 직접 유도되며, FIPS 140-3 인증을 위한 필수 요건이기도 합니다.

SP 800-90B 핵심 개념 쉬운 가이드

아래는 SP 800-90B의 핵심 개념들을 전문 용어 없이 설명한 내용입니다. 기술적 세부 사항은 뒤에 이어지는 각 섹션에서 다룹니다.

엔트로피(Entropy) — "얼마나 예측하기 어려운가?"

엔트로피는 "이 난수 생성기가 만든 숫자를 공격자가 얼마나 예측하기 어려운가"를 나타내는 점수입니다. 점수가 높을수록 예측이 어렵고, 점수가 낮을수록 쉽습니다.

• 8비트 난수(0~255 중 하나)의 경우: 완벽하게 무작위면 엔트로피 = 8.0 (만점). 항상 같은 숫자만 나오면 엔트로피 = 0
• quality 점수: 엔트로피를 0~1024 점수로 변환한 것. 1024 = 만점(완벽한 난수), 0 = 난수 아님
• 왜 "min-entropy"를 쓰는가?: 평균적인 예측 어려움이 아니라 "가장 쉽게 예측할 수 있는 경우"를 기준으로 삼습니다. 보안에서는 최악의 경우를 대비해야 하므로, 평균(Shannon entropy)이 아니라 최악(min-entropy)을 사용합니다

IID vs Non-IID — "매번 새 주사위인가, 같은 주사위인가?"

IID(Independent and Identically Distributed)는 "매번 던질 때마다 완전히 독립적이고 동일한 분포"라는 뜻입니다. 쉽게 말해 "매번 새로운 공정한 주사위를 던지는 것"과 같습니다.

• IID 검정 통과: 주사위가 완벽하게 공정하고 이전 결과에 영향을 받지 않음. 하지만 현실의 하드웨어는 거의 통과하지 못함
• Non-IID 검정: 주사위에 약간의 편향이나 이전 결과의 영향이 있을 수 있다고 가정. 대부분의 하드웨어 RNG는 이 검사를 사용
• Non-IID가 더 보수적(더 낮은 점수)이지만, 모든 소스에 안전하게 적용 가능

10가지 추정기 — "주사위의 어떤 문제를 찾는가?"

Non-IID 검사에서는 10가지 다른 방법으로 주사위의 예측 불가능성을 측정합니다. 각 방법이 찾는 문제가 다릅니다. 10가지 중 가장 낮은 점수가 최종 점수가 됩니다 — 가장 엄격한 기준을 적용하는 것입니다.

재시작 테스트 — "다시 켤 때마다 다른가?"

컴퓨터를 껐다 켤 때 하드웨어 난수 생성기가 매번 다른 초기 상태에서 시작하는지 확인합니다. 만약 부팅할 때마다 항상 비슷한 난수가 나온다면, 공격자가 "이 기기는 부팅 후 항상 이런 난수를 만든다"고 예측할 수 있어 치명적입니다.

컨디셔닝 — "품질 개선 공정"

하드웨어 난수 생성기의 원시 출력에는 약간의 편향이 있을 수 있습니다. 예를 들어 0이 1보다 약간 더 자주 나올 수 있습니다. 컨디셔닝은 이 편향을 제거하고 난수 품질을 높이는 후처리 단계입니다.

헬스 테스트 — "실시간 건강 검진"

난수 생성기가 동작 중에 고장 나는 것을 실시간으로 감지합니다. 두 가지 필수 검사가 있습니다:

• RCT (반복 카운트 검정): "같은 숫자가 너무 많이 연속으로 나오지 않는가?" — 주사위가 고장 나서 한 면에 고착되었는지 즉시 감지
• APT (적응형 비율 검정): "특정 숫자가 전체적으로 너무 자주 나오지 않는가?" — 주사위가 서서히 마모되어 편향이 커지는 것을 감지

SP 800-90 시리즈 3부작

NIST SP 800-90 시리즈는 난수 생성 체계를 세 계층으로 분리하여 각각의 표준 문서로 정의합니다. 이 3부작 구조는 리눅스 커널 drivers/char/random.c의 난수 서브시스템 설계와 직접 대응됩니다.

데이터 흐름은 90B 엔트로피 소스 → 90A DRBG → 90C RBG 구성 순서입니다. 90B가 원시 엔트로피의 품질을 보증하고, 90A가 그 엔트로피를 시드로 받아 결정론적으로 확장하며, 90C가 이 둘을 조합하는 안전한 구성 패턴을 규정합니다. 90C는 2024년 8월 최종 확정될 때까지 커널은 사실상 90A+90B 조합으로 90C 요건을 선제 충족해 왔습니다.

엔트로피 소스 모델

SP 800-90B는 모든 엔트로피 소스를 4단계 파이프라인으로 모델링합니다. 이 모델은 hwrng 드라이버 설계와 1:1로 대응되며, 각 단계의 출력이 검증 대상이 됩니다.

검증용 데이터 샘플 유형

SP 800-90B 검증은 세 종류의 데이터 샘플을 요구합니다. 각 샘플은 최소 1,000,000개의 연속된 표본값을 포함해야 하며, 샘플 수집 방법이 검증 결과의 유효성을 결정합니다.

min-entropy와 quality 파라미터 연관성

/* NIST SP 800-90B — min-entropy H_min 계산 및 quality 변환 */

/* 1단계: 가장 자주 나타나는 심볼의 확률 p_max 측정 */
/*        테스트 데이터 1,000,000비트에서 각 바이트값 출현 빈도 집계 */
double p_max = max_count / total_samples;  /* 이상적 8비트 표본: p_max ≈ 1/256 */

/* 2단계: min-entropy 계산 (비트 단위) */
double H_min = -log2(p_max);              /* 이상적: -log2(1/256) = 8.0 비트/바이트 */

/* 3단계: 비트당 min-entropy */
double H_min_per_bit = H_min / 8.0;       /* 이상적: 1.0 비트/비트 */

/* 4단계: hwrng quality 값으로 변환 (0~1024 스케일) */
unsigned short quality = (unsigned short)(H_min_per_bit * 1024);
/* 예시:
 *   H_min_per_bit = 1.000 → quality = 1024  (이론적 최대)
 *   H_min_per_bit = 0.990 → quality = 1014  (검증된 고품질 TRNG)
 *   H_min_per_bit = 0.875 → quality =  896  (Intel RDRAND 실측치)
 *   H_min_per_bit = 0.500 → quality =  512  (FPGA 링 오실레이터)
 *   H_min_per_bit = 0.000 → quality =    0  (PRNG, 엔트로피 없음) */

NIST SP 800-90B 검증 6단계

IID vs Non-IID 검증 경로

SP 800-90B는 엔트로피 소스의 통계적 특성에 따라 두 가지 검증 경로를 제공합니다. 경로 선택은 IID(Independent and Identically Distributed, 독립 동일 분포) 가설 검정으로 결정되며, 대부분의 실제 하드웨어 엔트로피 소스는 non-IID 경로를 따릅니다.

IID 경로를 선택하려면 ea_iid 도구의 순열 검정 19종(§5.1), 카이제곱 2종(§5.2.1-5.2.4), LRS 1종(§5.2.5) — 총 22종 검정이 모두 IID 가설을 기각하지 않아야 합니다. 하나라도 기각되면 non-IID 경로로 전환해야 합니다. CMVP Implementation Guidance 7.18(IG 7.18)은 IID 주장에 대해 추가 통계적 근거를 요구하므로, 대부분의 엔트로피 소스는 IID가 아니며, 실제 검증에서는 대부분 non-IID 경로가 채택됩니다.

Non-IID 10가지 추정기

Non-IID 경로에서는 10가지 추정기가 각각 독립적으로 min-entropy를 추정하고, 그중 가장 보수적인(가장 낮은) 값이 해당 엔트로피 소스의 H_I로 채택됩니다. 이 다중 추정기 접근은 단일 추정기가 놓칠 수 있는 다양한 형태의 구조적 편향을 포착합니다.

추정기 1-6은 통계적 분석 기반이며, 7-10은 예측(Prediction) 기반입니다. 예측 추정기는 이전 샘플들로 다음 샘플을 예측하는 정확도로 엔트로피를 추정합니다 — 예측이 잘 맞을수록 엔트로피가 낮다는 의미입니다. 바이너리 전용 추정기(2-4)는 비트스트링(bitstring) 모드에서만 실행되며, 다비트 심볼(8비트 등)에서는 추정기 1, 5-10만 적용됩니다.

통계적 분석 기반 추정기 (1~6)

통계적 분석 기반 추정기는 데이터의 빈도 분포, 패턴 반복, 압축 가능성 등 관측된 통계량으로부터 min-entropy를 직접 산출합니다. 데이터의 구조를 수학적 모델로 기술하고, 그 모델 하에서 최악의 경우(가장 높은 확률)를 상한으로 삼습니다.

1. Most Common Value (MCV) — §6.3.1: 모든 경로(IID/non-IID)에서 항상 계산되는 기본 추정기입니다. 데이터에서 가장 빈번한 값의 출현 비율 p_max를 구하고, 99.5% 신뢰구간 상한 보정을 적용합니다. p' = p_max + 2.576·√(p_max(1−p_max)/(n−1)), H = −log₂(p'). 완벽한 균등분포(8비트 256값)에서 p_max ≈ 1/256, H ≈ 8.0. 한 값이 지배적이면 p_max → 1.0, H → 0. 신뢰구간 보정으로 표본 크기 유한성을 보수적으로 반영하여 이론적 최댓값보다 약간 낮은 값(예: 7.999 대신 7.998)이 산출되는 것이 정상입니다. 수치 범위: H ∈ [0, 8] (8비트 심볼).

2. Collision Estimate — §6.3.2 (바이너리 전용): Hagerty와 Draper가 제안한 방법으로, 충돌(동일값 재등장)까지의 평균 간격으로 엔트로피를 추정합니다. 충돌 시간 t_i의 표본평균 X̄와 표준편차 σ̂를 구하고, 99% 신뢰하한 X̄' = X̄ − 2.576·σ̂/√v를 산출한 후, 이진 탐색으로 가장 가능성 높은 p를 해석하여 H = −log₂(p)를 산출합니다. 충돌이 드물면(간격이 길면) 엔트로피가 높고, 빈번하면 낮습니다. 수치 범위: H ∈ [0, 1] (비트당, 비트스트링 모드).

3. Markov Estimate — §6.3.3 (바이너리 전용): 2상태 마르코프 체인으로 인접 비트 간 1차 의존성을 모델링합니다. 4개 전이 확률 P(0→0), P(0→1), P(1→0), P(1→1)을 추정하고, 각 상태에서의 조건부 엔트로피에 보정항을 적용합니다. P(0→0)이 0.5에 가까우면 독립적, 1.0에 가까우면 0에 고착, 0.0에 가까우면 강제 교대 패턴을 의미합니다. 수치 범위: H ∈ [0, 1] (비트당). 1차 의존성만 모델링하므로 고차 의존성은 MultiMMC(#9)에서 처리합니다.

4. Compression Estimate — §6.3.4 (바이너리 전용): LZ76 압축 알고리즘의 통계량을 활용합니다. 데이터를 순차적으로 읽으며 "이전에 본 적이 없는" 최소 길이 구문(phrase)으로 분할하고, 평균 구문 길이로부터 H = log₂(n)/avg_word_length + 보정항으로 산출합니다. 구문이 짧을수록(많을수록) 반복적이고 압축 가능 = 낮은 엔트로피. 수치 범위: H ∈ [0, 1] (비트당).

5. t-Tuple Estimate — §6.3.5: 각 튜플 길이 t = 1, 2, 3, ...에 대해 데이터에서 가장 빈번한 t-튜플의 빈도 p_max(t)를 측정하고, 신뢰구간 보정 후 H(t) = −log₂(p'(t))/t를 계산합니다. 모든 t에 대해 최솟값을 채택합니다. t = 1은 MCV와 동일하며, t가 증가할수록 더 긴 패턴의 반복을 탐지합니다. 수치 범위: H ∈ [0, 8] (8비트 심볼).

6. Longest Repeated Substring (LRS) — §6.3.6: 데이터에서 2회 이상 출현하는 가장 긴 부분문자열의 길이 W를 접미 배열(suffix array)과 LCP 배열로 O(n log n)에 계산합니다 (libdivsufsort 의존). 무작위 데이터에서 이론적 W ≈ 2·log_k(n)이며, 8비트 심볼 1,000,000샘플에서 W ≈ 4~5가 예상치입니다. W가 이보다 크면 구조적 패턴이 존재 = 비-IID. 수치 범위: H ∈ [0, 8] (8비트 심볼).

예측 기반 추정기 (7~10)

예측 기반 추정기는 이전 샘플들로 다음 샘플을 예측하는 정확도(적중률)로 엔트로피를 추정합니다. 예측 적중률 p가 높을수록 H = −log₂(p)가 낮아집니다 — 즉, "미래를 예측할 수 있다"는 것은 "엔트로피가 낮다"는 의미입니다. 각 추정기는 서로 다른 예측 전략을 사용하여 다양한 형태의 구조적 의존성을 포착합니다.

7. MultiMCW Prediction — §6.3.7: 4개 윈도우 크기(W = 63, 255, 1023, 4095)에서 각각 최근 윈도우 내의 최빈값(Most Common Value)으로 다음 샘플을 예측합니다. 단기(63샘플)부터 장기(4095샘플)까지 다양한 시간 스케일의 예측 가능성을 탐지합니다. 4개 윈도우 중 가장 보수적인(가장 낮은) 추정값을 채택합니다. 수치 범위: H ∈ [0, 8] (8비트 심볼). 적중률 1/256(무작위)이면 H ≈ 8.0, 적중률 1.0(완벽 예측)이면 H = 0.

8. Lag Prediction — §6.3.8: 특정 lag d ∈ [1, 128] 이전의 샘플 값으로 현재 샘플을 예측합니다. 128개 lag 중 가장 보수적인 추정값을 채택합니다. 주기적/순환 패턴을 탐지하는 데 특화되어 있습니다 — 예를 들어 매 10번째 샘플이 항상 같은 값이면 lag = 10에서 적중률이 높게 나타납니다. 수치 범위: H ∈ [0, 8] (8비트 심볼).

9. MultiMMC Prediction — §6.3.9: 차수 d ∈ {16, 64, 256}의 마르코프 모델(Multi-Step Markov Model with Correction)을 구축합니다. 이전 d개 샘플의 패턴(문맥)으로 다음 샘플을 예측합니다. Markov Estimate(#3)가 1차(인접 비트 간)만 모델링하는 반면, MultiMMC는 고차 의존성을 탐지합니다. 차수가 높을수록 더 긴 패턴의 의존성을 탐지할 수 있지만, 가능한 상태 수가 k^d로 기하급수적으로 늘어 통계적 신뢰도가 낮아집니다. 3개 차수 중 최솟값을 채택합니다. 수치 범위: H ∈ [0, 8] (8비트 심볼).

10. LZ78Y Prediction — §6.3.10: LZ78 압축 알고리즘의 사전 구축 방식을 예측에 응용합니다(Y 변형). 관찰된 패턴으로 사전(최대 2¹⁶ = 65,536 항목)을 구축하고, 현재 위치에서 가장 길게 매칭되는 사전 패턴의 다음 값으로 예측합니다. 압축 가능한 데이터(반복 패턴)는 사전 기반 예측이 잘 되므로 엔트로피가 낮게 추정됩니다. 수치 범위: H ∈ [0, 8] (8비트 심볼).

보정 항과 신뢰구간

모든 추정기는 표본 크기가 유한할 때의 통계적 불확실성을 반영하기 위해 보정 항(correction term)을 적용합니다. 이는 추정값이 우연히 높게 산출되는 것을 방지하는 보수적 장치입니다.

# ea_non_iid 실행 시 10가지 추정기별 결과 출력
./ea_non_iid -i -v hwrng_sample.bin 8
# -i: unconditioned, -v: 상세 출력, 8 = bits_per_symbol

# 출력 예 (8비트 심볼, 바이너리 전용 추정기는 bitstring 모드에서 별도 실행):
# Most Common Value Estimate: H = 7.998417
# Collision Test Estimate: H = 7.995622 (bitstring only)
# Markov Test Estimate: H = 7.973311 (bitstring only)
# Compression Test Estimate: H = 7.989123 (bitstring only)
# t-Tuple Test Estimate: H = 7.991234
# LRS Test Estimate: H = 7.994567
# MultiMCW Prediction Estimate: H = 7.987654
# Lag Prediction Test Estimate: H = 7.992345
# MultiMMC Prediction Test Estimate: H = 7.988901
# LZ78Y Prediction Test Estimate: H = 7.990123
# ────────────────────────────────────────
# H_min = 7.973311  ← 10가지 중 최솟값이 최종 H_I

# 출력 해석:
# 1. H_I = 7.973311 bits per symbol (Markov 추정기가 가장 보수적)
# 2. H' = 7.973311 / 8 = 0.9967 bits per bit (min-entropy per bit)
# 3. quality = floor(0.9967 × 1024) = 1020 (커널 hwrng quality 파라미터)
# 4. Markov가 최소 → 인접 비트 간 1차 의존성이 가장 큰 엔트로피 감소 원인
# 5. 개선 방향: 컨디셔닝(SHA-256 등)으로 비트 간 의존성 제거 → Markov H 향상

# 비트스트링 모드 추가 실행 (바이너리 전용 추정기 포함 10종 전체):
./ea_non_iid -c -t hwrng_sample.bin 1
# -c: conditioned/bitstring, -t: 첫 1,000,000비트로 제한, 1 = 바이너리
# H_bitstring = min(10종) — H ∈ [0, 1] bits per bit
# 최종 H_I = min(8 × H_bitstring, H_symbol)

헬스 테스트 (Health Tests)

SP 800-90B는 노이즈 소스가 정상 동작하는지 상시 감시하기 위해 두 가지 필수 헬스 테스트를 규정합니다. 이 테스트는 컨디셔닝 전의 원시 출력에 적용되며, 시작 시(Start-up), 연속(Continuous), 요청 시(On-demand) 세 가지 시점에서 수행됩니다. 헬스 테스트 실패 시 엔트로피 소스는 즉시 비활성화되어야 합니다.

반복 카운트 검정 (Repetition Count Test, RCT)

RCT는 노이즈 소스가 단일 값에 "고착(stuck)"되는 치명적 고장을 즉시 감지합니다. 연속으로 동일한 값이 나타나는 횟수가 임계값을 초과하면 알람을 발생시킵니다. 임계값 C는 표준 §4.4.1의 공식 C = 1 + ⌈(−log₂ α) / H⌉로 계산됩니다. 여기서 α는 허용 오경보율(일반적으로 2⁻²⁰), H는 평가된 min-entropy입니다. 예: α = 2⁻²⁰, H = 2.0 → C = 1 + ⌈20/2.0⌉ = 11.

/* SP 800-90B §4.4.1 — Repetition Count Test 구현 */
/* C = 1 + ceil(-log2(alpha) / H), alpha = 2^-20 (일반적 오경보율) */

static int sp800_90b_rct(uint8_t *samples, size_t n,
                       double h_target, bool *alarm)
{
    double alpha = pow(2.0, -20.0);  /* 오경보율 */
    int c = 1 + (int)ceil(-log2(alpha) / h_target);  /* 임계값 */
    int repetition_count = 1;
    uint8_t prev = samples[0];

    for (size_t i = 1; i < n; i++) {
        if (samples[i] == prev) {
            repetition_count++;
            if (repetition_count >= c) {
                *alarm = true;  /* 고착 고장 감지 */
                return -EIO;
            }
        } else {
            repetition_count = 1;  /* 다른 값 → 카운터 리셋 */
            prev = samples[i];
        }
    }
    *alarm = false;
    return 0;
}

적응형 비율 검정 (Adaptive Proportion Test, APT)

APT는 환경 변화나 하드웨어 노화로 인한 점진적 엔트로피 손실을 감지합니다. 고정 크기 윈도우(바이너리: 1,024, 비-바이너리: 512) 내에서 특정 값의 출현 빈도가 임계값을 초과하면 알람을 발생시킵니다. RCT가 급성 고장을 감지한다면, APT는 만성 엔트로피 저하를 감지합니다.

/* SP 800-90B §4.4.2 — Adaptive Proportion Test 구현 */
/* 윈도우 크기: 바이너리 W=1024, 비-바이너리 W=512 */

#define APT_WINDOW_BINARY  1024
#define APT_WINDOW_NONBINARY 512

static int sp800_90b_apt(uint8_t *samples, size_t n,
                        double h_target, bool binary, bool *alarm)
{
    int window = binary ? APT_WINDOW_BINARY : APT_WINDOW_NONBINARY;
    double alpha = pow(2.0, -h_target);

    /* upper bound: 바이너리 = W * (p + α), 비-바이너리 = W * (p_max + α) */
    int bound = (int)(window * (pow(2.0, -h_target) + alpha));

    for (size_t start = 0; start + window <= n; start++) {
        uint8_t target = samples[start];  /* 윈도우 첫 값이 타겟 */
        int count = 0;

        for (int i = 0; i < window; i++) {
            if (samples[start + i] == target)
                count++;
        }

        if (count > bound) {
            *alarm = true;  /* 엔트로피 손실 감지 */
            return -EIO;
        }
    }
    *alarm = false;
    return 0;
}

재시작 테스트 (Restart Test) 상세

재시작 테스트는 엔트로피 소스의 초기 조건 의존성을 검증합니다. 전원 인가 시 항상 동일한 내부 상태에서 시작한다면, 첫 출력이 예측 가능할 수 있습니다. SP 800-90B는 1,000회 재시작으로 이 위험을 정량화합니다.

데이터 수집 절차:

1. 엔트로피 소스를 1,000회 재시작 (전원 차단/복구 또는 리셋)
2. 각 재시작마다 1,000개의 연속 샘플 수집 (시작 테스트 완료 후)
3. 총 1,000,000개 샘플을 "행 데이터셋(row dataset)" 형식으로 저장 — 1,000행 × 1,000열
4. 행 단위(단일 재시작 내)와 열 단위(재시작 간) 엔트로피를 각각 추정

재시작 테스트는 순차 데이터셋에서 얻은 H_I와 재시작 데이터셋에서 얻은 H_R을 비교하여, 최종 엔트로피 추정값으로 둘 중 더 작은 값을 채택합니다.

# 재시작 테스트 데이터 수집 (하드웨어별 스크립트 필요)
# 1,000회 재시작 × 1,000샘플 = 1,000,000바이트

# ea_restart 실행 (non-IID 경로, H_I는 순차 검증 결과값)
./ea_restart -n -v hwrng_restart.bin 8 7.973311
#                                    ↑ bits_per_symbol  ↑ H_I

# 출력 예:
# Row dataset analysis (within-restart): H_R_row = 7.985432
# Column dataset analysis (across-restart): H_R_col = 7.972145
# ────────────────────────────────────────
# H_R = min(H_R_row, H_R_col) = 7.972145
# Final entropy = min(H_I, H_R) = min(7.973311, 7.972145) = 7.972145

컨디셔닝 컴포넌트

컨디셔닝(Conditioning)은 노이즈 소스의 원시 출력에서 편향을 제거하고 엔트로피 밀도를 높이는 선택적 후처리 단계입니다. SP 800-90B는 컨디셔닝 컴포넌트를 두 가지로 분류합니다.

# ea_conditioning — 컨디셔닝 후 엔트로피 감소량 산정

# Vetted 컨디셔너 (SHA-256 등):
./ea_conditioning -v 256 256 256 240.0
#               ↑  n_in  n_out  nw  h_in
# 출력: H_out = min(256, 240.0) = 240.0 bits
#       (입력 엔트로피 240비트가 그대로 보존됨)

# Non-vetted 컨디셔너 (LFSR 등):
./ea_conditioning -n 256 256 8 240.0 0.98
#               ↑  n_in  n_out  nw  h_in  h'
# 출력: H_out = min(256, 240.0 × 0.98) = 235.2 bits
#       (컨디셔닝으로 인해 4.8비트 손실)

FIPS 140-3 요구사항 연관

SP 800-90B 검증 프로세스

SP 800-90B 검증은 NIST의 암호화 모듈 검증 프로그램(CMVP) 하에서 수행됩니다. 검증 프로세스는 엔트로피 소스 설계 문서 제출 → 데이터 샘플 수집 → 통계 검증 → 독립 실험실 검토 → 인증서 발급의 단계로 진행됩니다.

암호 키 생성 완전 플로우

hwrng 장치에서 생성된 엔트로피가 최종 암호 키로 변환되는 전체 흐름을 추적합니다. 커널 내부에서 여러 계층의 처리를 거쳐 안전한 키가 생성됩니다.

암호 키 생성 3가지 방식

/* 방식 1: get_random_bytes() — 권장 (CRNG 경유, 항상 안전) */
static int generate_aes_key(u8 *key, size_t keylen)
{
    get_random_bytes(key, keylen);  /* CRNG 초기화 후 항상 블록하지 않음 */
    /* keylen = 16(AES-128), 24(AES-192), 32(AES-256) */
    return 0;
}

/* 사용 후 반드시 소거 */
memzero_explicit(key, keylen);   /* 스택 키: 컴파일러 최적화 무력화 */
kfree_sensitive(heap_key);       /* 힙 키: 해제 전 자동 제로화 */

/* 방식 2: /dev/hwrng 직접 읽기 — 사용자 공간 (원시 엔트로피, CRNG 미경유) */
#include <fcntl.h>
#include <unistd.h>

static int read_hwrng_key(unsigned char *key, size_t len)
{
    int fd = open("/dev/hwrng", O_RDONLY);
    if (fd < 0) return -1;
    ssize_t n = read(fd, key, len);
    close(fd);
    return (n == (ssize_t)len) ? 0 : -1;
    /* 주의: 추출기(extractor) 미적용 시 편향 가능, NIST 권장은 getrandom() */
}

/* 방식 3: rng->read() — 커널 드라이버 내부 직접 접근 */
static int kernel_rng_keygen(struct hwrng *rng, u8 *key, size_t len)
{
    int ret = rng->read(rng, key, len, true);
    if (ret != (int)len) return -EIO;
    /* 주의: 원시 엔트로피 — 반드시 KDF(HKDF/PBKDF2)로 처리 후 사용 */
    return 0;
}

SSH 키 생성과 엔트로피

ssh-keygen은 모든 키 쌍 생성 시 OpenSSL의 BN_rand() 또는 libsodium의 randombytes_buf()를 통해 커널 getrandom() 시스템 콜에서 엔트로피를 획득합니다. 키 타입에 따라 엔트로피 소비량과 품질 요구사항이 크게 다릅니다.

호스트 키 재생성과 Forward Secrecy: 운영 중 SSH 호스트 키를 재생성하면 이전 키로 서명된 known_hosts 항목이 무효화(Invalidation)될 뿐 아니라, 재생성 시점의 엔트로피 품질이 새 키의 장기 보안성을 결정합니다. 특히 동일한 엔트로피 상태에서 재생성하면 이론적으로 동일한 키가 다시 나올 수 있으므로, crng_ready() 확인 후 재생성하는 것이 필수입니다. ChaCha20-CRNG의 Fast Key Erasure는 이전 출력을 역추적할 수 없게 하므로, CRNG가 초기화된 이후라면 재생성된 키의 안전성이 보장됩니다.

# 호스트 키 재생성 전 CRNG 준비 상태 확인
cat /proc/sys/kernel/random/entropy_avail  # 256 이상이어야 안전

# Ed25519 호스트 키 생성 (엔트로피 소비 최소, 권장)
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""

# RSA 4096 호스트 키 생성 (엔트로피 소비 최대, 구형 클라이언트 호환용)
ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""

# ssh-keygen의 getrandom() 호출 추적
strace -e trace=getrandom ssh-keygen -t ed25519 -f /tmp/test_key -N "" 2>&1

KDF와 솔트 생성

hwrng에서 추출된 원시 엔트로피는 KDF(Key Derivation Function, 키 파생 함수)를 거쳐 인증 프로토콜에 사용되는 다양한 키 자료로 확장됩니다. 원시 hwrng 출력을 인증 키로 직접 사용하면 하드웨어 편향(Bias)이 그대로 전파되므로, 반드시 KDF를 통해 균일 분포(Uniform Distribution)로 정규화해야 합니다.

HKDF와 TLS 1.3 / IKEv2 키 스케줄

HKDF(HMAC-based Key Derivation Function, RFC 5869)는 현대 인증 프로토콜의 키 파생 핵심입니다. TLS 1.3은 핸드셰이크 초기 엔트로피(ClientHello random + ServerHello random)를 HKDF-Extract로 흡수하고, HKDF-Expand로 각 단계별 키를 파생합니다.

/*
 * TLS 1.3 키 스케줄에서 hwrng 엔트로피의 흐름
 *
 * 1. ClientHello.random ← getrandom() 32바이트
 * 2. ServerHello.random ← getrandom() 32바이트
 * 3. Early Secret = HKDF-Extract(0, PSK 또는 0)
 * 4. Handshake Secret = HKDF-Extract(Derive-Secret(Early Secret), ECDHE shared secret)
 * 5. Main Secret = HKDF-Extract(Derive-Secret(Handshake Secret), 0)
 * 6. 각 키 파생: client/server traffic key, finished key, exporter key
 *
 * 핵심: ClientHello.random과 ServerHello.random은 hwrng 기반 CRNG에서 직접 추출.
 * ECDHE 개인 키도 getrandom()에서 생성. 모든 키 자료의 근원 엔트로피는 hwrng.
 */

/* IPSec IKEv2 키 파생 — RFC 7386 (PRF = HMAC-SHA-256) */
/*
 * SKEYSEED = prf(Ni | Nr, g^ir)
 *   Ni (initiator nonce) ← getrandom() 16~32바이트
 *   Nr (responder nonce) ← getrandom() 16~32바이트
 *   g^ir = Diffie-Hellman shared secret (개인 키도 getrandom()에서 생성)
 *
 * SK_d, SK_ai, SK_ar, SK_ei, SK_er = prf+(SKEYSEED, Ni | Nr | SPIi | SPIr)
 * 모든 SA 키는 SKEYSEED에서 파생되며, SKEYSEED의 엔트로피는
 * nonce(Ni, Nr)와 DH 일시 키에서 비롯 — 모두 hwrng 기반
 */

비밀번호 해시 솔트 생성

비밀번호 기반 인증의 핵심인 솔트(Salt) 생성도 hwrng에 의존합니다. 솔트는 각 사용자 비밀번호 해시마다 고유해야 하며, 예측 가능하면 레인보우 테이블(Rainbow Table)의 효율이 크게 높아집니다.

/* 비밀번호 솔트 생성 — 안전한 경로 (glibc 2.25+ 또는 직접 getrandom) */
#include <sys/random.h>
#include <errno.h>

static int generate_salt(unsigned char *salt, size_t len)
{
    /* getrandom()은 CRNG 초기화 전에 블록되므로 안전한 솔트 보장 */
    ssize_t ret = getrandom(salt, len, 0);
    if (ret < 0 || ret != (ssize_t)len)
        return -1;
    return 0;
}

/* 위험: time() + getpid() 기반 솔트 — 절대 사용 금지 */
/* unsigned int bad_salt = time(NULL) ^ getpid() ^ (clock() & 0xffff); */
/* → 예측 가능, 레인보우 테이블 사전 계산 가능, 인증 무력화 */

인증 프로토콜에서의 hwrng 역할

hwrng에서 생성된 엔트로피는 커널 CRNG를 거쳐 다양한 인증 프로토콜의 안전성 근간이 됩니다. 이 섹션에서는 hwrng 품질이 직접적으로 인증 보안에 영향을 미치는 주요 프로토콜들을 분석합니다.

원격 증명과 hwrng

원격 증명(Remote Attestation)은 TPM(Trusted Platform Module)이 시스템의 무결성(Integrity) 상태를 외부 검증자(Verifier)에게 암호학적으로 증명하는 프로세스입니다. 이 프로세스에서 hwrng는 도전값(Qualifying Data)의 무작위성을 보장하는 핵심 역할을 수행합니다.

TPM2_Quote 명령의 엔트로피 흐름:

1. 검증자가 getrandom()로 128~256비트 도전값(qualifying data)을 생성
2. 검증자가 도전값을 증명 대상(Attestator)에 전송
3. 증명 대상이 TPM2_Quote 명령으로 도전값 + 선택된 PCR(Platform Configuration Register) 값을 서명
4. 검증자가 서명된 응답을 검증 — 도전값이 일치하면 재생 공격(Replay Attack) 차단

/* TPM2_Quote 도전값 생성 — 커널 CRNG에서 추출 */
#include <sys/random.h>

static int generate_attestation_challenge(uint8_t *challenge, size_t len)
{
    /*
     * 도전값은 검증자가 생성. 128비트(16바이트) 이상 권장.
     * getrandom()은 CRNG 초기화 전에 블록되므로
     * 안전한 도전값이 보장됨.
     *
     * 주의: time()이나 counter 기반 도전값 사용 금지.
     *       예측 가능한 도전값은 재생 공격을 허용.
     */
    ssize_t ret = getrandom(challenge, len, 0);
    return (ret == (ssize_t)len) ? 0 : -1;
}

/*
 * TPM2_Quote 호출 (tpm2-tools 예시):
 *   tpm2_quote -c ak.ctx -l sha256:0,1,2,3,4,5,6,7 -q $(hex_challenge)
 *
 * -q (qualifying data): 검증자가 생성한 무작위 도전값
 * TPM이 이 값을 서명에 포함하여 재생 공격 방지
 */

도전-응답 인증과 난수 품질

도전-응답(Challenge-Response) 인증은 상대방이 비밀을 직접 전송하지 않고 도전값에 대한 응답으로 자신을 증명하는 프로토콜입니다. 도전값의 예측 불가능성이 프로토콜 전체의 보안을 결정하므로, hwrng 기반 CRNG에서 생성된 난수가 필수입니다.

PKI 인증서 발급의 난수 의존성

PKI(Public Key Infrastructure, 공개 키 기반 구조) 인증서 발급에서 hwrng 기반 난수는 세 가지 핵목에 사용됩니다: 인증서 일련 번호(Serial Number), CRL 번호, OCSP nonce입니다.

인증서 일련 번호 (RFC 5280 §4.1.2.2): RFC 5280은 일련 번호를 "양의 정수"로 요구하며, CA(Browser Forum Baseline Requirements)는 최소 64비트 무작위성을 권장합니다. 일련 번호가 순차적이거나 예측 가능하면 공격자가 다음 인증서의 일련 번호를 추측하여 인증서 충돌 공격이나 추적 공격에 활용할 수 있습니다.

/* OpenSSL 기반 CA의 일련 번호 생성 경로 */
/*
 * OpenSSL BN_rand() → getrandom() syscall
 *
 * CA 일련 번호: 20바이트(160비트) 무작위, 최상위 비트는 0 (양수 보장)
 * RFC 5280: 일련 번호는 1~20바이트 octet string
 * CA/B Forum: 최소 64비트 무작위성 권장 (충돌 방지)
 *
 * 예측 가능한 일련 번호의 위험:
 *   - 순차 할당(1, 2, 3...) → 발급량 추적 가능
 *   - 시간 기반 할당 → 발급 시점 추측 → 정밀 추적
 *   - 충돌 공격: 같은 발급자+일련번호로 두 인증서 생성 시 혼란
 */

/* OCSP nonce (RFC 8954) — 재생 공격 방지 */
/*
 * OCSP 요청에 nonce 확장 포함:
 *   클라이언트가 getrandom()로 128비트 nonce 생성 → OCSP 요청에 포함
 *   서버가 응답에 동일 nonce 포함 → 재생 공격 차단
 *
 * nonce 부재 시: 공격자가 이전 OCSP 응답을 재생하여
 *   이미 폐지된 인증서를 유효하게 속일 수 있음
 */

FIDO2 / WebAuthn 인증기 난수

FIDO2/WebAuthn은 패스워드 없는 인증(Passwordless Authentication) 표준으로, 인증기(Authenticator)가 비대칭 키 쌍을 생성하고 서명으로 사용자를 인증합니다. 이 과정에서 hwrng는 두 가지 경로로 기여합니다.

호스트 측 도전값: 의존 당사자(Relying Party, RP)가 crypto.getRandomValues()로 도전값을 생성합니다. 브라우저는 이를 getrandom() syscall로 전달하여 커널 CRNG에서 128비트 이상의 난수를 획득합니다.

인증기 내부 난수: 하드웨어 인증기(YubiKey, Titan Security Key 등)는 내장 TRNG를 사용하여 서명 논스와 키 쌍을 생성합니다. 소프트웨어 인증기(플랫폼 인증기)는 호스트의 getrandom()에 의존합니다.

Kerberos 세션 키 생성

Kerberos는 중앙 KDC(Key Distribution Center)가 TGT(Ticket Granting Ticket)와 TGS(Ticket Granting Service) 티켓에 포함되는 세션 키를 생성합니다. 이 세션 키는 클라이언트와 서비스 간 인증의 기반이 되며, KDC의 엔트로피 품질에 직접 의존합니다.

세션 키 생성 경로:

1. KDC의 krb5_c_make_random_key() 호출 → MIT krb5 라이브러리
2. 라이브러리 내부에서 krb5_c_random_make_octets() → /dev/urandom 또는 getrandom()
3. 추출된 난수를 암호 알고리즘의 키 형식(AES-256, Camellia 등)으로 변환
4. 생성된 세션 키가 TGT/TGS 티켓에 암호화되어 포함

# KDC의 엔트로피 소비 추적 (MIT Kerberos)
strace -e trace=getrandom -f -p $(pgrep krb5kdc) 2>&1 | head -20

# KDC 시작 전 CRNG 준비 확인
# /etc/systemd/system/krb5kdc.service.d/override.conf
[Unit]
After=systemd-random-seed.service

[Service]
ExecStartPre=/bin/sh -c 'while [ $(cat /proc/sys/kernel/random/entropy_avail) -lt 256 ]; do sleep 0.1; done'

# Active Directory KDC의 RNG 의존성:
# Windows DC는 CryptGenRandom() → BCryptGenRandom() 호출
# 내부적으로 커널 RNG(sysgenrng)를 사용하므로 hwrng 품질에 의존

사용자 공간 프로그램의 커널 난수 공급 구조

지금까지 커널 내부의 hwrng → input_pool → ChaCha20 CRNG 경로를 살펴봤습니다. 하지만 실제 암호학적 안전성은 사용자 공간(User Space) 프로그램이 이 난수를 어떻게 획득하고 어떻게 사용하는가에 의해 최종 결정됩니다. OpenSSL, OpenSSH, strongSwan, GnuTLS, NSS 등 주요 암호 라이브러리와 응용 프로그램은 각자 고유한 난수 공급 아키텍처를 가지며, 커널 getrandom() 시스템 콜 또는 /dev/urandom에서 시드를 받아 자체 DRBG를 운영합니다. 이 섹션에서는 각 프로그램이 커널로부터 난수를 공급받아 사용하는 전체 경로를 추적합니다.

전체 공급 계층 구조

사용자 공간 프로그램이 커널 난수를 사용하는 경로는 4계층으로 나뉩니다:

1. 커널 계층(Kernel Layer) — hwrng 하드웨어 → input_pool(Blake2s) → ChaCha20 CRNG
2. 시스템 콜 계층(System Call Layer) — getrandom(2), /dev/urandom, /dev/random, AF_ALG 소켓(crypto API)
3. 라이브러리 DRBG 계층(Library DRBG Layer) — OpenSSL, GnuTLS, NSS, libgcrypt 각자의 NIST SP 800-90A DRBG 인스턴스
4. 응용 프로그램 계층(Application Layer) — OpenSSH, strongSwan/charon, Nginx, Apache, Python 등

대부분의 응용 프로그램은 라이브러리 DRBG 계층을 거쳐 난수를 획득하지만, 일부(특히 시스템 유틸리티)는 getrandom()이나 /dev/urandom을 직접 호출하기도 합니다. 다음 다이어그램은 전체 공급 경로를 보여줍니다:

OpenSSL — DRBG 기반 난수 공급 아키텍처

OpenSSL은 가장 널리 사용되는 범용 암호 라이브러리로, Nginx, Apache, OpenSSH, curl 등 수많은 프로그램이 난수 생성을 OpenSSL에 위임합니다. OpenSSL 1.1.1부터는 NIST SP 800-90A CTR-DRBG(AES-256-CTR 기반)를 기본 DRBG로 사용하며, OpenSSL 3.0부터는 Provider 아키텍처로 전환되어 EVP_RAND / EVP_DRBG API를 통해 DRBG를 추상화합니다.

시드 획득 경로

OpenSSL은 플랫폼별로 최적의 시드 소스를 자동 선택합니다. Linux에서의 우선순위는 다음과 같습니다:

1. getrandom(2) 시스템 콜 (OpenSSL 1.1.0+ 사용) — GRND_NONBLOCK 플래그 없이 호출하여 CRNG 초기화 전 블로킹 보장. 시드로 256비트(32바이트) 이상 요청
2. /dev/urandom 폴백 — getrandom()을 사용할 수 없는 구형 커널(Linux 3.17 미만)에서 사용. OpenSSL 1.1.0 이전에는 /dev/urandom이 기본 경로
3. /dev/random 추가 시드 — FIPS 모드에서 drbg-seed 시 사용. 일반 모드에서는 사용하지 않음

OpenSSL의 시드 획득은 rand_seed.c 또는 Provider의 seed_src에서 수행됩니다:

/* OpenSSL 3.x — default provider의 seed source (libcrypto/rand/rand_seed.c) */

/*
 * Linux에서 시드를 획득하는 핵심 함수.
 * 1차: getrandom(GRND_NONBLOCK=0) → CRNG 준비까지 블로킹
 * 2차: /dev/urandom 읽기 (구형 커널 폴백)
 */
static int rand_pool_add_nonce_data(RAND_POOL *pool)
{
    unsigned char buf[DRBG_MIN_SEED_LEN];  /* 32바이트 (256비트) */
    size_t ret;

    /* getrandom() 시도 — Linux 3.17+ */
    ret = syscall(SYS_getrandom, buf, sizeof(buf), 0);
    if (ret == sizeof(buf)) {
        return rand_pool_add(pool, buf, ret, ret * 8);
    }

    /* /dev/urandom 폴백 */
    return rand_pool_add_additional_data(pool);
}

/*
 * 응용 프로그램이 호출하는 공개 API.
 * 내부적으로: DRBG 인스턴스 → 시드 확인 → CTR-DRBG 출력
 */
int RAND_bytes(unsigned char *buf, int num)
{
    return EVP_RAND_generate(
        RAND_get0_primary(NULL),  /* primary DRBG 인스턴스 */
        buf, num,
        DRBG_STRENGTH,             /* 256비트 보안 강도 */
        NULL, 0                    /* 추가 입력 없음 */
    );
}

DRBG 인스턴스 계층

OpenSSL 3.0은 NIST SP 800-90C의 3계층 DRBG 트리를 구현합니다:

재시드(Reseed) 정책

OpenSSL DRBG는 다음 조건에서 자동 재시드를 수행합니다:

• 시드 풀 갱신 — RAND_add() 또는 RAND_seed() 호출 시 Primary DRBG가 재시드되고, 하위 DRBG도 연쇄 재시드
• 요청 횟수 임계값 — RESEED_INTERVAL(기본값: 2²⁴ = 16,777,216회) 도달 시
• 시간 경과 — RAND_DRBG_get_reseed_time_interval() 기준 (기본 600초)
• FIPS 모드 — drbg-seed 파일에서 추가 시드를 주기적으로 읽어 재시드

# OpenSSL이 getrandom()을 호출하는지 추적
strace -e trace=getrandom,openat -f openssl rand -hex 32 2>&1 | grep -E 'getrandom|urandom'

# 출력 예 (Linux 5.x + OpenSSL 3.x):
# getrandom("\x..", 48, 0) = 48               ← 384비트 시드 획득 (CRNG 준비까지 블로킹)
# (이후 CTR-DRBG 내부에서 난수 생성, 추가 시스템 콜 없음)

# FIPS 모드에서 AF_ALG 사용 확인
strace -e trace=socket,sendto,recvfrom -f openssl rand -hex 32 -provider fips 2>&1 | head -20

OpenSSH — SSH 프로토콜 난수 사용

OpenSSH는 SSH 프로토콜의 모든 단계에서 난수를 소비합니다. OpenSSH의 난수 획득은 OpenSSL의 RAND_bytes()를 1차 경로로 사용하며, OpenSSL이 사용 불가능한 환경에서는 자체 arc4random() 구현으로 폴백합니다.

시드 및 난수 획득 경로

OpenSSH의 seed_rng() 함수(entropy.c)는 시작 시 다음 순서로 난수 소스를 초기화합니다:

1. OpenSSL RAND_bytes() 사용 가능 — OpenSSL이 내부적으로 getrandom()을 호출하여 시드 획득. OpenSSH는 OpenSSL의 DRBG 출력을 그대로 사용
2. arc4random() 폴백 — BSD 시스템 또는 OpenSSL 미연결 시. arc4random()은 ChaCha20 기반 자체 CSPRNG를 운영하며, 시드는 getrandom() 또는 /dev/urandom에서 획득
3. /dev/urandom 직접 읽기 — 최후의 폴백. 구형 시스템에서 사용

/* OpenSSH entropy.c — seed_rng() 단순화 */

void seed_rng(void)
{
    unsigned char buf[32];

    /*
     * 1차: OpenSSL RAND_bytes() — 내부적으로 getrandom() 호출
     * OpenSSL이 컴파일 시 연결된 경우 우선 사용
     */
#ifdef WITH_OPENSSL
    if (RAND_bytes(buf, sizeof(buf)) == 1)
        return;  /* OpenSSL DRBG에서 난수 확보 완료 */
#endif

    /*
     * 2차: arc4random() — libcrypto 미사용 시
     * arc4random_buf()는 내부적으로 getrandom() 또는
     * /dev/urandom에서 시드를 받아 ChaCha20 CSPRNG 운영
     */
    arc4random_buf(buf, sizeof(buf));
}

/*
 * SSH 프로토콜 쿠키 생성 — sshconnect.c / sshd.c
 * 16바이트(128비트) 난수 쿠키로 서버 인증 강화
 */
static void generate_session_cookie(u_char *cookie)
{
    arc4random_buf(cookie, 16);  /* 128비트 SSH 쿠키 */
}

프로토콜 단계별 난수 소비

SSH 연결 수립 과정에서 난수가 사용되는 모든 지점을 추적합니다:

strongSwan — IKE/IPsec 난수 사용

strongSwan은 Linux에서 가장 널리 사용되는 IPsec/IKEv2 구현체입니다. charon 데몬(IKE 데몬)은 libstrongswan 프레임워크의 RNG 추상화 계층을 통해 난수를 획득하며, 운영 모드에 따라 시드 소스가 다릅니다.

RNG 추상화 계층

strongSwan은 rng_t 인터페이스를 통해 세 가지 품질(Quality) 등급의 난수를 제공합니다:

/* strongSwan libstrongswan/crypto/rng.h — RNG 인터페이스 */

typedef enum {
    RNG_QUAL_TRUE   = 0,  /* /dev/random — 블로킹, 진난수 */
    RNG_QUAL_STRONG = 1,  /* /dev/urandom 또는 getrandom() — CSPRNG */
    RNG_QUAL_WEAK   = 2,  /* DRBG 내부 — 재시드 없음 */
} rng_quality_t;

/*
 * charon 데몬이 IKE nonce를 생성하는 코드 경로.
 * file: src/libcharon/sa/ikev2/task_v2.c
 */
static status_t build_nonce(ike_sa_t *ike_sa, chunk_t *nonce)
{
    rng_t *rng;
    size_t nonce_len = 32;  /* 256비트 nonce (RFC 7383 권장) */

    /* RNG_STRONG 품질로 RNG 인스턴스 생성 */
    rng = lib->crypto->create_rng(lib->crypto, RNG_QUAL_STRONG);
    if (!rng) {
        return FAILED;
    }

    /* /dev/urandom 또는 getrandom()에서 256비트 난수 획득 */
    rng->get_bytes(rng, nonce_len, nonce->ptr);
    rng->destroy(rng);

    return SUCCESS;
}

FIPS 모드 — AF_ALG 경로

strongSwan을 FIPS 140-2/140-3 모드로 운영할 때는 사용자 공간 라이브러리의 DRBG 대신 커널 Crypto API의 DRBG를 AF_ALG 소켓을 통해 직접 사용합니다. 이는 인증된 DRBG 구현체(crypto/drbg.c)를 사용하기 위함입니다:

1. socket(AF_ALG, SOCK_SEQPACKET, 0) — 알고리즘 소켓 생성
2. bind(fd, {sa_family=AF_ALG, salg_name="drbg_nopr_ctr_aes256", ...}) — DRBG 알고리즘 선택
3. setsockopt(fd, SOL_ALG, ALG_SET_KEY, seed, seed_len) — 시드 주입 (getrandom()에서 획득)
4. accept(fd) — operation 소켓 생성
5. send(op_fd, input, len, MSG_MORE) + recv(op_fd, output, len, 0) — 난수 출력

# strongSwan FIPS 모드에서 AF_ALG 사용 확인
strace -e trace=socket,bind,setsockopt,accept,sendto,recvfrom \
  -f charon 2>&1 | grep -E 'AF_ALG|drbg|getrandom'

# strongSwan 설정에서 RNG 품질 지정 (strongswan.conf)
# /etc/strongswan.conf
charon {
    # 기본 RNG 품질 (기본값: strong)
    rng_quality = strong

    # FIPS 모드: 커널 crypto API DRBG 사용
    # plugins/crypto/kernel-plugin 사용 시 AF_ALG 경로
    crypto {
        # RNG_STRONG → /dev/urandom (비FIPS) 또는 AF_ALG DRBG (FIPS)
        rng_strong = "drbg_nopr_ctr_aes256"
    }
}

# IKE SA 설정에서 nonce 크기 확인
# ipsec.conf 또는 swanctl.conf
connections {
    ike-v2 {
        version = 2
        proposals = aes256gcm16-prfsha256-modp2048
        # nonce_len 기본값: 32바이트 (256비트)
    }
}

IKEv2 통신 단계별 난수 소비

기타 주요 라이브러리 — GnuTLS, NSS, libgcrypt

GnuTLS

GnuTLS는 OpenSSL의 대안으로 널리 사용되는 TLS 라이브러리로, Apache, curl, Exim 등에서 사용됩니다. GnuTLS 3.3+에서는 getrandom(2)를 1차 시드 소스로 사용하며, 자체 DRBG 인스턴스를 운영합니다:

• 시드 소스: getrandom() → /dev/urandom 폴백
• DRBG: AES-256-CTR 기반 CTR-DRBG (NIST SP 800-90A)
• API: gnutls_rnd(level, data, len) — 세 가지 수준 제공
  • GNUTLS_RND_NONCE — nonce용 (재시드 빈도 낮음, 속도 우선)
  • GNUTLS_RND_RANDOM — 일반 난수 (균형)
  • GNUTLS_RND_KEY — 키 생성용 (매번 재시드, 보안 우선)
• 재시드: GNUTLS_RND_KEY 호출 시마다 getrandom()에서 새 시드 획득

/* GnuTLS — gnutls_rnd() 사용 예 */
#include <gnutls/gnutls.h>

uint8_t session_key[32];
uint8_t nonce[12];

/* 키 생성 — 매번 getrandom()에서 재시드 (가장 안전) */
gnutls_rnd(GNUTLS_RND_KEY, session_key, sizeof(session_key));

/* nonce — DRBG 출력 (빠른 경로) */
gnutls_rnd(GNUTLS_RND_NONCE, nonce, sizeof(nonce));

NSS (Network Security Services)

NSS는 Mozilla Firefox, Thunderbird, Red Hat Directory Server 등에서 사용하는 암호 라이브러리입니다. 과거 Hash-DRBG(SHA-256)를 사용했으나, 현재는 CTR-DRBG(AES-256-CTR)로 전환했습니다:

• 시드 소스: getrandom() (Linux 3.17+) → /dev/urandom 폴백
• DRBG: CTR-DRBG (AES-256-CTR), NIST SP 800-90A 준수
• API: PK11_GenerateRandom(data, len) — PKCS#11 인터페이스
• 특징: NSS는 자체 "freebl" 라이브러리에서 DRBG를 운영하며, 별도의 시드 데몬 없이 getrandom()에서 직접 시드 획득

libgcrypt (GnuPG)

libgcrypt는 GnuPG, dirmngr, gpg-agent 등에서 사용하는 암호 라이브러리입니다:

• 시드 소스: getrandom() → /dev/urandom 폴백
• DRBG: CTR-DRBG (AES-256-CTR) 또는 HMAC-DRBG (SHA-256), 설정에 따라 선택
• API: gcry_random_bytes(len, level) — 세 가지 수준
  • GCRY_WEAK_RANDOM — nonce/padding용
  • GCRY_STRONG_RANDOM — 일반 암호학적 용도
  • GCRY_VERY_STRONG_RANDOM — 장기 키 생성 (매번 재시드)
• 특징: GCRY_VERY_STRONG_RANDOM 사용 시 /dev/random에서 추가 엔트로피를 읽어 재시드. FIPS 모드에서는 rngd와 연동

공급 경로 종합 비교

실제 난수 획득 추적 — strace 실습

각 프로그램이 실제로 어떤 시스템 콜을 통해 커널에서 난수를 획득하는지 strace로 확인할 수 있습니다:

# OpenSSL: getrandom() 호출 1회 후 DRBG에서 확장
strace -e trace=getrandom,openat -f openssl rand -hex 64 2>&1 | grep -v ENOENT
# 예상 출력:
# [pid 12345] getrandom("\x..", 32, GRND_NONBLOCK) = 32  ← CRNG 준비 확인
# [pid 12345] getrandom("\x..", 48, 0) = 48               ← DRBG 시드 (256+128비트)
# (이후 64바이트는 CTR-DRBG 내부에서 생성, 추가 getrandom 없음)

# OpenSSH: ssh-keygen Ed25519 키 생성
strace -e trace=getrandom -f ssh-keygen -t ed25519 -f /tmp/test_key -N "" 2>&1
# 예상 출력:
# getrandom("\x..", 32, 0) = 32  ← OpenSSL을 통한 256비트 시드
# (Ed25519 스칼라 1개 = 256비트, DRBG에서 1회 출력)

# strongSwan: charon 데몬의 IKE nonce 생성
strace -e trace=getrandom,openat -f -p $(pgrep charon) 2>&1 | head -10
# 예상 출력 (비FIPS 모드):
# openat(AT_FDCWD, "/dev/urandom", O_RDONLY|O_CLOEXEC) = 8
# read(8, "\x..", 32) = 32  ← 256비트 nonce (Ni)
# read(8, "\x..", 32) = 32  ← 256비트 nonce (Nr)

# strongSwan FIPS 모드: AF_ALG 소켓 사용
strace -e trace=socket,bind,setsockopt,accept,sendto,recvfrom -f -p $(pgrep charon) 2>&1 | head -20
# 예상 출력:
# socket(AF_ALG, SOCK_SEQPACKET, 0) = 9
# bind(9, {sa_family=AF_ALG, salg_type="rng", salg_name="drbg_nopr_ctr_aes256"}, ...)
# setsockopt(9, SOL_ALG, ALG_SET_KEY, "\x..", 32)  ← getrandom() 시드
# accept(9) = 10
# recvfrom(10, "\x..", 32, 0, ...) = 32  ← DRBG 출력

# Python: 매번 getrandom() 직접 호출 (DRBG 없음)
strace -e trace=getrandom python3 -c 'import os; os.urandom(32)' 2>&1
# 예상 출력:
# getrandom("\x..", 32, 0) = 32  ← 직접 CRNG 출력, DRBG 거치지 않음

# Node.js: crypto.randomBytes()는 OpenSSL RAND_bytes() 경유
strace -e trace=getrandom node -e 'require("crypto").randomBytes(32)' 2>&1
# 예상 출력:
# getrandom("\x..", 48, 0) = 48  ← OpenSSL DRBG 시드 (내부적으로 getrandom 호출)
# (이후 난수는 OpenSSL CTR-DRBG에서 생성)

테스트 및 검증

hwrng 드라이버를 로드한 후 다양한 수준의 검증을 수행해야 합니다. 기본적인 sysfs 확인부터 NIST 통계 배터리까지, 검증 단계는 드라이버 로드 확인 → 바이트 스트림 읽기 → FIPS 빠른 검증 → 정밀 통계 검증 순서로 진행합니다. 다음 다이어그램은 전체 테스트 워크플로우를 보여줍니다.

sysfs 인터페이스

# 현재 활성 hwrng 확인
cat /sys/class/misc/hw_random/rng_current
# 출력: myrng (또는 usb-hwrng)

# 사용 가능한 hwrng 목록
cat /sys/class/misc/hw_random/rng_available
# 출력: myrng virtio_rng intel-rng

# 활성 hwrng 변경 (우선순위: quality 높은 것이 자동 선택)
echo "myrng" > /sys/class/misc/hw_random/rng_current

# hwrng에서 직접 읽기 (원시 바이트)
dd if=/dev/hwrng bs=1 count=32 | xxd

rng-tools를 사용한 엔트로피 공급

# rng-tools 설치 (Ubuntu/Debian)
apt-get install rng-tools5

# rngd 데몬 실행 — /dev/hwrng → /dev/random 엔트로피 공급
rngd -r /dev/hwrng -o /dev/random -f

# 엔트로피 풀 현재 크기 확인 (레거시, 5.18+에서는 의미 감소)
cat /proc/sys/kernel/random/entropy_avail

# CRNG 초기화 완료 여부 확인 (dmesg)
dmesg | grep -E "crng|random"
# 정상: "random: crng init done"
# 경고: "random: get_random_u32 called from ... with crng_init=0" → 초기화 전 사용

rngtest — NIST SP 800-22 통계 검증

# NIST 통계 테스트 실행 (20000비트 × 200 블록)
cat /dev/hwrng | rngtest -c 200

# 예상 출력 (정상 hwrng):
# rngtest: bits received from input: 4000032
# rngtest: FIPS 140-2 success: 196
# rngtest: FIPS 140-2 failures: 4
# rngtest: bits discarded due to failures: 80032
# → 200블록 중 ~4개 실패는 통계적으로 정상 (5% 이내)

# 실패율이 너무 높으면 (10% 초과) 드라이버 또는 하드웨어 문제

# ENT (entropy estimation 도구)
dd if=/dev/hwrng bs=1M count=1 | ent
# Entropy: 7.9999 bits per byte → 이상적 난수 표본
# Chi-square: 초과 확률 > 1%이면 양호

커널 내부 엔트로피 디버그

# CRNG 초기화 타임스탬프 확인
dmesg --ctime | grep "crng init"

# hwrng 스레드 동작 확인 (hw_random 코어가 kthread로 지속 수집)
ps aux | grep hwrng
# 출력: ... [hwrng] (커널 스레드)

# /proc/sys/kernel/random/ 파라미터
ls /proc/sys/kernel/random/
# boot_id        — 부팅 고유 UUID (변경 불가)
# uuid           — 읽을 때마다 새 UUID 생성
# entropy_avail  — 현재 엔트로피 추정값 (비트)
# poolsize       — 입력 풀 크기 (항상 256)
# urandom_min_reseed_secs — 재시드 최소 간격

# 엔트로피 소모 시뮬레이션 (테스트 전용)
dd if=/dev/urandom of=/dev/null bs=1M count=100 &
watch -n 0.5 'cat /proc/sys/kernel/random/entropy_avail'

엔트로피 기여량 실시간(Real-time) 모니터링

# hwrng 스레드 동작 및 엔트로피 기여량 실시간 모니터링
# (1초 간격으로 entropy_avail 변화 추적)
watch -n 1 'echo "=== $(date +%T) ===" ;
  echo "활성 hwrng: $(cat /sys/class/misc/hw_random/rng_current)";
  echo "엔트로피 추정: $(cat /proc/sys/kernel/random/entropy_avail) bits";
  echo "CRNG 재시드: $(cat /proc/sys/kernel/random/urandom_min_reseed_secs)s 간격"'

# hwrng 커널 스레드 CPU 사용률 확인
ps -eo pid,comm,pcpu | grep hwrng

# 1MB 샘플 수집 속도 측정 (처리율 벤치마크)
time dd if=/dev/hwrng of=/dev/null bs=4k count=256 2>&1
# 출력 예: 1048576 bytes copied, 0.08 s, 12.6 MB/s  ← PCIe hwrng
#          1048576 bytes copied, 1.05 s, 998 kB/s    ← USB hwrng

NIST SP 800-90B 오픈소스 검증 도구

# NIST SP 800-90B 공식 검증 도구 설치 (C++11 + OpenMP 기반)
git clone https://github.com/usnistgov/SP800-90B_EntropyAssessment.git
cd SP800-90B_EntropyAssessment

# 의존 라이브러리 설치 (Ubuntu/Debian)
apt-get install libbz2-dev libdivsufsort-dev libjsoncpp-dev libssl-dev libmpfr-dev

# 빌드 — 전체 도구 한 번에 컴파일
make

# 또는 개별 빌드: make iid / make non_iid / make restart / make conditioning

# 셀프 테스트로 컴파일 검증
cd selftest && ./selftest
# delta < 1.0E-6 이면 PASS

# 1,000,000바이트 원시 엔트로피 수집
dd if=/dev/hwrng bs=1M count=1 of=hwrng_sample.bin

# IID 추정 (독립-동일 분포 가정)
./ea_iid -i hwrng_sample.bin 8
# -i: unconditioned 초기 엔트로피 추정, 8 = bits_per_symbol
# 출력: min-entropy estimate = 7.999 bits per symbol → quality=1023 적합

# Non-IID 추정 (보수적 추정, FIPS 140-3 요건) — 대부분의 소스는 이 경로 사용
./ea_non_iid -i hwrng_sample.bin 8
# 10가지 추정기 중 최솟값이 실제 min-entropy (H_I)
# -v 옵션 추가 시 각 추정기별 상세 결과 출력
# 출력 예: min-entropy = 7.998 → H_min_per_bit = 0.9998 → quality=1023

# 컨디셔닝된 데이터 검증 (-c 옵션, bitstring 모드)
./ea_non_iid -c -t conditioned_sample.bin 1
# -c: conditioned 데이터, -t: 첫 1,000,000비트로 제한, 1 = 바이너리

# 재시작 테스트 (Restart Test) — 하드웨어 초기 조건 의존성 검증
./ea_restart -n hwrng_restart.bin 8 7.998
# -n: non-IID 경로, 마지막 인자 H_I는 순차 검증 결과값
# 파일은 "row dataset" 형식: 1,000행 × 1,000열 = 1,000,000바이트

# 컨디셔닝 컴포넌트 엔트로피 감소량 산정
./ea_conditioning -v 256 256 256 240.0
# -v: vetted, n_in=256 n_out=256 nw=256 h_in=240.0
# non-vetted: ./ea_conditioning -n 256 256 8 240.0 0.98 (마지막은 h')

SP800-90B_EntropyAssessment 툴킷 구성 (5종)

위 코드에서 사용한 ea_* 명령들은 모두 NIST 공식 C++ 툴킷 SP800-90B_EntropyAssessment(C++11 + OpenMP)에서 빌드되는 하위 도구들입니다. 툴킷은 SP 800-90B의 min-entropy 평가 방법을 충실하게 구현하며, 관리자는 NIST의 Chris Celi, 라이선스는 NIST public domain(NIST 개발 소프트웨어 공공 서비스 조건)입니다.

SP800-90B_EntropyAssessment 세부 평가 항목 상세 해설

SP800-90B_EntropyAssessment 툴킷은 단일 프로그램이 아니라 5개 하위 도구(ea_iid, ea_non_iid, ea_restart, ea_conditioning, ea_transpose)로 구성되며, 각 하위 도구가 SP 800-90B 표준의 서로 다른 절(Section)에 대응하는 평가 항목들을 수행합니다. 아래는 각 하위 도구가 평가하는 모든 세부 항목을 방법·의미·수치 범위와 함께 열거한 해설입니다.

① ea_iid — IID 검정 세부 항목 (카이제곱 + LRS + 순열 검정 19종)

ea_iid는 엔트로피 소스가 IID(Independent and Identically Distributed, 독립 동일 분포) 특성을 만족하는지 검정합니다. IID 가설이 유지되면 Most Common Value 추정기로 H_I를 산출하고, 기각되면 ea_non_iid 경로로 전환해야 합니다. ea_iid의 검정은 SP 800-90B §3.1.3에 기술된 절차에 따라 세 단계로 구성됩니다 — 순열 검정(§5.1), 카이제곱 검정(§5.2), LRS 검정(§5.2.5) 순서로 수행되며, 모든 단계에서 PASS해야 IID 가설이 유지됩니다.

카이제곱 검정 (§5.2) — 2종

카이제곱 검정은 순열 검정과 별도로 수행되는 독립된 검정 범주입니다. 소스 코드 chi_square_tests.h에 구현되어 있으며, 두 가지 하위 검정을 수행합니다.

LRS 검정 (§5.2) — 1종

최장 반복 부분문자열(Longest Repeated Substring) 검정은 순열 검정과 별도로 수행됩니다. 소스 코드 lrs_test.h에 구현되어 있으며, 접미 배열(suffix array, libdivsufsort)과 Kasai 등의 LCP(Longest Common Prefix) O(n) 알고리즘으로 최장 반복 부분문자열의 길이 W를 계산합니다.

순열 검정 (§5.1) — 19종

순열 검정(Permutation Test)은 원본 데이터에서 각 통계량을 계산한 후, 데이터를 무작위로 섞어(shuffle) 동일 통계량을 10,000회(PERMS = 10000, utils.h에 고정) 반복 계산하여 참조 분포(reference distribution)를 구성합니다. 원본 통계량이 순열 분포에서 극단적인 영역에 위치하면 p-value가 낮아지고, p-value < 0.001이면 해당 통계량에 대해 IID 가설을 기각합니다. OpenMP 병렬 처리로 10,000회 순열을 다중 코어에서 동시에 수행합니다.

아래 표는 소스 코드 permutation_tests.h의 test_names[] 배열에서 직접 확인한 19종 순열 검정 통계량의 정확한 목록입니다. 모든 통계량은 바이너리 및 다비트 심볼 모두에 적용되며, 바이너리 데이터의 경우 방향성/중앙값 기반 검정(2~6)은 Conversion I을, 충돌 검정(7~8)은 Conversion II를 통해 전처리됩니다.

# ea_iid 상세 실행 — 모든 검정 결과 개별 출력
./ea_iid -v -v -v hwrng_sample.bin 8
# -v 3회: 가장 상세한 출력 (각 검정별 통계량, p-value)
# -q: quiet mode (출력 감소, verbose 플래그 무시). 유의수준 조정 아님

# 검정 수행 순서 (iid_main.cpp 기준):
# 1. Most Common Value → H_original, H_bitstring 산출
# 2. Chi-Square Tests (§5.1) → independence + goodness-of-fit
# 3. LRS Test (§5.2) → longest repeated substring
# 4. Permutation Tests (§5.1) → 19종 × 10,000회 순열

# 출력 예 (8비트 심볼, n = 1,000,000):
#   H_original = 7.999124
#   H_bitstring = 0.999891
#   Assessed min entropy: 7.999124
#   ** Passed chi square tests
#   ** Passed length of longest repeated substring test
#   ** Passed IID permutation tests
#   ─────────────────────────────────────────
#   IID 검정 결과: PASS (22종 검정 모두 통과)
#   H_I = 7.999124 bits per symbol (Most Common Value 추정)

# 순열 검정 19종 개별 결과 (-v -v -v 출력):
#   statistic  C[i][0]  C[i][1]  C[i][2]
#   excursion         4987     101    4912
#   numDirectionalRuns 5003      98    4899
#   lenDirectionalRuns 4950     103    4947
#   numIncreasesDecreases 4991    95    4914
#   numRunsMedian     4978     110    4912
#   lenRunsMedian     4985      99    4916
#   avgCollision      5012      87    4901
#   maxCollision      4977     105    4918
#   periodicity(1)    4993      97    4910
#   periodicity(2)    5001     100    4899
#   periodicity(8)    4962      94    4944
#   periodicity(16)   4988     103    4909
#   periodicity(32)   4995      98    4907
#   covariance(1)     4970      99    4931
#   covariance(2)     5005      96    4899
#   covariance(8)     4989     101    4910
#   covariance(16)    4956      94    4950
#   covariance(32)    4991     100    4909
#   compression       4988     103    4909
# 각 행: C[i][0]=원본보다 큰 순열 수, C[i][1]=같은 수, C[i][2]=작은 수
# p-value = min(C[i][0], C[i][2]) / (C[i][0]+C[i][1]+C[i][2]) < 0.001 → 기각

② ea_non_iid — 10가지 추정기 상세 해설

ea_non_iid는 IID 가설이 기각되었거나, FIPS 140-3 요건상 보수적 경로를 선택하는 경우에 사용합니다. 10가지 추정기가 각각 독립적으로 min-entropy H를 추정하고, 그중 가장 낮은 값(최소값)이 해당 엔트로피 소스의 H_I로 채택됩니다. 이 "최소값 채택" 원칙은 어떤 단일 추정기도 놓칠 수 없도록 모든 형태의 구조적 편향을 포착하는 다중 방어선 전략입니다.

아래는 10가지 추정기 각각의 평가 방법, 수학적 공식, 의미, 수치 범위를 상세히 해설한 내용입니다.

1. Most Common Value (MCV) Estimate — §6.3.1

적용 범위: 모든 알파벳 크기 (전체). IID 및 Non-IID 양 경로에서 항상 계산됩니다.

평가 방법: 데이터에서 가장 빈번하게 나타나는 값(최빈값)의 출현 횟수를 세고, 그 비율 p_max에 99.5% 신뢰구간 상한 보정(Z = 2.576, ZALPHA)을 적용하여 min-entropy를 산출합니다. 가장 단순하면서도 가장 보수적인 추정기로, 모든 경로의 기준이 됩니다.

수학적 공식:

p_max = count(most_common_value) / n
/* 99.5% 신뢰구간 상한 (단측) 보정, ZALPHA = 2.576 */
p' = min(1.0, p_max + ZALPHA * sqrt(p_max * (1 - p_max) / (n - 1)))
  /* Z = 2.576 (ZALPHA, utils.h 고정값, 99.5% 신뢰수준) */
H = -log2(p')
/* n = 샘플 수 (1,000,000), p_max = 최빈값 비율 */

의미: 한 값이 전체 데이터에서 차지하는 비율이 높을수록 엔트로피가 낮습니다. 극단적으로 모든 샘플이 동일한 값이면 p_max = 1.0, H = 0 bits가 됩니다. 완벽한 균등분포(8비트, 256값)에서 p_max ≈ 1/256, H ≈ 8.0 bits가 됩니다. 신뢰구간 보정은 표본 크기가 유한할 때의 통계적 불확실성을 보수적으로 반영합니다.

수치 범위: H ∈ [0, log₂(k)] (k = 알파벳 크기). 8비트 심볼: H ∈ [0, 8]. H' = H / 8 ∈ [0, 1]. 신뢰구간 보정으로 인해 이론적 최댓값보다 약간 낮은 값이 산출되는 것이 정상입니다 (예: 7.999 대신 7.998).

2. Collision Estimate — §6.3.2 (바이너리 전용)

적용 범위: 비트스트링(bitstring) 모드 전용. 다비트 심볼에는 적용되지 않습니다.

평가 방법: Hagerty와 Draper[HD12]가 제안한 방법으로, 충돌(동일값 재등장)까지의 간격으로 엔트로피를 추정합니다. 비트 시퀀스에서 충돌 간격 t_i를 기록하고, 표본평균 X̄와 표준편차 σ̂를 구하여 99% 신뢰하한을 산출한 후, 이진 탐색으로 가장 가능성 높은 p를 해석합니다.

수학적 공식:

/* §6.3.2 — Collision Estimate (Hagerty & Draper) */
/* 1. 충돌격 t_i 기록: 같은 값이 다시 나타날 때까지의 샘플 수 */
/* 2. 표본평균 X̄와 표준편차 σ̂ 산출 */
X_bar = (1/v) * sum(t_i);
sigma_hat = sqrt((1/(v-1)) * sum((t_i - X_bar)^2));
/* 3. 99% 신뢰하한 (Z = 2.576) */
X_prime = X_bar - 2.576 * sigma_hat / sqrt(v);
/* 4. 이진 탐색으로 p 해석: X̄' = f(p)를 만족하는 p 찾기 */
/*    f(p)는 Gamma 함수 포함 복잡 수식 (표준 §6.3.2 참조) */
H = -log2(p);  /* 최종 min-entropy 추정값 */

의미: 충돌 간격이 길수록 엔트로피가 높습니다. 무작위 비트열에서 충돌은 기하급수적으로 드물게 발생하며, 편향된 소스에서는 특정 비트 패턴이 빠르게 재등장합니다. 표준 §6.3.2에서 명시적으로 “only applied to binary inputs”라고 규정합니다.

수치 범위: H ∈ [0, 1] (비트당, 비트스트링 모드). 충돌 간격이 길수록 H가 1.0에 가까워집니다. 모든 샘플이 동일하면 충돌 간격 = 1, H ≈ 0.

3. Markov Estimate — §6.3.3 (바이너리 전용)

적용 범위: 비트스트링 모드 전용. 1차 마르코프 체인을 모델링합니다.

평가 방법: 비트 시퀀스를 2상태 마르코프 체인으로 모델링하여, 4가지 전이 확률 P(0→0), P(0→1), P(1→0), P(1→1)을 추정합니다. 인접 비트 간의 순차적 의존성을 정량화합니다.

수학적 공식:

/* 전이 확률 추정 */
P00 = count(0→0) / count(0→*)
P01 = count(0→1) / count(0→*)
P10 = count(1→0) / count(1→*)
P11 = count(1→1) / count(1→*)
P0 = count(0) / n; P1 = count(1) / n

/* 각 상태에서의 조건부 엔트로피 */
H0 = -P00*log2(P00) - P01*log2(P01)
H1 = -P10*log2(P10) - P11*log2(P11)

/* 보정 적용 후 min-entropy */
H = -log2(max(P0 * pow(2, -H0), P1 * pow(2, -H1))) + correction
/* correction = 0.9968... (정규 근사 보정항) */

의미: 현재 비트가 다음 비트에 영향을 미치는 정도를 측정합니다. P(0→0)이 0.5에 가까우면 독립적, 1.0에 가까우면 0에 고착, 0.0에 가까우면 강제 교대 패턴을 의미합니다. 마르코프 추정기는 1차(인접 비트 간) 의존성만 모델링하며, 고차 의존성은 MultiMMC 추정기(#9)에서 처리합니다.

수치 범위: H ∈ [0, 1] (비트당). 독립적 비트열에서 H ≈ 1.0. 완전 상관(P00=P11=1.0)이면 H = 0.0. 강제 교대(P01=P10=1.0)이면 H = 0.0 (다음 비트가 완벽히 예측 가능).

4. Compression Estimate — §6.3.4 (바이너리 전용)

적용 범위: 비트스트링 모드 전용. Lempel-Ziv 76 압축 알고리즘 기반.

평가 방법: LZ76 압축 통계량을 활용하여 데이터의 압축 가능성으로 엔트로피를 추정합니다. 압축이 잘 되는 데이터는 반복 패턴이 존재하여 엔트로피가 낮고, 무작위 데이터는 압축이 되지 않아 엔트로피가 높습니다.

수학적 공식:

/* LZ76 사전 단어 수 계산 */
num_dictionary_words = count_distinct_phrases(LZ76_parse)
/* 평균 사전 단어 길이 */
avg_word_length = n / num_dictionary_words

/* 정규 근사를 통한 엔트로피 추정 */
H = log2(n) / avg_word_length + correction
/* correction: 표본 크기에 따른 편향 보정항 */
/* n이 클수록 보정항이 0에 수렴 */

의미: 압축 가능성 = 예측 가능성 = 낮은 엔트로피. LZ76 파싱은 데이터를 순차적으로 읽으며 "이전에 본 적이 없는" 최소 길이의 구문(phrase)으로 분할합니다. 구문이 짧을수록(많을수록) 데이터가 반복적이고 압축 가능합니다. 반대로 구문이 길수록(적을수록) 데이터가 무작위적입니다.

수치 범위: H ∈ [0, 1] (비트당). 무작위 비트열에서 H ≈ 1.0. 완전히 반복적인 패턴(예: 01010101...)에서는 H가 0에 가까워집니다. avg_word_length가 log₂(n)에 가까우면 H ≈ 1.0.

5. t-Tuple Estimate — §6.3.5

적용 범위: 모든 알파벳 크기 (전체). 다비트 심볼에도 적용 가능.

평가 방법: 각 튜플 길이 t = 1, 2, 3, ...에 대해, 데이터에서 가장 빈번하게 출현하는 t-튜플(t개 연속 샘플)의 빈도를 측정합니다. 다양한 스케일에서 반복 패턴을 탐지합니다.

수학적 공식:

/* 각 튜플 길이 t에 대해 */
for t = 1 to max_t:
    p_max(t) = max_count_of_any_t_tuple / (n - t + 1)
    H(t) = -log2(p_max(t)) / t

/* 보정: 신뢰구간 상한 적용 */
p'(t) = p_max(t) + Z(0.99) * sqrt(p_max(t)*(1-p_max(t))/(n-t))
H'(t) = -log2(p'(t)) / t

H = min(H'(t)) over all t

의미: 특정 길이의 비트 패턴이 반복적으로 출현하면 엔트로피가 저하됩니다. t = 1은 Most Common Value와 동일하고, t = 2, 3, ...은 더 긴 패턴의 반복을 탐지합니다. t가 증가할수록 가능한 튜플 종류가 기하급수적으로 늘어나므로, 의미 있는 최대 t는 데이터 크기에 의해 제한됩니다.

수치 범위: H ∈ [0, log₂(k)] (k = 알파벳 크기). 8비트: H ∈ [0, 8]. 모든 t에 대해 H'(t)를 계산하고 최솟값을 취하므로, 어느 스케일에서든 구조가 발견되면 전체 엔트로피 추정값이 낮아집니다.

6. Longest Repeated Substring (LRS) Estimate — §6.3.6

적용 범위: 모든 알파벳 크기 (전체). 접미 배열(suffix array) 기반 고속 계산.

평가 방법: 데이터에서 2회 이상 출현하는 가장 긴 부분문자열의 길이 W를 찾습니다. 접미 배열(suffix array)과 LCP(Longest Common Prefix) 배열을 구성하여 O(n log n) 시간에 계산합니다 (libdivsufsort 라이브러리 의존).

수학적 공식:

/* W = 최장 반복 부분문자열 길이 */
W = longest_repeated_substring_length(data, n)

/* 엔트로피 추정 (정규화) */
if (W < sqrt(n))
    H = n * log2(n) / (W * (n - W))
else
    H = log2(n) - log2(W)

/* 보정: 표본 크기 편향 보정항 적용 */
H_corrected = H + correction_term(n, W)

의미: 긴 반복 부분문자열은 데이터에 구조적 패턴이 존재한다는 증거입니다. 무작위 데이터에서 이론적 최장 반복 길이는 W ≈ 2·log_k(n) (k = 알파벳 크기)이며, 8비트 심볼 1,000,000샘플에서 W ≈ 2·log₂(1,000,000)/8 ≈ 4~5 정도가 예상치입니다. W가 이보다 유의하게 크면 비-IID입니다.

수치 범위: H ∈ [0, log₂(k)]. 8비트: H ∈ [0, 8]. W가 작을수록 H가 높고, W가 클수록 H가 낮습니다. W = 0 (반복 없음)이면 이론적 최대 H.

7. MultiMCW Prediction Estimate — §6.3.7

적용 범위: 모든 알파벳 크기 (전체). 예측 기반 추정기.

평가 방법: 4개의 서로 다른 윈도우 크기(W = 63, 255, 1023, 4095)에서 각각 가장 최근 윈도우 내의 최빈값(Most Common Value)으로 다음 샘플을 예측합니다. 예측이 적중한 비율로 엔트로피를 추정합니다.

수학적 공식:

/* 4개 윈도우 크기에 대해 독립 예측 */
windows = {63, 255, 1023, 4095}
for W in windows:
    for i = W to n-1:
        prediction = most_common_value(data[i-W..i-1])
        if (data[i] == prediction) correct[W]++

    p_global(W) = correct[W] / (n - W)
    /* 보정: 예측 적중률에 대한 신뢰구간 상한 */
    p'(W) = p_global(W) + correction(W, n)
    H(W) = -log2(p'(W))

H = min(H(W)) over all W

의미: 최근 관찰 윈도우의 최빈값으로 다음 값을 예측합니다. 예측이 잘 맞으면(적중률이 높으면) 최근 경향이 다음 샘플을 결정한다는 의미로 엔트로피가 낮습니다. 4개 윈도우 크기로 단기(63샘플)부터 장기(4095샘플)까지 다양한 시간 스케일의 예측 가능성을 탐지합니다.

수치 범위: H ∈ [0, log₂(k)]. 8비트: H ∈ [0, 8]. 적중률 1/k (무작위)이면 H ≈ log₂(k). 적중률 1.0 (완벽 예측)이면 H = 0.

8. Lag Prediction Estimate — §6.3.8

적용 범위: 모든 알파벳 크기 (전체). 예측 기반 추정기.

평가 방법: 특정 lag d 이전의 샘플 값으로 현재 샘플을 예측합니다. lag d ∈ [1, 128] 범위에서 최적 lag를 탐색하여 가장 보수적인 추정값을 채택합니다.

수학적 공식:

/* 각 lag d에 대해 */
for d = 1 to 128:
    for i = d to n-1:
        prediction = data[i - d]
        if (data[i] == prediction) correct[d]++

    p_lag(d) = correct[d] / (n - d)
    p'(d) = p_lag(d) + correction(d, n)
    H(d) = -log2(p'(d))

H = min(H(d)) over d ∈ [1, 128]

의미: 주기적/순환 패턴을 탐지합니다. 특정 간격 d 이전의 값이 현재 값을 잘 예측한다면, 데이터에 주기 d의 순환 구조가 존재한다는 의미입니다. 예: 매 10번째 샘플이 항상 같은 값이면 lag = 10에서 적중률이 높게 나타납니다.

수치 범위: H ∈ [0, log₂(k)]. 8비트: H ∈ [0, 8]. 128개 lag 중 가장 보수적인 값이 채택되므로, 어느 주기에서든 순환 구조가 발견되면 전체 추정값이 낮아집니다.

9. MultiMMC Prediction Estimate — §6.3.9

적용 범위: 모든 알파벳 크기 (전체). 예측 기반 추정기. Markov Estimate(#3)의 일반화.

평가 방법: 다양한 차수 d ∈ {16, 64, 256}의 마르코프 모델(Multi-Step Markov Model with Correction)을 구축합니다. 이전 d개 샘플이 다음 샘플을 예측하는 정도를 측정합니다. Markov Estimate가 1차(인접 비트 간)만 모델링하는 반면, MultiMMC는 고차 의존성을 탐지합니다.

수학적 공식:

/* 차수 d의 마르코프 모델 구축 */
orders = {16, 64, 256}
for d in orders:
    /* d개 이전 샘플로 구성된 상태 → 다음 샘플 예측 */
    for i = d to n-1:
        context = data[i-d..i-1]
        prediction = most_common_next_value(context)
        if (data[i] == prediction) correct[d]++

    p(d) = correct[d] / (n - d)
    /* Correction: 관측되지 않은 상태의 불확실성 반영 */
    p'(d) = p(d) + correction_mmc(d, n, alphabet_size)
    H(d) = -log2(p'(d))

H = min(H(d)) over d ∈ {16, 64, 256}

의미: 이전 d개 샘플의 패턴(문맥)이 다음 샘플을 예측하는 정도를 측정합니다. 차수가 높을수록 더 긴 패턴의 의존성을 탐지할 수 있지만, 동시에 가능한 상태 수가 k^d로 기하급수적으로 늘어나 통계적 신뢰도가 낮아집니다. 3개 차수 중 가장 보수적인 값을 채택합니다.

수치 범위: H ∈ [0, log₂(k)]. 8비트: H ∈ [0, 8]. 고차 의존성이 존재하면 특정 차수에서 예측 적중률이 높아져 H가 낮아집니다.

10. LZ78Y Prediction Estimate — §6.3.10

적용 범위: 모든 알파벳 크기 (전체). 예측 기반 추정기. LZ78 압축 알고리즘 변형.

평가 방법: LZ78 사전(Dictionary) 구축 방식을 예측에 응용합니다(Y 변형). 관찰된 패턴으로 사전을 구축하고, 사전에서 가장 길게 매칭되는 패턴의 다음 값으로 다음 샘플을 예측합니다. Compression Estimate(#4)의 압축 기반 접근을 예측 기반으로 전환한 것입니다.

수학적 공식:

/* LZ78Y 사전 구축 + 예측 */
dictionary = {}  /* LZ78 사전 */
max_dict_size = pow(2, 16)  /* 최대 사전 크기 */

for i = 0 to n-1:
    /* 현재 위치에서 가장 길게 매칭되는 사전 패턴 탐색 */
    match = longest_match(data[0..i-1], data[i..])
    if (match.next_value == data[i]) correct++

    /* 사전 갱신 (Y 변형: preload length 조정) */
    if (dictionary.size < max_dict_size)
        dictionary.insert(data[i..i+match.length])

p = correct / n
p' = p + correction_lz78y(n, alphabet_size)
H = -log2(p')

의미: LZ78 압축 알고리즘의 사전 구축 방식을 예측에 응용합니다. 압축 가능한 데이터(반복 패턴 존재)는 사전 기반 예측이 잘 되므로 엔트로피가 낮게 추정됩니다. LZ78Y는 LZ78의 변형으로, 사전 preload 길이와 매칭 전략을 조정하여 예측 정확도를 높입니다. 사전 크기가 2¹⁶ = 65,536에 도달하면 더 이상 갱신하지 않습니다.

수치 범위: H ∈ [0, log₂(k)]. 8비트: H ∈ [0, 8]. 예측 적중률이 1/k(무작위)이면 H ≈ log₂(k). 적중률 1.0(완벽 예측)이면 H = 0.

③ ea_restart — 재시작 테스트 세부 항목

ea_restart는 엔트로피 소스가 재시작(전원 차단 후 재인가, 리부트 등) 후에도 동일한 엔트로피 품질을 유지하는지 검증합니다. 핵심 우려는 초기 조건 의존성 — 하드웨어 엔트로피 소스가 부팅 시 항상 비슷한 초기 상태에서 시작한다면, 재시작 후 첫 출력이 매번 비슷해지는 치명적 보안 취약점이 됩니다.

데이터 형식 (§3.1.4.1): 재시작 테스트는 1,000×1000 재시작 행렬 M을 요구합니다. 엔트로피 소스를 r = 1,000회 재시작하고, 각 재시작에서 c = 1,000연속 샘플을 수집합니다. M[i][j]는 i번째 재시작의 j번째 샘플입니다. 이 행렬로부터 두 개의 데이터셋을 구성합니다:

• Row dataset: 행을 순서대로 연결 — M[1][1]‖...‖M[1][1000]‖M[2][1]‖...‖M[2][1000]‖...‖M[1000][1]‖...‖M[1000][1000]
• Column dataset: 열을 순서대로 연결 — M[1][1]‖...‖M[1000][1]‖M[1][2]‖...‖M[1000][2]‖...‖M[1][1000]‖...‖M[1000][1000]

ea_transpose 유틸리티로 순차 데이터를 row dataset 형식으로 변환할 수 있습니다. 단, 실제 인증에서는 진짜 재시작 데이터(1,000회 재부팅)를 수집해야 합니다.

평가 항목 3종 (§3.1.4.2~§3.1.4.3):

# 1단계: 1,000회 재시작 데이터 수집 (각 1,000샘플)
# 하드웨어를 1,000회 재부팅하며 각 부팅 후 1,000바이트씩 수집
# → restart_data.bin (1,000,000바이트 = 1,000행 × 1,000열 행렬 M)

# 2단계: ea_non_iid로 순차 데이터 H_I 산출 (별도 수행)
./ea_non_iid -i sequential_data.bin 8
# → H_I = 7.998 bits per symbol

# 3단계: ea_restart 실행 — H_I를 인자로 전달
./ea_restart -n restart_data.bin 8 7.998
# -n: non-IID 경로, 8 = bits_per_symbol, 7.998 = H_I (순차 검증 결과)

# 수행 순서 (표준 §3.1.4.2):
# 1. Sanity check (§3.1.4.3) — 행/열 최빈값 빈도 검정
# 2. Row dataset 엔트로피 추정 → H_r
# 3. Column dataset 엔트로피 추정 → H_c

# 출력 예:
#   Sanity check: Passed
#   Row dataset entropy: H_r = 7.876 bits per symbol
#   Column dataset entropy: H_c = 7.912 bits per symbol
#   min(H_r, H_c) = 7.876, H_I / 2 = 3.999
#   ─────────────────────────────────────────
#   Restart test result: PASS (min(H_r, H_c) ≥ H_I / 2)
#   Final entropy = min(H_r, H_c, H_I) = min(7.876, 7.912, 7.998) = 7.876

# IID 경로로 재시작 테스트 (ea_iid 통과한 소스만)
./ea_restart -i restart_data.bin 8 7.999
# -i: IID 경로, 마지막 인자는 ea_iid 결과 H_I

④ ea_conditioning — 컨디셔닝 검증 세부 항목

ea_conditioning은 컨디셔닝(Conditioning) 컴포넌트 — 원시 엔트로피 출력의 편향을 제거하고 엔트로피를 집중시키는 후처리 단계 — 의 엔트로피 감소량을 산정합니다. SP 800-90B §3.1.5는 컨디셔닝을 vetted(검증됨, §3.1.5.1)와 non-vetted(검증되지 않음, §3.1.5.2) 두 종류로 분류합니다.

# Vetted 컨디셔닝 검증 (예: HMAC-SHA-256 기반)
./ea_conditioning -v 256 256 256 240.0
# -v: vetted 모드
# n_in=256, n_out=256, n_w=256, h_in=240.0
# → h_out = Output_Entropy(256, 256, 256, 240.0)
# Output_Entropy() 다단계 수식으로 정확한 h_out 산출 (libmpfr·libgmp 임의 정밀도 연산)

# 출력 예:
#   Vetted Conditioning Component
#   n_in = 256, n_out = 256, n_w = 256
#   h_in = 240.000 bits
#   h_out = 239.987 bits (Output_Entropy 산출값)

# Non-vetted 컨디셔닝 검증 (예: von Neumann 추출기)
./ea_conditioning -n 256 256 8 240.0 0.98
# -n: non-vetted 모드, h'=0.98 (컨디셔닝된 데이터셋에서 산출한 비트당 엔트로피)
# → h_out = min(Output_Entropy(256,256,8,240.0), 0.999×256, 0.98×256)
#         = min(Output_Entropy(...), 255.744, 250.88)
# 0.999×n_out 항으로 인해 full entropy(256비트) 주장 불가

# h' 추정: 별도로 컨디셔닝된 데이터 샘플 수집 후
./ea_non_iid -c -t conditioned_sample.bin 1
# 컨디셔닝된 데이터를 비트스트링으로 평가 → h' = H_bitstring 산출

⑤ ea_transpose — 데이터 전치 유틸리티

ea_transpose는 평가 도구가 아닌 전처리 유틸리티입니다. ea_restart가 요구하는 row dataset(1,000행 × 1,000열) 형식으로 순차 원시 데이터를 변환합니다. 별도의 평가 항목은 없으며, 1,000,000바이트 순차 데이터를 1,000바이트씩 1,000행으로 재구성합니다.

# 순차 데이터를 row dataset으로 변환
./ea_transpose sequential_data.bin restart_data.bin
# 입력: 1,000,000바이트 순차 데이터
# 출력: 1,000행 × 1,000열 row dataset (동일 1,000,000바이트, 2차원 재구성)

# 실제 재시작 데이터를 수집한 경우 변환 불필요
# (각 재부팅 후 1,000바이트씩 순차 저장하면 이미 row dataset 형식)

NIST ESV Server (공식 검증 서버)

SP 800-90B 인증서를 실제로 발급받으려면 NIST의 ESVTS(Entropy Source Validation Test System)에 엔트로피 소스 데이터를 제출해야 합니다. ESVTS는 ACVP(Automated Cryptographic Validation Protocol) 기반의 ESVP(Entropy Source Validation Protocol) API를 제공하며, 내부적으로 위 SP 800-90B Entropy Assessment Library를 실행해 엔트로피 추정치를 산출합니다. 같은 서버가 SP 800-90C RBG(Random Bit Generator) 구성 적합성 제출도 처리합니다.

Python 포트 — sp800_90b

sp800_90b는 NIST 공식 C++ 코드를 pybind11로 래핑한 Python 패키지로, 오프라인 개발·CI(Continuous Integration) 자동화에서 SP 800-90B 평가를 스크립트로 호출할 때 사용합니다. NIST 원본 코드를 nist_impl 서브모듈로 포함해 동일한 알고리즘 결과를 내며, sp800_90b.Data 클래스로 .iid_tests(), .h_initial() 등을 직접 호출할 수 있습니다. PyPI 패키지명은 sp800-90b입니다.

# Python 포트 설치 (PyPI)
pip install sp800-90b

# 또는 소스 빌드 — NIST C++ 서브모듈 포함
git clone https://github.com/hnj2/sp800_90b.git
cd sp800_90b
git submodule init && git submodule update
pip install setuptools pybind11
python setup.py build && python setup.py install

import random, sp800_90b

# 1,000,000바이트 난수 샘플 생성
r = bytes(random.getrandbits(8) for _ in range(1000000))
rd = sp800_90b.Data(r)

# IID 검정 — 순열 검정 19종 수행
print(rd.iid_tests())       # True = IID 가설 기각 불가
print(rd.h_initial())       # 7.189... (bits per symbol)

dieharder 통계 배터리 전체 실행

# dieharder 설치
apt-get install dieharder   # Ubuntu/Debian
dnf install dieharder       # Fedora/RHEL

# 전체 배터리 실행 (114개 통계 검정, 수 시간 소요)
cat /dev/hwrng | dieharder -a -g 200
# -a: 모든 테스트, -g 200: stdin 입력
# 결과: PASSED/WEAK/FAILED — WEAK는 5% 이내 정상

# 특정 테스트만 실행 (빠른 검증)
cat /dev/hwrng | dieharder -d 0 -g 200    # Birthday Spacings
cat /dev/hwrng | dieharder -d 15 -g 200   # RGB Bit Distribution
cat /dev/hwrng | dieharder -d 100 -g 200  # STS Monobit

# ENT 도구 — 빠른 엔트로피 추정
dd if=/dev/hwrng bs=1M count=1 | ent
# Entropy: 7.9999 bits per byte  → 이상적 난수 표본
# Chi-square: 적합 확률 50%      → 정상 분포
# Arithmetic mean: 127.49        → 균등 분포 (이론: 127.5)
# Serial correlation: 0.000001  → 독립성 확인

드라이버 로드/언로드 검증 체크리스트

엔트로피 풀 구조 심층 분석

Linux 커널의 엔트로피 풀은 drivers/char/random.c에 구현된 핵심 난수 인프라의 심장부입니다. 커널 5.6 이전에는 input_pool과 blocking_pool 두 개의 풀이 존재했지만, 5.6에서 blocking_pool이 제거되어 input_pool 단일 구조가 되었고, 5.17에서는 기존 LFSR + SHA-1 기반 믹싱이 Blake2s 해시 함수로 완전 교체되었습니다. 이 섹션에서는 풀의 내부 구조, 믹싱 알고리즘, 엔트로피 추정 메커니즘을 심층적으로 분석합니다.

풀 구조의 진화: LFSR에서 Blake2s로

믹싱 알고리즘 상세

/* drivers/char/random.c — 현대 커널 엔트로피 풀 구조 */

/* 전역 엔트로피 풀 — Blake2s 해시 상태 */
static struct {
    struct blake2s_state hash;      /* 256비트 내부 상태 */
    spinlock_t lock;                /* 동시 접근 보호 */
    unsigned int init_bits;         /* 누적 엔트로피 비트 수 */
} input_pool = {
    .hash.h = { BLAKE2S_IV0 ^ (0x01010000 | 32),
                BLAKE2S_IV1, BLAKE2S_IV2, BLAKE2S_IV3,
                BLAKE2S_IV4, BLAKE2S_IV5, BLAKE2S_IV6, BLAKE2S_IV7 },
    .hash.outlen = 32,
    .lock = __SPIN_LOCK_UNLOCKED(input_pool.lock),
};

/* 믹싱 함수 — 엔트로피를 풀에 혼합 (비가역적) */
static void _mix_pool_bytes(const void *buf, size_t len)
{
    unsigned long flags;

    spin_lock_irqsave(&input_pool.lock, flags);
    blake2s_update(&input_pool.hash, buf, len);
    spin_unlock_irqrestore(&input_pool.lock, flags);
}

/* 엔트로피 추출 — 풀 상태를 변경하며 32바이트 키 생성 */
static void extract_entropy(void *buf, size_t len)
{
    unsigned long flags;
    u8 hash[BLAKE2S_HASH_SIZE];
    struct blake2s_state state;

    spin_lock_irqsave(&input_pool.lock, flags);

    /* 1. 현재 풀 상태의 스냅샷 생성 */
    state = input_pool.hash;

    /* 2. 스냅샷에서 최종 해시 계산 (256비트) */
    blake2s_final(&state, hash);

    /* 3. 출력 해시를 풀에 재혼합 → backtrack resistance */
    blake2s_update(&input_pool.hash, hash, sizeof(hash));

    spin_unlock_irqrestore(&input_pool.lock, flags);

    memcpy(buf, hash, len);
    memzero_explicit(hash, sizeof(hash));
    memzero_explicit(&state, sizeof(state));
}

/* 엔트로피 크레딧 — init_bits 누적 (256비트 목표) */
static void credit_init_bits(size_t bits)
{
    unsigned int new_bits, orig;
    unsigned long flags;

    if (!bits)
        return;

    spin_lock_irqsave(&input_pool.lock, flags);
    orig = input_pool.init_bits;
    new_bits = min_t(unsigned int, POOL_READY_BITS,
                     orig + bits);  /* 최대 256비트까지만 */
    WRITE_ONCE(input_pool.init_bits, new_bits);
    spin_unlock_irqrestore(&input_pool.lock, flags);

    /* 256비트 도달 시 CRNG 초기화 트리거 */
    if (orig < POOL_READY_BITS && new_bits >= POOL_READY_BITS)
        crng_reseed();
}

엔트로피 추정과 크레딧 정책

커널은 각 소스별로 다른 엔트로피 크레딧 정책을 적용합니다. hwrng의 경우 quality 파라미터가 직접적으로 크레딧 계산에 사용됩니다.

RDSEED vs RDRAND 비교 분석

Intel x86 프로세서는 두 가지 하드웨어 난수 명령어를 제공합니다: RDRAND(Ivy Bridge, 2012~)와 RDSEED(Broadwell, 2014~). 두 명령어는 같은 하드웨어 엔트로피 소스(열잡음 기반 디지털 난수 생성기)를 공유하지만, 출력 방식과 암호학적 보증이 근본적으로 다릅니다.

RDRAND 내부 동작

/* arch/x86/include/asm/archrandom.h — RDRAND 인라인 어셈블리 */

static inline bool rdrand_long(unsigned long *v)
{
    bool ok;
    unsigned int retry = RDRAND_RETRY_LOOPS;  /* 기본 10회 */

    do {
        asm volatile(RDRAND_LONG
                     "\n\t"
                     CC_SET(c)      /* CF=1이면 유효한 난수 */
                     : CC_OUT(c)(ok), "=a"(*v));
        if (ok)
            return true;
    } while (--retry);
    return false;  /* DRNG 내부 고갈 — 매우 드뭄 */
}

/* RDSEED — 순수 하드웨어 엔트로피 (DRBG 미경유) */
static inline bool rdseed_long(unsigned long *v)
{
    bool ok;
    asm volatile(RDSEED_LONG
                 "\n\t"
                 CC_SET(c)      /* CF=1이면 유효한 시드 */
                 : CC_OUT(c)(ok), "=a"(*v));
    return ok;  /* 실패 확률이 RDRAND보다 높음 */
}

/* 커널 엔트로피 수집에서의 사용 — random.c */
static void try_to_generate_entropy(void)
{
    unsigned long v;

    /* RDSEED 우선 시도 (순수 엔트로피) */
    if (rdseed_long(&v)) {
        _mix_pool_bytes(&v, sizeof(v));
        credit_init_bits(sizeof(v) * 8);  /* 64비트 크레딧 */
        return;
    }

    /* RDSEED 실패 시 RDRAND 폴백 (DRBG 경유) */
    if (rdrand_long(&v)) {
        _mix_pool_bytes(&v, sizeof(v));
        /* CONFIG_RANDOM_TRUST_CPU=y 설정 시에만 크레딧 부여 */
    }
}

RDRAND vs RDSEED 상세 비교표

FIPS 140-2/140-3 인증과 커널 RNG

FIPS 140(Federal Information Processing Standard 140)은 미국 연방 정부가 요구하는 암호 모듈 보안 표준입니다. Linux 커널은 CONFIG_CRYPTO_FIPS 옵션과 fips=1 부트 파라미터를 통해 FIPS 모드를 지원하며, 이 모드에서는 RNG 관련 추가 요구사항이 활성화됩니다.

FIPS 모드 커널 설정

/* crypto/fips.c — FIPS 모드 전역 플래그 */
int fips_enabled;
EXPORT_SYMBOL_GPL(fips_enabled);

/* 부팅 파라미터: fips=1 → FIPS 모드 활성화 */
static int __init fips_enable(char *str)
{
    fips_enabled = simple_strtol(str, NULL, 0);
    printk(KERN_INFO "fips mode is %s\n",
           fips_enabled ? "enabled" : "disabled");
    return 1;
}
__setup("fips=", fips_enable);

/* FIPS 모드에서의 RNG 셀프 테스트 */
/* crypto/testmgr.c — alg_test_drbg() */
static int alg_test_drbg(const struct alg_test_desc *desc,
                          const char *driver, u32 type, u32 mask)
{
    int err = 0;
    int i;
    const struct drbg_testvec *tv;

    /* 알려진 응답 테스트(KAT): 고정 시드 → 고정 출력 비교 */
    for (i = 0; i < desc->suite.drbg.count; i++) {
        tv = &desc->suite.drbg.vecs[i];
        err = drbg_cavs_test(tv, desc->alg_common.cra_driver_name);
        if (err) {
            pr_err("DRBG KAT 실패 #%d: %s\n", i, driver);
            return err;
        }
    }
    return 0;
}

FIPS DRBG 요구사항과 커널 구현 매핑

KCMVP(한국 암호모듈 검증프로그램)와 커널 RNG

KCMVP(Korea Cryptographic Module Validation Program)는 국가정보원(NIS, National Intelligence Service)이 운영하는 한국의 암호모듈 검증 제도입니다. 미국 FIPS 140과 동일한 ISO/IEC 19790을 기반 표준으로 채택하면서, 한국 고유 암호 알고리즘(ARIA, SEED, LEA, LSH, KCDSA, EC-KCDSA)과 한국 표준(TTAK)을 검증 대상으로 추가한 것이 핵심 특징입니다. 이 섹션에서는 KCMVP의 난수발생기 관련 요구사항과 Linux 커널 hwrng 서브시스템의 관계를 분석합니다.

KCMVP 법적 근거 및 기반 표준

KCMVP는 국가·공공망에서 사용되는 암호모듈의 안전성과 구현 적합성을 검증합니다. 정보보호시스템(DB 암호화, VPN, SSO, DRM 등)에 KCMVP 검증필 암호모듈 탑재가 필수이며, 이는 FIPS 140이 미국 연방 정부에 요구하는 것과 동일한 구조입니다.