Java/Android - Décryptage AES/CCM avec un MIC de 4 octets

Question

Je tente de décrypter certaines données de test chiffrées par un module blueooth. Le firmware du bluetooth est programmé en C, si cela est important.

Les données chiffrées ont été:

// Test Bytes - 16 bytes 
byte[] testInput = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 
        0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f}; 

// Test key - 16 bytes, 128-bit 
byte[] keyBytes = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 
        0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f}; 

// Test nonce - 13 bytes, 104-bit 
byte[] nonce = {0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09, 
       0x0a,0x0b,0x0c}; 

est ici le problème. Le cryptage des données en C, en utilisant AES/CCM, produit une sortie de 16 octets, avec un MIC de 4 octets. Lorsque je crypte les données en utilisant AES/CCM/NoPadding en Java, la sortie est également de 16 octets, mais a un MAC de 8 octets. Les termes MAC et MIC sont ambigus, semble-t-il, où MIC est utilisé pour la terminologie bluetooth.

Lorsque je crypte le testInput ci-dessus en Java, j'obtiens les mêmes 16 octets de sortie que le cryptage de programmation C. Mais, étant donné que MIC et MAC ont des longueurs différentes, je ne peux pas déchiffrer les données à chaque extrémité.

Y at-il une solution à cela?

J'ai ajouté mon code Java:

Cipher cipher = Cipher.getInstance("AES/CCM/NoPadding", "BC"); 
SecretKeySpec secretKeySpec = new SecretKeySpec(keyBytes, "AES"); 
IvParameterSpec ivParameterSpec = new IvParameterSpec(nonce); 
cipher.init(Cipher.ENCRYPT_MODE, secretKeySpec, ivParameterSpec); 
byte[] encrypted = cipher.doFinal(testInput); 

// The first 16 bytes print out equivalently with the C-language AES/CCM 

est Ci-dessous une image de ma sortie:

est Ci-dessous une image de la sortie C.

BLE Publicité Packet

Answer 1

Le code Java suivant produira le même résultat que le code C:

import org.bouncycastle.jce.provider.BouncyCastleProvider; 

import javax.crypto.Cipher; 
import javax.crypto.spec.GCMParameterSpec; 
import javax.crypto.spec.SecretKeySpec; 
import javax.xml.bind.DatatypeConverter; 
import java.security.Security; 

public class Main { 

    // Test Bytes - 16 bytes 
    static byte[] testInput = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 
      0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f}; 

    // Test key - 16 bytes, 128-bit 
    static byte[] keyBytes = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 
      0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f}; 

    // Test nonce - 13 bytes, 104-bit 
    static byte[] nonce = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 
      0x0a, 0x0b, 0x0c}; 


    public static void main(String[] args) throws Exception { 
     Security.addProvider(new BouncyCastleProvider()); 
     GCMParameterSpec parameterSpec = new GCMParameterSpec(32, nonce); 
     Cipher cipher = Cipher.getInstance("AES/CCM/NoPadding"); 
     SecretKeySpec secretKeySpec = new SecretKeySpec(keyBytes, "AES"); 
     cipher.init(Cipher.ENCRYPT_MODE, secretKeySpec, parameterSpec); 
     cipher.updateAAD(new byte[]{0x01}); 
     System.out.println(DatatypeConverter.printHexBinary(cipher.doFinal(testInput))); 
    } 
} 

Cependant, je ne suis pas sûr pour trouver l'octet à fournir à Cipher.updateAAD(). 0x01 a été trouvé par des essais et erreurs. Essayer de lire la spécification Bluetooth 4.0 est assez douloureux. La spécification semble indiquer que l'octet est le premier octet de l'en-tête du paquet, avec 3 des bits (NESN, SN, MD) forcés à zéro. Les bits restants que j'essaie encore de comprendre.