Сервер Java TLS 1.2: расшифровка AES-GCM

В настоящее время я работаю над сервером Java TLS. (Я опубликовал здесь несколько дней назад о подписи KeyExchange)

Сейчас я пытаюсь расшифровать сообщение TLS, закодированное с помощью AES-GCM. Сервер уже обрабатывает CBC, но, поскольку он уязвим для POODLE, мы хотели бы вместо этого использовать GCM. Постараюсь объяснить как смогу :)

Для этого кода мы используем Java 8u91, Netty 3.9.0. Мы не используем BouncyCastle и не собираемся, мы хотели бы придерживаться JDK.

Код !

/**
 * Deciphers the fragment and returns the deciphered version of it
 * 
 * @param fragment
 *            to decrypt
 * @return the decrypted fragment
 * @throws InvalidKeyException
 * @throws InvalidAlgorithmParameterException
 * @throws IllegalBlockSizeException
 * @throws BadPaddingException
 */
    private ChannelBuffer decodeCiphered(ChannelBuffer fragment, short contentType, byte[] version) throws InvalidKeyException,
    InvalidAlgorithmParameterException, IllegalBlockSizeException, BadPaddingException {
    if (readCipher != null) {
        byte[] ciphered = fragment.array();
        if (session.cipherSuite.cipher.type == CipherType.stream) {
            /* ... */
        } else if (session.cipherSuite.cipher.type == CipherType.block) {
            /* ... */
        } else if (session.cipherSuite.cipher.type == CipherType.aead) {
            byte[] nonce = concat(clientWriteIV.getIV(), fragment.copy(0, 8).array());
            // ClientWriteIV + explicit nonce (first 8 bytes of encrypted data)

            readCipher.init(Cipher.DECRYPT_MODE, clientWriteKey,
                new GCMParameterSpec(session.cipherSuite.cipher.block * 8, nonce));

            ChannelBuffer aad = ChannelBuffers.buffer(13);
            //seq_num(8B) + TLSCompressed.type(1B) + TLSCompressed.version(2B) + TLSCompressed.length(2B)

            aad.writeLong(writeSequence.longValue());
            aad.writeByte(contentType);
            aad.writeBytes(version);
            aad.writeShort(fragment.readableBytes() - 8 - 16);
            readCipher.updateAAD(aad.array());
            ciphered = readCipher.doFinal(ciphered, 8, ciphered.length - 8);
            fragment = ChannelBuffers.wrappedBuffer(ciphered);
        }
    return fragment;
}

/**
 * Generates the different needed keys.
 */
private void generateKeys() {
    byte[] keyBlock = null;
    if (session.cipherSuite.cipher.type == CipherType.aead) {
        keyBlock = new byte[2 * session.cipherSuite.cipher.key
                    + 8];

        try {
            prf(keyBlock, session.masterSecret, KEY_EXPANSION_LABEL, concat(serverRandom, clientRandom));
        } catch (GeneralSecurityException e) {
        }
        clientWriteKey = new SecretKeySpec(keyBlock,0 , session.cipherSuite.cipher.key, session.cipherSuite.cipher.kalgo);
        serverWriteKey = new SecretKeySpec(keyBlock, session.cipherSuite.cipher.key, session.cipherSuite.cipher.key, session.cipherSuite.cipher.kalgo);
        clientWriteIV = new IvParameterSpec(keyBlock, 2 * session.cipherSuite.cipher.key, 4);
        serverWriteIV = new IvParameterSpec(keyBlock, 2 * session.cipherSuite.cipher.key + 4, 4);

    } else {
        /* ... 
            For CBC
        */
    }
}

Я постоянно получаю следующую ошибку:

javax.crypto.AEADBadTagException: Tag mismatch!
at com.sun.crypto.provider.GaloisCounterMode.decryptFinal(GaloisCounterMode.java:524)
at com.sun.crypto.provider.CipherCore.finalNoPadding(CipherCore.java:1023)
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:960)
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:824)
at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:436)
at javax.crypto.Cipher.doFinal(Cipher.java:2223)
at com.seemy.codec.tls.TlsCodec.decodeCiphered(TlsCodec.java:525)

Кажется, обычно это означает, что AAD не прав. Но насколько я могу судить из RFC 5246, раздел 6.2.3.3 AAD должен быть следующим:

The additional authenticated data, which we denote as additional_data, is defined as follows:

  additional_data = seq_num + TLSCompressed.type +
                    TLSCompressed.version + TLSCompressed.length;
where "+" denotes concatenation.

Я в растерянности, чтобы найти, что я делаю неправильно, чтобы расшифровать это сообщение. Ошибка «Несоответствие тегов» не очень помогает найти, что не так, поэтому я надеюсь, что кто-то здесь может мне помочь :)

Спасибо и хорошего дня !

Редактировать 1: я поместил короткий вместо байта в contentVersion, однако результат все тот же. Я получаю только ошибки несоответствия тегов...

Редактировать 2: Как предложил @dave_thompson_085, doFinal теперь вызывается для (ciphered, 8, ciphered.length-8) вместо (ciphered, 0, ciphered.length), чтобы исключить явное_nonce.

Я также более тщательно проверил значения aad и nonce.

Часть «explicit_nonce» одноразового номера соответствует пакету, который я вижу в Wireshark. Теперь я беспокоюсь, что client_write_IV не сгенерирован должным образом :|

Что касается aad, я обнаружил кое-что немного странное: длина равна 0.

Сообщение, которое я получаю от клиента, имеет длину 40 байтов, минус 8 для части manifest_nonce, минус длина MAC, которая составляет 32 для SHA-256 (я пытаюсь заставить работать tls_ecdhe_rsa_with_aes_128_gcm_sha256).

Следовательно, если я попробую tls_ecdhe_rsa_with_aes_256_gcm_sha384, длина окажется равной -16. Это кажется мне неправильным.

Редактировать 3: Я снова сделал, как предложил @dave_thompson_085, и изменил свой код, чтобы он имел следующую длину: aad.writeShort(fragment.readableBytes() - 8 - 16);, тогда как раньше я делал aad.writeShort(fragment.readableBytes()-8-session.cipherSuite.mac.len);

Кажется, он хорошо работает при разговоре с хромом (даже если он терпит неудачу после того, как я отправляю собственное зашифрованное сообщение, но для этого потребуется еще один пост позже, если я не могу исправить это самостоятельно), но при попытке с клиентом open_ssl я получаю несоответствие тегов очередной раз. Firefox и Safari просто присылают мне оповещения о версии_протокола…