Problème

Le verrouillage des threads dans java.security.SecureRandom.nextBytes, force l'application AEM à se bloquer :

java.lang.Thread.State: BLOCKED (on object monitor)
at java.security.SecureRandom.nextBytes(SecureRandom.java:468)
- waiting to lock <0x0000000744cb6070> (a java.security.SecureRandom)
at org.bouncycastle.crypto.CipherKeyGenerator.generateKey(Unknown Source)
at org.bouncycastle.jcajce.provider.symmetric.util.BaseKeyGenerator.engineGenerateKey(Unknown Source)
at javax.crypto.KeyGenerator.generateKey(KeyGenerator.java:540)

Cause

Il s’agit d’un problème connu [1] dans les systèmes Linux où /dev/random manque « d’entropie » et entraîne le blocage du système de threads.

[1] https://bugs.java.com/view_bug.do?bug_id=6708214

Résolution

  1. La solution la plus simple consiste à installer haveged sur le système d'exploitation Linux. Cette procédure s’assure que le périphérique /dev/random est fourni avec suffisamment d'aléatoire pour éviter des problèmes de performances.

    Sur les plates-formes basées sur Debian (Debian, Ubuntu) :

    sudo apt-get install rng-tools
    sudo update-rc.d haveged defaults

    Sur les plateformes Redhat (RHEL, Fedora, CentOS) :

    sudo yum install rng-tools
    sudo chkconfig haveged on
  2. Une autre solution consiste à utiliser /dev/urandom plutôt que /dev/random. Cependant, la sécurité risque d’être réduite en raison d’une diminution de l'aléatoire.

    • Modifier $JAVA_HOME/jre/lib/security/java.security
    • Modifiez la ligne suivante :
    securerandom.source=file:/dev/random

    en

    securerandom.source=file:/dev/urandom
  3. Les variantes sont disponibles ici.

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne