Нужна помощь в реализации схемы управления ключами

Question

Схема имеет следующие требования

• Клиентское приложение должно выполнить шифрование / дешифрование с использованием компонента 1, компонента 2 и ZPK (ключ PIN-кода зоны. Клиент должен получить этот ключ от хоста в зашифрованном виде).
• Хост-приложение должно выполнять шифрование / дешифрование с использованием ключа MK (мастер-ключ, сформированный из компонента 1 и компонента 2) и ZPK.

Вот как я создаю компоненты

Online-AUTH>GC
Enter LMK id [0-2]: 0
Enter key length [1,2,3]: 2
Enter key type: 002
Enter key scheme: u
Clear component: **** **** **** **** **** **** **** **** 
Encrypted component: UXXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX 
Key check value: xxxxxx

Online-AUTH>GC
Enter LMK id [0-2]: 0
Enter key length [1,2,3]: 2
Enter key type: 002
Enter key scheme: u
Clear component: **** **** **** **** **** **** **** ****
Encrypted component: UYYYY YYYY YYYY YYYY YYYY YYYY YYYY YYYY 
Key check value: yyyyyy

Online-AUTH>FK
Enter LMK id [0-2]: 0
Enter key length [1,2,3]: 2
Enter key type: 002
Enter key scheme: u
Enter component type [X,H,T,E,S]: e
Enter number of components [1-9]: 2
Enter component 1: UXXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX 
Component 1 check value: xxxxxx
Continue? [Y/N]: y
Enter component 2: UYYYY YYYY YYYY YYYY YYYY YYYY YYYY YYYY
Component 2 check value: yyyyyy
Continue? [Y/N]: y
Encrypted key: UZZZZ ZZZZ ZZZZ ZZZZ ZZZZ ZZZZ ZZZZ ZZZZ 
Key check value: zzzzzz

Что я не понимаю, так это

• Каковы преимущества создания МК с использованием зашифрованных компонентов Как расшифровать зашифрованный ZPK с компонентом 1 и компонентом 2.
• Какова связь между компонентом 1, компонентом 2 и выводом команды FK
• Достаточно ли вездесуще шифрование PIN-кода под ZPK?

Любая помощь приветствуется. PS Я хочу придерживаться вездесущих реализаций.

Answer 1

Вы не первый:)

Я постараюсь объяснить (но мой английский не настолько хорош, чтобы быть достаточно ясным:().

HSM никогда не работает с простыми ключами, все ключи, которые он обрабатывает, зашифрованы под другими, называемыми Key Encryption Key (KEK) ключами. LMK - это KEK, который надежно хранится в защищенной среде HSM. Основная идея HSM заключается в том, что вы не можете получить реальное значение ключа LMK, соответственно, вы не можете получить реальное рабочее значение простого ключа. Все ключи, которые вы используете с HSM, являются криптограммами. LMK - это ваш личный KEK, который не доступен для других сторон (что означает, что он является безопасным KEK). Эти ключи вы должны хранить в базе данных для использования с вашим собственным HSM.

Иногда вам нужно передавать ключи другим лицам, например, Visa или MasterCard, чтобы обмениваться некоторыми зашифрованными данными, такими как PIN-блоки. В этом случае вы должны использовать другой KEK под названием ZMK. Это транспортный ключ, который используется ТОЛЬКО для другого обмена ключами. Вы не можете использовать зашифрованные ключи ZMK с вашим HSM. Во-первых, вы ДОЛЖНЫ импортировать ключ под свой LMK, чтобы сделать его managanbe.

ЗАКЛЮЧЕНИЕ:

1) Вы должны хранить в БД ключи под LMK

2) Ключи под ZMK используются только для передачи другим сторонам.

Если я не был достаточно ясен, пожалуйста, не стесняйтесь спрашивать, постараюсь найти другое объяснение.