Chiffrement AES 256 de l'ère Java 9

Vous n'avez plus besoin d'un fichier de politique.

C'est important, alors je le répète. Vous n'avez plus besoin d'un fichier de politique.

Contexte

Java utilise la classe Cipher de la bibliothèque standard pour gérer les chiffrements AES sans utiliser de bibliothèques tierces. Cependant, le cryptage AES semble être soumis à des restrictions d'exportation américaines et la norme ne peut gérer que des clés jusqu'à 128 bits. Il est bien connu que dans des pays comme le Japon qui ne sont pas soumis à ce contrôle des exportations, il est nécessaire de télécharger séparément un fichier de politique de puissance illimitée d'Oracle et de l'écraser sur le système.

Activer AES256 avec Java

Ce serait bien de pouvoir utiliser le chiffrement AES 256 en remplaçant le fichier de politique, mais ... pour être honnête, c'est très ennuyeux. Il est difficile d'expliquer cela à quelqu'un qui ne sait pas ce qui s'est passé, et c'est aussi un problème de le remplacer chaque fois que vous mettez à jour le JDK. Si c'est juste un problème, il y a toujours le risque d'oublier ou de faire des erreurs.

Changements de Java 9

Dans Java 9, ce fichier de stratégie est pré-livré avec le JDK et peut maintenant être contrôlé en modifiant simplement la propriété de sécurité crypto.policy.

ʻUnlimited` → Force illimitée (AES 256 peut également être utilisé)
limited → Force limite (peut être utilisé jusqu'à AES 128 comme avant)

La propriété de sécurité crypto.policy peut être définie de deux manières, mais à partir de Java 9, elle est par défaut ** ʻunlimited`, donc vous n'avez vraiment rien à faire. il n'y a pas.

Définissez en appelant Security.setProperty ()

Puisqu'il peut être défini par programme, il est exempt de remplacement de fichier de stratégie et de réécriture de fichier de configuration préalable. Cependant, gardez à l'esprit qu'une fois que le framework JCE est initialisé, il ne peut pas être commuté au milieu, comme décrit ci-dessous.
```
Security.setProperty("crypto.policy", "unlimited");
int length = Cipher.getMaxAllowedKeyLength("AES"); // => 2147483647
```
```
Security.setProperty("crypto.policy", "limited");
int length = Cipher.getMaxAllowedKeyLength("AES"); // => 128
```

Définissez dans le fichier java.security

Vous pouvez également pré-éditer $ JAVA_HOME / conf / security / java.security. Veuillez noter que la hiérarchie des répertoires est légèrement différente de Java 8

$ cd /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/conf/security/  #exemple macOS
$ tree
.
├── java.policy
├── java.security  #Définir dans ce fichier
├── javaws.policy
└── policy
    ├── README.txt
    ├── limited
    │   ├── default_US_export.policy
    │   ├── default_local.policy
    │   └── exempt_local.policy
    └── unlimited
        ├── default_US_export.policy
        └── default_local.policy

$ grep "crypto.policy=" java.security
crypto.policy=unlimited

Changements de Java 8

■ Addendum du 17/01/2018 (merci @Yehara) Depuis 8u161, la valeur par défaut est passée à ʻunlimited` dans Java 8. Même dans l'environnement Java 8, vous pouvez utiliser le cryptage AES 256 simplement en mettant à jour le dernier JDK: félicitations:

Jusque-là, il se termine par «Je veux bientôt passer à Java 9: fatigué:», mais en fait, ce mécanisme s'applique également à Java 8 8u151. Il est inclus à partir de /javase/8u151-relnotes-3850493.html#JDK-8157561). Cela signifie que les utilisateurs de Java 8 peuvent désormais utiliser le cryptage AES 256 simplement en définissant la propriété de sécurité crypto.policy.

Cependant, il existe des différences par rapport aux spécifications Java 9, alors tenez compte des points suivants.

La valeur par défaut n'est pas spécifiée (équivalente à limited), vous devez donc la changer explicitement en ʻunlimited`.
Il suit la hiérarchie de répertoires traditionnelle et est différent de Java 9.

Vous pouvez activer le chiffrement à force illimitée de l'une des manières suivantes:

Définissez en appelant Security.setProperty ()

Identique à Java 9

Définissez dans le fichier java.security

Notez que contrairement à Java 9, il s'agit de $ JAVA_HOME / jre / lib / security / java.security

$ cd /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/lib/security/
$ tree
.
├── blacklist
├── blacklisted.certs
├── cacerts
├── java.policy
├── java.security  #Définir dans ce fichier
├── policy
│   ├── limited
│   │   ├── US_export_policy.jar
│   │   └── local_policy.jar
│   └── unlimited
│       ├── US_export_policy.jar
│       └── local_policy.jar
└── trusted.libraries

$ grep "crypto.policy=" java.security                                           
# (equivalent to crypto.policy=limited)
#crypto.policy=unlimited

Pour référence, jusqu'à 8u144 était la hiérarchie de répertoires suivante

$ cd /Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre/lib/security/
$ tree 
.
├── US_export_policy.jar  #Remplacez ce fichier
├── blacklist
├── blacklisted.certs
├── cacerts
├── java.policy
├── java.security
├── local_policy.jar      #Remplacez ce fichier
└── trusted.libraries

Définissez dans le fichier de stratégie ʻUS_export_policy.jar, local_policy.jar`

Je ne pense pas qu'il y ait d'autre mérite que de ne pas vouloir changer l'opération, mais vous pouvez également placer un fichier de politique directement sous $ JAVA_HOME / jre / lib / security / comme auparavant. Cependant, dans ce cas, la condition est que «crypto.policy» n'est pas spécifié (valeur par défaut).

Remarques

Il s'agit de la méthode de 1. qui est définie par programme en utilisant Security.setProperty (), mais soyez prudent car elle ne fonctionne pas comme prévu dans certaines applications. Le fait est qu'il doit être défini ** avant l'initialisation du framework JCE.

Par exemple, le code suivant semble correct, mais la «longueur2» est également 128. Cela est dû au fait que le framework JCE est initialisé lorsque la classe Cipher est référencée pour la première fois, et à ce stade, il est décidé quelle stratégie sera utilisée.

    int length = Cipher.getMaxAllowedKeyLength("AES");  // => 128
    Security.setProperty("crypto.policy", "unlimited");
    int length2 = Cipher.getMaxAllowedKeyLength("AES"); // => 128 (!)

C'est bien si vous écrivez un simple outil de ligne de commande, mais cela peut être un problème pour les applications Web qui s'exécutent sur Tomcat, par exemple. En effet, si la communication HTTPS est activée, le framework JCE sera initialisé avant l'exécution de votre code d'application.

Même dans la même application Web, si un conteneur intégré est utilisé dans Spring Boot, etc., la classe avec la méthode principale qui est le point d'entrée se trouve du côté de l'application, de sorte que la propriété de sécurité dans sa propre classe est plus rapide que l'initialisation du conteneur. Peut être remplacé.

Résumé

Dans cet article, j'ai présenté que le remplacement du fichier de stratégie qui était requis lors de l'utilisation de chiffrements AES 256 en Java n'est plus requis dans Java 9 et Java 8.

Puisqu'il n'est plus nécessaire de remplacer le fichier de politique à l'avance, il est de la nature humaine de choisir la méthode d'utilisation de Security.setProperty () 1. Cependant, dans Java 8, le type d'application en cours de développement Veuillez noter que certains peuvent ne pas fonctionner. Vous devriez passer rapidement à Java 9 où la valeur par défaut est ʻunlimited`.