형태보존 암호화 FPE: 데이터 형식을 유지하는 암호화 방식
형태보존 암호화(FPE)의 동작 구조와 Feistel 네트워크, FF1·FF3-1 알고리즘, 형식 보존이 필요한 데이터 보호 시 고려할 사항을 정리한다.
2026-08-14 · 최초 발행 2025-05-23
형식 자체가 인터페이스인 데이터를 암호화할 때
형태보존 암호화(Format Preserving Encryption, FPE)는 암호문이 평문과 같은 형식과 구조를 유지하도록 만드는 암호화 방식이다. 길이와 문자 유형을 보존하므로, 숫자·알파벳처럼 정해진 문자 집합과 형식을 가진 데이터를 보호하면서 기존 시스템의 호환성을 유지할 수 있다.
2016년 NIST에서 표준화됐으며, FF1·FF3·FF3-1이 대표적인 알고리즘이다. 데이터베이스 스키마나 형식 검증 로직을 대폭 수정하기 어려운 곳에서 정보보호와 시스템 연계를 함께 다루기 위한 선택지가 된다.
FPE는 적절한 키가 있어야 복호화할 수 있는 가역 암호화다. 특정 문자 집합 또는 형식으로 도메인을 제한할 수 있고, 트윅(Tweak)을 사용하면 같은 평문과 키를 사용하더라도 서로 다른 암호문을 만들 수 있다. 무차별 대입 공격 등에 대한 내성도 고려 대상이다.
숫자 도메인으로 옮긴 뒤 다시 원래 형식으로 돌린다
FPE 처리 흐름은 평문을 도메인에 맞는 숫자로 매핑하고, Feistel 네트워크에서 키와 트윅을 사용해 암호화한 뒤, 결과를 다시 원래 형식으로 되돌리는 방식으로 볼 수 있다.
랭킹 함수(Ranking Function)는 입력 데이터를 숫자 도메인으로 옮긴다. 예를 들어 신용카드 번호 4111-2222-3333-4444를 숫자 값으로 매핑할 수 있다. 역랭킹 함수(Inverse Ranking Function)는 이 숫자 값을 원래 형식으로 복원하며, 랭킹 함수의 역연산을 수행한다.
트윅은 암호화 과정에 더하는 부가 정보다. 고객 ID나 트랜잭션 ID 등을 트윅으로 활용할 수 있으며, 같은 평문과 키의 조합에서도 서로 다른 암호문을 생성하게 한다. 형변환 함수는 데이터 형식 사이의 변환을 담당하고, 암호화 키는 권한 있는 사용자만 원본에 접근할 수 있도록 보호해야 한다.
Feistel 네트워크에서 트윅을 반영하는 방식
FPE는 주로 균형 Feistel 네트워크(Balanced Feistel Network)를 사용한다. 입력을 좌측(L)과 우측(R) 절반으로 나누고, 각 라운드에서 한쪽은 통과시키며 다른 한쪽에는 함수 F와 XOR 연산을 적용한다. 이때 트윅(T)은 함수 F의 추가 입력으로 사용된다.
충분한 라운드를 거쳐 보안성을 확보하며, 처리 결과는 처음 입력이 가진 데이터 형식에 맞게 다시 표현된다.
형식 검증과 연동을 유지해야 하는 데이터
신용카드 번호를 보호할 때는 4111-2222-3333-4444를 4893-5467-2198-7654처럼 암호화할 수 있다. 16자리 숫자 형식을 유지하고, Luhn 알고리즘 검증 가능성을 보존하며, 기존 결제 시스템과의 호환성을 확보할 수 있다.
주민등록번호도 800101-1234567을 870523-1876543처럼 바꿔 형식을 유지할 수 있다. 기존 검증 로직을 계속 사용할 수 있고, 데이터베이스 구조 변경이나 응용프로그램 수정의 부담을 줄일 수 있다.
의료 영역에서는 환자 ID와 의료보험 번호 같은 민감 정보를 암호화하면서 데이터 분석 과정의 형식 일관성을 유지할 수 있다. 금융거래 내역에서는 계좌번호와 거래금액 등을 보호하고, 형식과 길이를 유지해 시스템 변경을 최소화할 수 있다. 거래별 트윅을 적용하면 차별화된 암호화도 가능하다.
FF1과 FF3-1의 적용 범위
FF1은 NIST SP 800-38G에서 표준화된 FPE 알고리즘이다. 임의 기수(radix)와 길이의 데이터 암호화가 가능하며, AES 기반 PRF(의사 난수 함수)를 사용한다.
FF3은 초기 표준이고 FF3-1은 이를 개선한 버전이다. 트윅 길이는 최대 7 바이트로 제한되며, FF1보다 구현이 단순하고 효율적이다. 짧은 데이터에 최적화돼 있다.
호환성의 이점과 형식 보존의 제약
FPE를 적용하면 기존 시스템 변경을 최소화하고, 데이터 타입과 길이 제약조건을 포함한 데이터베이스 스키마를 유지할 수 있다. Luhn 알고리즘 같은 형식 기반 검증 로직도 통과 가능하며, 데이터의 일부만 선택적으로 암호화할 수 있다. 트윅을 활용하면 같은 평문에서도 다른 암호문을 생성해 의미론적 보안을 지원한다.
반면 형식을 보존해야 하므로 엔트로피가 제한될 수 있다. 일반 암호화보다 구현이 복잡하고, 추가 변환 과정에서 성능 오버헤드가 발생한다. 특정 형식과 길이의 데이터에 최적화된다는 도메인 제한도 함께 고려해야 한다.
구현 과정에서 함께 설계할 항목
데이터 길이와 형식, 보안 요구사항을 기준으로 FF1 또는 FF3-1 같은 알고리즘을 선택한다. 트윅은 트랜잭션 ID나 테이블명처럼 선택 기준을 정하고, 트윅을 분실했을 때의 복구 방안도 마련해야 한다.
키는 안전하게 생성하고 저장해야 하며, 정기적인 키 교체 메커니즘이 필요하다. 성능 측면에서는 캐싱 전략과 병렬 처리 가능성을 검토할 수 있다. PCI DSS, GDPR 등 관련 규제와 감사 요구사항도 적용 환경에 맞춰 확인해야 한다.
양자 컴퓨팅 시대를 대비한 양자 내성 FPE, IoT 기기 같은 제한된 환경을 위한 경량 FPE, 새로운 데이터 형식 지원, 다른 암호화 기법과 결합하는 하이브리드 접근법도 연구 대상이다.