토큰화의 주요 원칙 및 결제 적용 Part 1

본 포스팅에서 우리는 토큰화 이면의 원칙과 이것이 전 세계의 거래 처리에서 금융 기관에서 어떻게 사용되는지를 간략히 알아보고자 합니다.

신용 카드 데이터 및 개인 식별 정보(PII)를 포함한 수십억 개의 개인 기록은 사이버 보안 재해 및 데이터 침해 위험 노출로부터 보호되어야 합니다. 한 가지 방법은 토큰화를 사용하는 것입니다.

토큰화란 정확히 무엇일까요?: 일반 원칙

토큰화는 보안을 손상시키지 않으면서 데이터에 대한 모든 중요한 정보를 유지하는 기호로 민감한 데이터를 대체하는 프로세스입니다.

토큰화는 아주 오래전부터 일상 생활에 존재합니다. 다음은 토큰화의 올바른 예입니다.

◆ 사회 보장 번호는 시민을 나타내며,

◆ 숫자는 스위스 "번호가 지정된" 은행 계좌를 나타내며,

◆ 라벨이 붙은 플라스틱 토큰은 카지노 은행에 예치된 실제 돈을 나타냅니다.

◆ 별명(가명, nom de plume, nom de guerre) 등...

토큰화는 암호화 해시의 일반화된 표현입니다. 그것은 무언가를 다른 것으로, 상징('토큰')으로 표현하는 것을 의미하며, 이는 원래 엔티티로 치환됩니다.

보다 정확하게 암호학의 맥락에서 토큰은 해당 기호 값에서 유용한 정보를 검색할 수 없는 방식으로 민감한 정보를 나타내는 기호(또는 기호 그룹)입니다. 실제로 대체되는 기호가 무언가를 의미할 수 있기 때문에 암호화와 정확히 같은 개념은 아닙니다. 이러한 생각은 (공격자를 유인한다는 의미에서) 실제로 복잡하고 대체적입니다.

암호화 토큰은 기밀 정보의 직접 노출을 허용하지 않고 일부 민감한 정보를 대신하는 일종의 프록시 기호입니다.

컴퓨터에서 매우 일반적으로 사용되는 토큰화는 암호 해싱입니다. 실제로 컴퓨터는 옛날부터 사용자의 암호를 해시로 저장합니다.

종종 토큰화는 단방향 암호화 해시를 사용하지만 일반적인 규칙은 아니며 대체 테이블도 토큰화를 수행하는 유효한 방법입니다.

