Ce thread de code crypto est-il sécurisé?

Question

J'ai un pool d'objets d'aide de cryptage immuables qui contiennent des instances de la java JCA Cipher et objets MessageDigest:

AlgorithmInstance(Cipher encCipher, Cipher decCipher, MessageDigest digest) { ... } 
private BlockingQueue<AlgorithmInstance> pool = new ArrayBlockingQueue<AlgorithmInstance>(poolSize); 

Divers fils dans mon application, le cryptage ou le décryptage besoin, composer des objets AlgorithmInstance en accédant à une piscine. Chaque thread les utilise pour chiffrer ou déchiffrer, puis les renvoie dans le pool lorsqu'ils sont terminés. Les threads ne se synchronisent sur aucun objet JCA car il n'y a pas d'accès simultané. Decrypt fonctionne à peu près de la même manière.

public byte[] encryptMessage(byte data[]) { ... 
try { 
    AlgorithmInstance inst = pool.take(); 

    inst.digest.reset(); 
    byte[] digest = inst.digest.digest(message); 

    inst.encryptCipher.init(Cipher.ENCRYPT_MODE, m_currentKey, ivParams); 
    inst.encryptCipher.doFinal(messageBuffer); 
} 
finally { 
    pool.put(inst) 
} 
} 

Cela fonctionne 99.99% du temps; et 100% du temps dans les tests unitaires. Cependant, une fois dans une lune bleue, je reçois un message dont le résumé calculé ne sort pas correctement - normalement cela indique une falsification de message ou des erreurs de réseau; mais l'expéditeur et le destinataire sont sur la même machine (dans différents processus). Existe-t-il un état interne pour un chiffrement ou un chiffrement qui peut souffrir d'effets de consistance de la mémoire? Je suis dans une boîte Windows 2 Core donc je ne vois pas comment je pourrais même souffrir de la cohérence de la mémoire effets. Je réinitialise le chiffrement et digère chaque appel, cela ne devrait donc pas avoir d'importance.

Q: Y at-il un moyen que j'aurais pu finir avec un mode de remplissage qui échoue parfois en fonction de la longueur du message? Le décrypteur et le chiffreur utilisent exactement les mêmes algorithmes (AES/CBC/Pkcs5Padding + SHA-256, et une taille de clé de 128).

Answer 1

J'ai changé le code afin que je synchronise sur l'AlgorithmInstance pendant que j'utilise l'un de ses objets contenus. Je n'ai pas vu ce problème depuis; Cependant, ce n'est pas clair pourquoi; étant donné que les queue.put() et queue.take() opérations devraient former exactement le même se passe-avant relation formée par le déverrouillage de l'écran:

synchronized (inst) { 
... 
// do crypto opperations 
} 

La seule autre possibilité que je peux trouver est que le IVParamSpec est modifié au cours de la Cipher.init() calcul puis restauré à la fin. Puisque les ivParams sont supposés en lecture seule et partagés entre tous les objets du pool, si cela est vrai, cela pourrait conduire à un accès non-synchronisé et éventuellement à un MCE.

Answer 2

La fonction encryptMessage() est self-thread car elle n'utilise pas la mémoire partagée par 2 threads. Cependant, il est probable que le code qui utilise cette fonction ne soit pas thread-safe. Si vous souhaitez chiffrer/déchiffrer simultanément des données dans un pool ou que, il est probable que l'index de travail actuel n'augmente pas ou ne décrémente pas de manière sécurisée. Un index global partagé entre threads peut être créé en ayant un entier global protégé par un mutex. Avant que cette valeur soit lue puis modifiée, un thread doit demander un verrou sur cette variable.

Answer 3

Votre application comporte-t-elle beaucoup de threads? Parce qu'au lieu d'avoir un pool, vous pouvez placer votre AlgorithmInstances dans des objets ThreadLocal, s'assurant ainsi que chaque AlgorithmInstance n'est utilisée que par le même thread, le problème devrait disparaître et vous n'aurez plus besoin de synchroniser sur AlgorithmInstance (donc vous aurez une meilleure performance).