Шифрование на уровне приложения

API стандартных платежей поддерживают PGP или JWE для шифрования на уровне приложения.

PGP-шифрование

PGP — это стандартный набор алгоритмов шифрования, дешифрования и подписи, обеспечивающий криптографическую конфиденциальность и аутентификацию.

При использовании PGP для шифрования полезных данных партнеры должны поддерживать:

  • Шифрование и дешифрование полезных данных с помощью нескольких ключей PGP.
  • Подписание полезных данных с помощью нескольких ключей PGP.
  • Проверка полезных данных с помощью нескольких подписей, любая из которых может быть подписью с ключом, предоставленным Google.
  • Расшифровка веб-безопасных полезных данных в кодировке Base64.

Открытые ключи PGP, предоставленные Google, должны иметь дополнительный ключ, используемый для шифрования. Подключ допускает независимую ротацию от главного ключа. Мастер-ключ используется для проверки личности. Закрытые ключи должны представлять собой 2048-битные (или более) ключи RSA со сроком действия один год и максимальным сроком действия два года .

Прежде чем начать разработку, вам необходимо обменяться ключами PGP с Google. На этом этапе вы создаете пару открытого и закрытого ключей PGP, предоставляете открытый ключ Google и получаете открытый ключ обратно от Google. Во время разработки вам нужно будет только обмениваться ключами песочницы, используемыми для разработки и тестирования за пределами производства. Перед производственным тестированием и запуском вам необходимо будет выполнить еще один обмен производственными ключами.

Генерация нового ключа PGP

Предполагая, что в вашем системном пути есть двоичный файл GPG , вы можете использовать следующую команду POSIX для создания новой пары ключей.

$ gpg --full-generate-key

При появлении запроса выберите ключ RSA с энтропией не менее 2048 бит и сроком действия 1–2 года. Эта команда должна создать как главный ключ (с меткой SC для подписи и генерации сертификата), так и дополнительный ключ (с меткой E для шифрования) .

Конфигурация библиотеки PGP

Отправка полезных данных

  1. При подписании в качестве алгоритма дайджеста следует использовать SHA384 ; не используйте SHA1 или MD5
  2. При шифровании следует использовать AES256 в качестве алгоритма симметричного шифрования; не используйте CAST5 или IDEA
  3. При шифровании или подписании сообщений обязательно выбирайте подключ соответствующего назначения; используйте ключ CAN_SIGN для подписи и ключ ENCRYPT_COMMS / ENCRYPT_STORAGE для шифрования

Получение полезных данных

  1. При проверке полезных данных убедитесь, что ваша библиотека поддерживает современные алгоритмы хеширования, такие как SHA384 . Google начнет использовать его во всех новых ключах с 14 мая 2023 года.
  2. При расшифровке полезных данных убедитесь, что ваша библиотека поддерживает современные алгоритмы симметричного шифрования, такие как AES256 . Google начнет использовать его во всех новых ключах с 14 мая 2023 года.

Пример шифрования полезной нагрузки GPG

Команда ниже представляет собой пример выбора параметров безопасности при использовании GPG. Ожидается, что эта операция выполняется в доверенной среде, где люди не имеют доступа к закрытым ключам или конфиденциальным входным файлам.

gpg --output signed-and-encrypted.pgp \
  --sign --digest-algo SHA384 \
  --encrypt --cipher-algo AES256 \
  --armor \
  --recipient {key_id} \
  input.txt

GPG автоматически выберет правильный ключ из пакета для каждой операции, которую вы попросите его выполнить.

JWE-шифрование с подписью JWS

Веб-шифрование JSON (JWE) — это стандарт, определенный rfc7516 для шифрования контента на уровне приложения. Веб-подпись JSON (JWS) — это стандарт, определенный rfc7515 для подписи контента на уровне приложения.

Запросы и ответы будут представлять собой токены JWE, зашифрованные с использованием асимметричного шифрования (открытого ключа) с опцией «Компактная сериализация». Токен JWE будет содержать подписанные полезные данные в виде токена JWS. JWS также использует асимметричные ключи; закрытый ключ для подписи и открытый ключ для проверки.

При отправке полезных данных сначала подпишите их, а затем зашифруйте. При получении полезных данных сначала расшифруйте их, а затем проверьте подпись.

При использовании JWE Партнеры должны поддерживать следующие параметры:

  • Компактная сериализация.
  • Расшифровка полезных данных с одного из нескольких ключей JWE.
  • Алгоритм RSA-OAEP, RSA-OAEP-256 или ECDH-ES для управления ключами.
  • Алгоритм A256GCM , A128GCM , A128CBC-HS256 или A256CBC-HS512 для шифрования контента.
    • Заполняется в заголовке enc .
  • kid заголовок для идентификации открытого ключа шифрования.
  • Полезные данные сообщений, использующие шифрование JWE, должны использовать тип контента application/jose; кодировка = utf-8.

При использовании JWS Партнеры должны поддерживать следующие параметры:

  • Компактная сериализация.
  • Проверка полезных данных с помощью одного из нескольких ключей JWS.
  • Алгоритм создания подписи HS256, HS384, HS512, RS256, RS384, RS512, ES256, PS256, PS384 или PS512.
  • kid заголовок для идентификации закрытого ключа подписи.

Строки JWE/JWS будут закодированы как строки UTF-8, а их полезные данные могут быть произвольными байтами.

Закрытые ключи должны представлять собой ключи RSA/ECDH-ES, срок действия которых истекает через один год, а максимальный срок действия — два года. Все идентификаторы закрытых ключей всегда должны оставаться на сервере партнера и, соответственно, все значения подписи должны рассчитываться на сервере партнера.

Перед началом разработки вам необходимо обменяться ключами JWE и JWS с Google. Ключи следует обменивать в формате JWK, как определено в rfc7517 . На этом этапе вы создаете пару открытого и закрытого ключей, предоставляете открытый ключ Google и получаете открытый ключ обратно от Google. Во время разработки вам нужно будет только обмениваться ключами песочницы, используемыми для разработки и тестирования за пределами производства. Перед производственным тестированием и запуском вам необходимо будет выполнить еще один обмен производственными ключами.