Bouncy Castle Diffie-Hellman KeyAgreement с KDF: Что такое материал ключей пользователя?

Question

В документации Диффи-Хеллмана Bouncy Castle говорится об использовании "материала пользовательского ключа" и KDF при получении эфемерных ключей из статической пары долгосрочных ключей. Там нет упоминания о том, как создать этот ключевой материал.

Например, в BCFipsIn100.pdf у них есть этот пример:

    public static byte[] initiatorAgreementWithKdf(PrivateKey initiatorPrivate, PublicKey recipientPublic, byte[] userKeyingMaterial) throws GeneralSecurityException {
        KeyAgreement agreement = KeyAgreement.getInstance("ECCDHwithSHA384CKDF", "BCFIPS");
        agreement.init(initiatorPrivate, new UserKeyingMaterialSpec(userKeyingMaterial));
        agreement.doPhase(recipientPublic, true);
        SecretKey agreedKey = agreement.generateSecret("AES[256]");
        return agreedKey.getEncoded();
    }

В их примерах используются статические строки для userKeyingMaterial, но обычно не упоминается, что это должно быть.

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

Answer 1

Используется как extraInfo параметр в DHKDFParameters класс, который используется для инициализации KDF. KDF может использоваться для получения различных ключей из главного ключа путем смешивания дополнительных байтов помимо общего секрета, вычисленного по алгоритму согласования ключей, в данном случае ECCDH. SHA384KDF, вероятно, является совместимым с ANS X9.63 KDF, что требует дополнительного Info Строка октетов (для этой строки октетов существуют различные "информационные" имена (например, байтовый массив).

Там нет никаких спецификаций о том, как его генерировать. Это может быть ASCII-кодировка метки, скажем, "SessionKeyMaterial".getBytes(StandardCharsets.US_ASCII), Он также может включать идентификаторы обеих сторон, открытые ключи, одноразовые номера. По сути, это может занять любые данные, если вам удастся иметь явное кодирование этих данных, которое не перекрывается (т.е. каноническое представление данных).

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