Como o Keytool protege as chaves?
Pergunta
Quando você está construindo uma loja -chave com o utilitário Java Keytool, como as teclas são protegidas? Eu li a documentação e percebo que cada chave privada tem uma senha chave e, em seguida, a loja tem uma senha da loja.
Mas que mecanismo é usado para proteger os dados? É uma cifra de criptografia? Se sim, qual é o algoritmo? Estou focado especificamente em como o KeyTool faz a proteção ao criar um arquivo JKS.
Solução
O JKS Keystore, padrão da Sun, usa um algoritmo proprietário, principalmente para contornar as restrições de exportação em algoritmos padrão. O algoritmo é implementado nesta classe,
sun.security.provider.KeyProtector
A descrição do algoritmo,
Esta é uma implementação de um algoritmo proprietário e exportável do sol destinado ao uso ao proteger (ou recuperar a versão ClearText de) chaves sensíveis. Esse algoritmo não se destina a uma cifra de uso geral. É assim que o algoritmo funciona para a proteção das chaves: P - Senha do usuário S - Random Sal Anexe um sal aleatório (de tamanho fixo) e hash It: d1 = Digest (p, s) armazenar d1 em X. Etapa 2: pegue a senha do usuário, anexe o resultado da digestão da etapa anterior e o hash It: dn = Digest (P, DN-1). Armazene DN em X (anexá -lo aos digestos armazenados anteriormente). Repita esta etapa até que o comprimento de x corresponda ao comprimento da chave privada P. Etapa 3: xor x e p e armazene o resultado em y: y = x xor P. Etapa 4: Armazene S, Y e Digest (P , P) no buffer de resultado r: r = s + y + digery (p, p), onde " +" indica concatenação. (Nota: o Digest (P, P) é armazenado no buffer de resultado, para que, quando a chave seja recuperada, podemos verificar se a tecla recuperada corresponde à chave original.) R é armazenado na tecla. A tecla protegida é recuperada da seguinte forma: a etapa1 e a etapa2 são as mesmas acima, exceto que o sal não é gerado aleatoriamente, mas retirado do resultado r da etapa 4 (os primeiros bytes de comprimento (s)). A etapa 3 (operação XOR) produz a tecla de texto simples. Em seguida, concatenique a senha com a tecla recuperada e compare com o último comprimento (Digest (P, P)) bytes de R. Se eles correspondem, a chave recuperada é realmente a mesma chave que a chave original.
Outras dicas
O algoritmo usado depende da tecla que você usa (pode ser um SmartCard, por exemplo).
O keystore padrão que o Sun envia com o JDK cria um token suave (no arquivo de disco) com três opções de criptografia:
Padrão: "JKS", um tipo de tecla de tecla proprietário (formato). Não tenho certeza sobre o algoritmo.
"JCEKS", um formato proprietário alternativo, usando 3-DE
"PKCS12", um formato padrão (OpenSSL pode lê-lo), com várias opções, mas geralmente 3-DE para chaves privadas e RC2-40 para certificados.
Nos três casos, você possui os dados privados criptografados (simetricamente, usando senhas individuais) e a integridade de todo o armazenamento de chaves protegidas por um resumo criptográfico (usando a senha do keystore).