Questions de base sur l'utilisation de Keystore

Question

J'ai une application qui génère SecretKeys, une par client. Ceux-ci doivent être conservés dans notre base de données. Je ne connais pas vraiment les schémas de sécurité courants ou les implémentations, et je recherche des conseils.

La classe KeyStore semble être largement utilisée, notamment pour protéger SecretKeys. Cependant, j'ai vu peu parler de l'utilisation de KeyStore avec des bases de données, et j'essaie de comprendre si c'est parce que c'est un usage élémentaire (et donc pas mentionné), ou parce que c'est une approche mauvaise ou redondante, et je devrais vraiment utiliser une technique différente.

La conception de base est que chaque utilisateur aurait son propre keystore, qui serait sauvegardé/chargé de et vers la base de données par conversion en octets (en utilisant load() et store(), je pense).

Un problème avec ce design? Je me demande aussi comment je devrais gérer le mot de passe pour le KeyStore. Nous envisageons de n'utiliser qu'un seul mot de passe pour tous les KeyStores, mais comment pouvons-nous stocker CE de manière sécurisée sans un keystore?

Ceci est destiné à être utilisé dans une application back-end, et le client ne nous transférera jamais un mot de passe, ni un opérateur humain côté serveur pour fournir un mot de passe.

Answer 1

Dans le monde réel, les clés secrètes sont stockées en toute sécurité (Souligné par) dans un HSM si elles sont destinées à être stockées en toute sécurité, pendant une longue période de temps (allant de quelques heures à plusieurs années). Il y a la norme PKCS#11 qui est destinée à faciliter l'interfaçage avec de tels systèmes, mais je dirais le moins - la plupart des HSM ont leurs propres mécanismes préférés pour l'interfaçage avec le HSM, et l'interface PKCS # 11 s'avère généralement être un handicapé un.

Les clés secrètes peuvent également être stockées de manière sécurisée dans d'autres périphériques comme les cartes à puce et les jetons USB, mais elles sont destinées à la distribution de clés parmi une population de masse. Cependant, tout le monde n'a pas de budget pour les HSM, et beaucoup d'autres alternatives moins sûres (et évidemment moins chères) sont utilisées. Certains systèmes (je prends le cas du serveur d'application Glassfish) stockent un mot de passe principal, qui est utilisé pour protéger les autres mots de passe. La même chose vaut pour les clés - il y aurait une clé principale qui est utilisée pour protéger les autres clés (en quelque sorte, cela est similaire à la façon dont les HSM fonctionnent en interne). Bien sûr, vous êtes alors bloqué avec la sécurisation de la clé principale. Dans certains environnements, c'est facile, car vous pouvez placer la clé dans un fichier qui est restreint à un administrateur système et à l'application, et personne d'autre.

Clause de non-responsabilité: Aucun de ces conseils ne doit être pris à l'aveuglette :-). Si vos clés doivent être protégées à tout prix, investissez dans un HSM.

Answer 2

Donc, vous utilisez java et keystores.

Vous avez 2 questions je comprends bien ?:

1) vous avez besoin des conseils

2) vous voulez savoir comment stocker ce genre de choses à un DB

Question1 Réponse: donc lors de l'utilisation de Java et vous devez utiliser SSL. Java a déjà des implémentations de classes qui communiqueront via https et il effectuera le handshake SSL et tout pour vous! La seule chose que vous devez faire est de fournir le java.security.KeyStore à cette implémentation.

Il y a basiquement 2 types de keystores:

• le premier est de stocker tous les certificats que vous faites confiance (plusieurs certificats) => Keystore.getInstance ("JKS")

• la deuxième est de conserver votre certificat client (un seul) avec sa clé privée => Keystore.getInstance ("PKCS12");

Comment vous faites vos clés privées et des certificats, je ne parlerai pas ici. Je suppose que vous êtes déjà là ... (et sinon, vous pouvez le savoir). Mais les KeyStores sont protégés par un mot de passe. Donc, en général, ils sont sûrs, si personne ne peut pirater votre base de données. Si vous stockez le mot de passe pour ouvrir votre keystore dans la même table, faites attention à l'injection de sql! Mais supposons que ce soit sécurisé. Les fichiers de clés vous permettent d'utiliser l'implémentation existante qui gérera la prise de contact SSL. Donc, fondamentalement, ce n'est pas une mauvaise chose d'utiliser les keystores. Notez que vous n'utiliserez le keystore PKCS12 qu'en cas d'authentification mutuelle (c'est-à-dire que vous devez également vous identifier).

Répondre à la question2: Oui, vous pouvez stocker des fichiers de clés dans la base de données, c'est un peu difficile. Puisque les keystores leur permettent seulement d'utiliser leurs méthodes de stockage et de chargement. Mais vous pouvez atteindre cet objectif comme ceci:

@Entity 
public class MyKeyStoreClass { 
private Long id; 
@Transient 
private KeyStore keystore; 
private String passwordForKeyStore; 
private Byte[] keyStoreAsBytes; 

@PreUpdate 
@PrePersist 
public void concertKeyStoreToBytes() { 
    ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream(); 
     keystore.store(byteArrayOutputStream, 
       passwordForKeyStore.toCharArray()); 
    keyStoreAsBytes = byteArrayOutputStream.toByteArray(); 
} 

@PostLoad 
public void getKeyStore() { 
    if (keystore == null && keyStoreAsBytes != null) { 
     keyStore = KeyStore.getInstance(getKeystoreType().getType()); 
     keyStore.load(new ByteArrayInputStream(keystoreAsBytes), passwordForKeyStore.toCharArray()); 
    }  
} 

Le code ci-dessus est probablement pas 100% correct puisque je l'ai écrit ici (pas d'éditeur). Mais c'est généralement comment vous pourriez le faire, je l'ai fait auparavant et cela a fonctionné si bonne chance;) Notez que ma configuration Spring effectue les méthodes annotées avant ou après une persistance ou une mise à jour. Si vous n'utilisez pas d'annotations et de ressorts, vous pouvez le faire d'une autre manière.