토큰은 그래픽 표현인 이미지일 수도 있습니다. 대체 테이블은 토큰화를 수행하는 간단한 방법을 제공합니다. 이것은 종종 단일 알파벳 치환 암호(Caesar's cipher 등 ...)의 원리입니다.

예를 들어 영어 알파벳(+ 공백 문자)의 각 문자를 색상 코드로 나타낼 수 있습니다(일부 색상은 같아 보일 수 있지만 실제로는 모두 다른 색상입니다).

예를 들어 중요한 사람의 이름이 될 수 있는 기밀 정보 "MR JOHNSON"을 쓰는 대신 다음 토큰으로 표시합니다.

대체 테이블을 모르면 해당 색상 코드를 완전히 이해할 수 없습니다. 사용할 방법이 없습니다.

예를 들어 스마일 아이콘과 같은 기호를 사용할 수도 있습니다.

그리고 이전 예와 같은 문장은 다음 토큰으로 대체됩니다.

이 모든 예는 토큰이 혼란을 야기하고 궁극적으로 최종 공격자를 유인하는 것을 목표로 함을 보여줍니다.

토큰화 대 암호화: 동일하지 않은 이유

토큰화는 암호화와 다르며 실제로 상호 보완적인 개념입니다.

토큰화는 항목과 토큰을 연결하는 큰 사전을 사용해야 하는 암호화로 볼 수 있습니다. 큰 사전이 없으면 토큰을 원래 항목으로 되돌리는 것이 일반적으로 거의 불가능하거나 완전히 불가능합니다.

그러나 AES 또는 RSA와 같은 "표준" 암호화 기능을 사용하여 토큰을 생성할 수도 있습니다. 사전이 필요하지 않으며 키에 대한 지식은 항목을 해당 토큰과 매핑하기에 충분합니다.

마지막으로 명확하지는 않지만 "순수" 임의 함수는 임의 함수에 의해 생성된 토큰에 값을 매핑하는 사전과 함께 토큰을 생성하는 데 사용할 수 있습니다. 이것은 아마도 토큰을 생성하는 가장 좋고 이상적인 방법일 것입니다.

토큰화의 주요 알고리즘

앞서 언급했듯이 토큰을 생성하는 방법에는 여러 가지가 있습니다.

◆ 해시 함수

◆ 암호화

◆ 랜덤 함수

◆ 사용자 지정 대체 테이블

토큰을 실제 값에 매핑할 수 있으려면 암호화를 사용하는 알고리즘이나 되돌릴 수 있는 알고리즘을 제외하고 사전을 유지 관리해야 합니다. 물론 그러한 경우 알고리즘은 예를 들어 일대일 대응과 같은 전단사를 제공해야 합니다. 토큰이 생성되고 최종적으로 역전되는 장소를 토큰 볼트라고 합니다.

차례로 토큰 공급자는 특정 알고리즘과 특히 형식 보존 메커니즘을 사용하여 토큰이 나타내는 값과 동일한 형식을 갖습니다. 예를 들어 16자리 은행 계좌 번호는 16자리 토큰으로 표시되어야 합니다. 이는 일반적으로 기존 시스템을 중단하지 않고 토큰화로 원활하게 마이그레이션하기 위해 필요합니다.

토큰 공급자가 일반적으로 사용하는 것은 다음과 같습니다.

1. 랜덤 성향이 "양호" 인 난수 생성기. 이것은 예를 들어 die hard/또는 die hard randomness 테스트를 성공적으로 통과함을 의미합니다.

2. 원래 값의 공간에서 FIPS 140-2 레벨 3 난수 생성기 표준을 따르는 토큰 공간으로의 무작위 순열.

3. NIST SP 800-90A Rev. 1 표준을 따르는 무작위 순열;

4. NIST 800-38G 표준(알고리즘 FF1)을 따르는 형식 보존 암호화(FPE);

5. 표준 NIST 800-131a를 준수하는 암호화 솔트를 사용하는 암호화 해시

토큰화가 쉽지 않은 이유

토큰화가 그렇게 어렵지 않은 것처럼 보일 수 있습니다. 개념은 매우 간단하고 모든 표준 프로그래머는 모든 종류의 정보를 토큰으로 변환하는 해시 함수를 코딩할 수 있다 라고 생각할 수 있지만 그렇지 않습니다. 다음은 우수한 토큰 생성 서비스에 걸림돌이 되는 몇가지 설계 문제입니다.

1. 토큰 볼트. 볼트는 사전 정보와 토큰이 유지되는 곳이므로 매우 안전해야 합니다. 사전은 보호되어야 하며 가능하면 암호화되어야 합니다.

2. 무충돌. 토큰은 충돌이 없어야 합니다. 그렇지 않으면 올바른 계정 대신 잘못된 계정이 청구될 위험이 있습니다!

3. 속도​. 볼트에서 토큰 생성 및 비교는 빨라야 합니다. 수백만 개의 항목으로 작업할 때 쉽지 않습니다.

4. "무지개 테이블"이 없습니다. 사전 정보/토큰은 다시 생성할 수 없습니다.

결제 토큰화의 이점

은행업계에서 PCI-DSS 요구 사항은 대부분 본질적으로 민감한 신용 카드 정보가 토큰화되어 데이터베이스에 저장되도록 명령하거나 권장합니다. EMV 컨소시엄은 EMV 거래의 토큰화에 관한 사양을 발표했습니다. Visa 및 기타 카드 체계에도 토큰화와 관련하여 고유한 요구 사항이 있습니다.

대부분의 경우 토큰화는 PAN(Primay Account Number : 기본 계정 번호)을 대상으로 합니다.

16자리 PAN은 일반적으로 무작위로 생성되는 16자리 토큰으로 대체됩니다.

예를 들어 PAN을 사용하는 대신:

4085-8800-8378-3527

지불 시스템은 토큰을 사용합니다:

1454-0989-2121-8954

토큰은 원래 PAN으로 토큰화 해제할 수 없다면 완전히 쓸모가 없습니다.

이 토큰은 데이터가 유출되더라도 영향을 받는 결제 카드를 차단하고 새 카드를 생성하는 번거로움 없이 쉽게 변경할 수 있습니다. 토큰화의 또 다른 이점은 "실제" 지불 카드 번호보다 위험이 적기 때문에 토큰화가 되어 있다면 부정 행위 방지 규제가 덜 심하기 때 허위 거부가 감소한다는 것입니다.

대규모 신용 카드 유출의 역사로 인해 소매 은행 업계, 특히 모바일 결제의 맥락에서 카드 데이터의 토큰화를 적극적으로 추진해 왔습니다.

사실 현재 대부분의 모바일 결제는 일부 형태의 토큰화를 사용하고 있습니다.

두 번째 부분에서는 지불 산업의 맥락에서 토큰화 시스템의 실제 예를 볼 것입니다.

관련 솔루션​

Utimaco KeyBRIDGE TokenBRIDGE는 조직이 데이터 손실을 방지할 수 있는 완벽한 토큰화 솔루션을 제공하고 보안 관리를 복잡하게 하지 않으면서 자산의 고유한 토큰화를 보장합니다.

TokenBRIDGE는 모든 토큰화 솔루션의 핵심인 안전하고 관리하기 쉬운 토큰 볼트를 구현합니다