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

Стандартные API для платежей поддерживают шифрование на прикладном уровне либо по протоколу PGP, либо по протоколу JWE.

Шифрование PGP

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

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

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

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

Перед началом разработки необходимо обменяться ключами 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 Web Encryption (JWE) — это стандарт, определенный RFC7516 , для шифрования контента на уровне приложения. JSON Web Signature (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; charset=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. Во время разработки вам потребуется обмениваться только ключами для песочницы, используемыми для разработки и тестирования вне производственной среды. Перед тестированием и запуском в производственной среде необходимо выполнить еще один обмен ключами для производственной среды.