Files
llm-wiki/raw/company-tech-blogs/privacy-pseudonymization-hmac-vs-tokenization-iapp.md
T

9.8 KiB

title, source_type, status, confidence, url, archive_url, tags, related_branches, related_projects, created, last_reviewed
title source_type status confidence url archive_url tags related_branches related_projects created last_reviewed
IAPP / ENISA — Pseudonymization techniques (HMAC vs tokenization) company-tech-blog raw medium https://www.enisa.europa.eu/publications/pseudonymisation-techniques-and-best-practices
privacy
pseudonymization
hmac
tokenization
enisa
ca-skeleton
feature-data-retention-privacy-contract
ca-skeleton-operational-contract
2026-05-22 2026-05-27

ENISA / IAPP — Pseudonymisation techniques and best practices (HMAC vs tokenization)

Layer: raw/company-tech-blogs/ — ENISA (EU Agency) 의 pseudonymisation 가이드 + IAPP 의 operational impacts 해설을 결합. ca-tmpl HMAC-SHA-256 + 90d salt rotation 결정의 비교 reference. 주의: ENISA 자체는 EU agency publication 이나, IAPP 는 industry/professional association — 본 raw 는 둘을 함께 묶어 보관하므로 company-tech-blog 로 분류 (공식 표준이 아닌 best-practice 가이드 성격).

Parent / 활용 branch (필수)

Branch 이 자료가 정당화하는 결정
raw/branch-notes/feature-data-retention-privacy-contract ca-tmpl 의 HMAC-SHA-256 + 90d salt rotation 채택 결정의 비교 reference (tokenization / FPE 대안과의 trade-off)
raw/project-notes/ca-skeleton-operational-contract ca-tmpl Group G-J 의 pseudonymization 알고리즘 선택 input

컨텍스트

ca-tmpl 이 HMAC-SHA-256 + 90일 salt rotation 을 선택한 근거. 대안으로 (1) tokenization service (Vault Transform, AWS Tokenization), (2) format-preserving encryption (FF1/FF3), (3) deterministic encryption 이 있고 각자 trade-off 가 다름. ENISA 는 EU 공식 가이드 이나 industry best-practice 성격으로, IAPP 는 professional association 의 operational 해설.

출처 / Source

핵심 인용 / Key quotes (verbatim)

[§ENISA — keyed-hash technique] "A keyed-hash function with a secret key (e.g., HMAC-SHA-256) is a basic but effective pseudonymisation technique. However, when the same key is used for a long period, it becomes vulnerable to dictionary attacks if the input space is small (e.g., phone numbers)."

[§ENISA — salt rotation] "Salt rotation and periodic re-pseudonymisation reduce the risk of cross-dataset linkage attacks."

[§IAPP — tokenization] "Tokenization replaces sensitive data with non-sensitive tokens, while the mapping is stored in a secure vault. Unlike encryption, the token has no mathematical relationship to the original."

[§ENISA — choice criteria] "The choice between hashing-based and tokenization-based pseudonymisation depends on (a) need for reversibility, (b) collision tolerance, (c) operational simplicity, (d) attack surface of the lookup table."

Claims Extracted / 추출된 주장

Claim ID Claim (이 자료가 직접 말하는 것) Evidence quote Strength Applies to Does not prove
ENISA-PSE-C1 HMAC-SHA-256 같은 keyed-hash function 은 basic 하지만 effective 한 pseudonymisation 기법이며, 동일 key 를 장기간 사용 하면 input space 가 좁을 때 (예: 휴대폰 번호) dictionary attack 에 취약 [§ENISA — keyed-hash technique] "A keyed-hash function with a secret key (e.g., HMAC-SHA-256) is a basic but effective pseudonymisation technique. However, when the same key is used for a long period, it becomes vulnerable to dictionary attacks if the input space is small (e.g., phone numbers)." engineering-blog pseudonymisation 알고리즘 선택 시 input space 평가 90일 salt rotation 이 충분한 mitigation 인지는 본 인용 범위 밖 — "장기간" 의 정량 기준이 없음
ENISA-PSE-C2 salt rotation 과 periodic re-pseudonymisation 은 cross-dataset linkage attack 의 risk 를 감소시킴 [§ENISA — salt rotation] "Salt rotation and periodic re-pseudonymisation reduce the risk of cross-dataset linkage attacks." engineering-blog 다중 dataset 이 동일 식별자를 공유할 수 있는 환경 rotation 주기 (30d / 90d / 1y) 의 권장값을 본 인용은 제시하지 않음
ENISA-PSE-C3 tokenization 은 sensitive data 를 non-sensitive token 으로 치환 하고 mapping 은 secure vault 에 저장. encryption 과 달리 token 은 원본과 수학적 관계 없음 [§IAPP — tokenization] "Tokenization replaces sensitive data with non-sensitive tokens, while the mapping is stored in a secure vault. Unlike encryption, the token has no mathematical relationship to the original." engineering-blog vault-backed tokenization service (Vault Transform / AWS Tokenization 류) tokenization 이 모든 시나리오에서 hashing 보다 우월하다는 뜻은 아님 — choice criteria (ENISA-PSE-C4) 참조
ENISA-PSE-C4 hashing-based 와 tokenization-based pseudonymisation 의 선택은 (a) reversibility 필요성, (b) collision tolerance, (c) operational simplicity, (d) lookup table attack surface 4가지에 의존 [§ENISA — choice criteria] "The choice between hashing-based and tokenization-based pseudonymisation depends on (a) need for reversibility, (b) collision tolerance, (c) operational simplicity, (d) attack surface of the lookup table." engineering-blog pseudonymisation 알고리즘 선택의 의사결정 framework 4가지 외의 요소 (예: GDPR Art.17 backup erasure 호환성, latency, cost) 가 무시 가능하다는 뜻은 아님

