Java - PKCS11 et MSKeyStore

Question

J'essaye de signer une chaîne avec des certificats différents de MS-KeyStore. Mais, je sais qu'il y a des clés importées d'un jeton dans MS-Keystore. Donc, mon problème est - si je passe par le Keystore et essaie de signer avec un cert qui a une référence à pkcs11, je reçois un pop-up pour entrer le mot de passe pkcs11. Comment puis-je vérifier si le certificat provient de mon token?

Merci d'avance !!!

C'est mon code pour l'instant:

String alias; 
    byte[] data = "test".getBytes(); 
    char[] pin = "pass".toCharArray(); 

    try { 


     KeyStore ks = KeyStore.getInstance("Windows-MY"); 
     ks.load(null, pin); 
     System.out.println("Provider: "+ks.getProvider()); 
     System.out.println("KS size: " + ks.size()); 

     Enumeration enumeration = ks.aliases(); 

     while (enumeration.hasMoreElements()) { 
      alias = (String) enumeration.nextElement(); 

      PrivateKey privateKey = (PrivateKey) ks.getKey(alias, null); 
      Certificate certificate = ks.getCertificate(alias); 

      Provider provider = ks.getProvider(); 
      Signature signature = Signature.getInstance("SHA1withRSA", provider); 
      try { 
       signature.initSign(privateKey); 
       signature.update(data); 

       byte[] signedSignature = signature.sign(); 
       System.out.println("\tGenerated signature for " + alias); 

       signature.initVerify(certificate); 
       signature.update(data); 
       if (signature.verify(signedSignature)) { 
        System.out.println("\tSignature verifified for " + alias); 
       } else { 
        System.out.println("\tCould not verify signature for " + alias); 
       } 
      } catch (Exception ex) { 
       System.out.println("\tError for " + alias); 
      } 

     } 

    } catch (KeyStoreException e) { 
     e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates. 
    } catch (CertificateException e) { 
     e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates. 
    } catch (NoSuchAlgorithmException e) { 
     e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates. 
    } catch (FileNotFoundException e) { 
     e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates. 
    } catch (IOException e) { 
     e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates. 
    } catch (UnrecoverableKeyException e) { 
     e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates. 
    } 

Answer 1

Je crains que vous ne pouvez pas dire de manière fiable la source du certificat, au moins pas au niveau Java pour le fournisseur MS CAPI. Mais cela fait partie de la conception - MS CAPI a plus ou moins l'intention d'encapsuler et de cacher l'origine des certificats/clés.

Un moyen sûr de savoir que votre clé/certificat provient d'un périphérique PKCS # 11 serait d'utiliser le SUN PKCS#11 provider. Cela présente toutefois l'inconvénient que vous devez spécifier le chemin d'accès à votre bibliothèque PKCS n ° 11 native de manière statique (dans le fichier java.security où vous pouvez configurer les fournisseurs de façon statique) ou le demander dynamiquement en tant qu'entrée utilisateur.

Si l'utilisation du fournisseur PKCS # 11 pose trop de problèmes dans votre situation, je suggère d'implémenter une boîte de dialogue de choix de certificat qui filtre les certificats appropriés. Il n'y a aucun gain immédiat de sécurité en restreignant MSCAPI aux certificats d'origine PKCS # 11 - il pourrait y avoir une bonne raison pour que votre utilisateur ait d'autres certificats/clés installés (souvent sous la forme de fichiers PKCS # 12). Vous devez uniquement vérifier (et aider l'utilisateur à filtrer les certificats en fonction de ce critère) que le certificat/la clé finalement choisi répond à vos critères: utilisation correcte de la clé (par exemple signature numérique), utilisation de la clé étendue, politiques acceptables ou connues les certificats etc.

Dans l'UE, nous évoluons lentement vers la notion de «certificats qualifiés sur un dispositif de création de signature sécurisé». Cela implique que les certificats qui sont expédiés sur un tel périphérique (par exemple une carte à puce) contiendront une stratégie spéciale, les autorités de certification sont interdites d'utiliser ces stratégies pour d'autres certificats, par exemple des certificats logiciels. Cela vous permettra donc de vous assurer qu'un certificat provient d'un périphérique matériel sécurisé. Vous pouvez vérifier si les certificats concernés prennent en charge cette fonctionnalité. Cette ETSI document répertorie les OID correspondants que vous auriez à rechercher.

Answer 2

Dans les magasins de clés Java, l'alias de la clé et du certificat doit être lié. Fondamentalement, une entrée de clé privée est une clé privée + chaîne de certificats. Donc, le certificat devrait toujours provenir du magasin de clés. Si le certificat provient du jeton actuel, c'est bien sûr l'implémentation du magasin de clés. La seule façon de vérifier si elles provenaient réellement du jeton est de les récupérer en utilisant une méthode différente (par exemple en lisant les octets du certificat directement à partir du jeton). Il n'y a pas de lien vers le périphérique de stockage pour les certificats, si c'est ce que vous recherchez.

Bien sûr, il est logique de vérifier la chaîne complète des certificats jusqu'au certificat racine. Si le certificat racine ne change pas souvent, vous pouvez envisager de stocker le certificat ou un hachage sur le certificat racine dans une ressource fournie avec votre application ou de le distribuer dans le magasin de clés Java standard.