0

중앙 서버에서 명령을 폴링하는 분산 응용 프로그램이 있으며 해당 명령의 내용은 응용 프로그램과 함께 배포 된 공개 키를 사용하여 개인 키로 "서명"됩니다 각 원격 사이트에서. 각 명령은 개인 키로 서명되며 명령이 실행되기 전에 해당 서명이 확인됩니다.Java에서 대칭 암호화를 사용하여 디스크의 개인 키 보안

다음은 내가 공개/개인 키 쌍을 java로 생성하는 방법입니다. 은 간단 상대적으로 안전 명령을 전송뿐만 아니라, 우리가 지금 다운로드하고 실행 우리의 소프트웨어를 지시합니다 명령을 보낼 것을

KeyPairGenerator keyGen = KeyPairGenerator.getInstance("DSA", "SUN"); 
    SecureRandom random = SecureRandom.getInstance("SHA1PRNG", "SUN"); 
keyGen.initialize(1024, random); 
KeyPair pair = keyGen.generateKeyPair(); 

새로운 요구 사항은 (나는 우리가 더 많은 1,024 다음 일을해야 실현) 설치 프로그램이 자체를 업데이트합니다. 이것은 올바르게 수행되지 않으면 커다란 구멍을 열 가능성이 있습니다. "업데이트 설치 관리자 실행"명령은 항상 서명되며 실행 파일의 md5도 포함되어 다운로드되고 실행됩니다. 따라서 명령의 서명이 정확해야하며 (md5가 포함될 것임), 다운로드 된 파일에서 계산 된 md5가 정확해야 실행이 발생합니다. 이것은 내가 생각할 수있는 대부분의 공격 벡터를 처리해야합니다. 다른 모든 것에 대해 걱정해야합니까?

그래서 이제는 이러한 명령이 시작된 서버의 개인 키 보안에주의를 기울이고 있습니다. 개인 키가 확보되면 게임 오버가됩니다. 디스크의 해당 키를 어떻게 보호해야합니까?

개인 키를 보호하기 위해 암호문과 함께 대칭 암호화를 사용하는 것이 좋습니다. ,

char[] passphrase; // Actual passphrase 
PrivateKey privateKeyObj; // Actual Private Key 
byte[] privateKeyBytes = privateKeyObj.getEncoded(); 

byte[] salt = new byte[8]; 
new SecureRandom().nextBytes(salt); 

SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1"); 
KeySpec spec = new PBEKeySpec(passphrase, salt, 1024, 256); 
SecretKey tmp = factory.generateSecret(spec); 
SecretKey secret = new SecretKeySpec(tmp.getEncoded(), "AES"); 

Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding"); 
cipher.init(Cipher.ENCRYPT_MODE, secret); 
AlgorithmParameters params = cipher.getParameters(); 
byte[] iv = params.getParameterSpec(IvParameterSpec.class).getIV(); 

byte[] ciphertext = cipher.doFinal(privateKeyBytes); 

FileOutputStream outputFileStream = new FileOutputStream(outputFile); 
outputFileStream.write(salt); 
outputFileStream.write(iv); 
outputFileStream.write(ciphertext); 
outputFileStream.close(); 

(명확성을 위해 제거 예외)

이 기본적으로 무작위로 염을 생성을 키 올 암호를 사용하고 그 결과 소금을 저장하고 다음과 같이

나의 현재 솔루션입니다 , IV 및 암호문을 해독 할 준비가 된 파일에 저장합니다.

그러나 나는 여기에 뭔가 빠져 있다고 느낍니다. 마찬가지로 내가 어떻게 든 유효한 유형의 설명을 얻을 수 있도록 키에 어떤 종류의 MAC를 포함시켜야합니까? 개인 키 앞에 5 또는 6 바이트의 알려진 텍스트를 넣는 것만으로도 간단할까요? 나쁜 패스 프레이즈는 지금 막 나쁜 패딩 예외를 야기하지만, 나는 이것이 항상 그런 것은 아니며 나쁜 패스 프레이즈가 디코드되어 정크로 이어질 것이라고 읽었습니다. 나는 이것을 막아야한다고 느낍니다.

내가 올바른 길을 가고 있는지 알 수 있고 의견을 제공 할 수 있습니까? 가능한 한 보안을 유지하는 것이 중요합니다.

답변

1

암호 구문을 잘못 입력했는지 알고 싶다면 해시 또는 HMAC를 포함하는 것이 타당합니다. 그렇지 않으면 솔루션이 나에게 합리적으로 보입니다.

가능한 한 안전하게 저장하기 위해 할 수있는 다른 한 가지 방법은 오프라인으로 가져 오는 것입니다. 몇 개의 USB 키에 사본을 넣고 안전하지만 보관할 곳에 보관하고 안전 금고 또는 변호사와 함께 백업하십시오. 물리적으로 접근하기 어려운 경우에는 비밀 키를 얻는 것이 좋습니다.

+0

감사합니다. 내가 가진 한 가지 질문은 내가 HMAC에 어떤 열쇠를 사용 하느냐가 중요하다는 것입니다. 중요하지 않겠지 만 암호화에 사용 된 것과 동일한 키를 사용하는 위험이 있는지 확실하지 않습니까? 정직하게도 정적 키를 사용할 수 있습니다. 위험에 대해 잘 모르겠습니다. –

+0

@jr 암호 해독 된 키의 간단한 해시도 포함 할 수 있습니다. 유일한 목적은 암호가 올바른지 확인하는 것입니다. 암호화 된 전송 된 데이터의 확인을 위해 HMAC를 사용할 때 고려해야 할 사항이 있지만 실제로이 경우에는 적용되지 않는다고 생각합니다. –

+0

감사합니다. Nick. 내가 한 것은 또 다른 소금을 생성하고 hmac 계산에 사용 된 키를 생성하기 위해 동일한 암호와 다른 소금을 사용했습니다. –

0

HMAC를 사용하지 않거나 잘 알려진 접두사를 사용하여 공격자가 해독하기가 더 어려워지는 경우가 있습니다. HMAC를 포함시키지 않으면 잘못된 패스워드를 인식하기에 충분할 수있는 몇몇 상황 (파손 된 패딩으로 인한)에서 디코딩 예외가 발생합니다.

관련 문제