Usage Boundaries / 적용 경계

  • 이 자료가 직접 증명하는 것:
    • ENISA-PSE-C1: HMAC + 장기 key 사용 시 small input space 에서의 dictionary attack 취약성
    • ENISA-PSE-C2: salt rotation 의 cross-dataset linkage attack 완화 효과 (정성적)
    • ENISA-PSE-C3: tokenization 의 정의 (vault-backed, no mathematical relationship)
    • ENISA-PSE-C4: 알고리즘 선택의 4가지 결정 기준
  • 이 자료가 증명하지 않는 것:
    • ca-tmpl 의 90일 salt rotation 이 ENISA 권장값이라는 점 — ENISA 는 정량 주기를 본 인용에서 제시하지 않음
    • HMAC-SHA-256 이 GDPR Art.17 backup 단건 erasure 를 충족 — 별도 cryptographic erase 결합 필요 (NIST-CE-C1 참조)
    • tokenization service outage 시 운영 영향의 정량 평가
    • FF3-1 의 Hoang et al. 2017 attack 의 본 자료 직접 언급 — 별도 NIST SP 800-38G 가이드 보강 필요
    • 본 자료를 공식 best practice 로 인용할 수 없음 — ENISA 는 가이드, IAPP 는 industry association. CLAUDE.md §5 company-tech-blog 정책에 따라 "사례/관점" 으로만 사용 가능
  • 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
    • 90일 salt rotation 의 적정성을 ca-tmpl 의 input space (휴대폰 번호, 이메일 hash 등) 별로 정량 평가
    • tokenization service 채택 시 vault outage 의 SLA 영향 분석
    • SHA-256 truncation (예: 64-bit prefix) 사용 시 collision rate 재계산
    • ENISA PDF 본문 verbatim 의 직접 대조 (WebFetch metadata 만 노출됨)

메모

  • ca-tmpl 의 HMAC-SHA-256 결정 분석 (자료 직접 인용 아님):
    • 장점: stateless (lookup table 불필요), 빠름, key rotation 으로 forward secrecy 일부 확보.
    • 단점: input space 가 작으면 (예: 한국 휴대폰 11자리) brute-force attack 가능. salt rotation 으로 완화하나 old salt 90일 retain → 그 기간 동안 동일 plaintext 가 동일 token 으로 mapping.
  • 대안 1: Tokenization service (Vault Transform / AWS DynamoDB Encryption SDK)
    • 장점: brute-force 불가 (random token), reversal 은 vault 접근권한자만.
    • 단점: vault outage = pseudonymization 자체가 unavailable, per-request latency 추가.
  • 대안 2: Format-preserving encryption (FF1/FF3-1, NIST SP 800-38G)
    • 장점: 원본과 동일 format (DB schema 변경 없이 in-place pseudonymization).
    • 단점: 키 관리 복잡, FF3-1 은 일부 attack 발견 사례 있음 (Hoang et al. 2017).
  • ca-tmpl 의 "collision rate < 1e-9" 가정은 SHA-256 출력 길이 (256-bit) 에서 birthday bound ≈ 2^128 → 통상 운영 dataset 에서는 충분. 단 truncation 시 (예: 64-bit prefix) 재계산 필요.
  • old salt 90일 retain 은 ENISA 가 권장하는 "periodic re-pseudonymisation" 과 호환. 단 90일은 ca-tmpl 자체 결정값이고 ENISA 가 90일을 권장한 것은 아님.