AES 암호화 된 데이터베이스 항목의 키 및 초기화 벡터는 어떻게 파생해야합니까?

Question

사용자가 내 인트라넷 앱에서 온라인 양식을 만들고 관리 할 수 ​​있도록 CMS 시스템을 구축했습니다.

물론 양식에서 처리하는 데이터 중 일부는 암호화되어야 할 수도 있습니다. 급여 세부 사항을 처리하는 양식을 작성하는 데 시스템을 사용하는 경우. 그래서 AESManaged 클래스를 사용하여 응용 프로그램 db에 들어가기 전에 이러한 종류의 데이터를 대칭 적으로 암호화합니다.

모두 괜찮습니다.하지만 이제는 출시하기 전에 shared secret 및 salt과 관련된 조정자와 함께 할 수 있습니다.

내 원래 아이디어는 Question 필드 (다시 GUID 기반) ID와 암호화 된 필드를 포함하는 Form의 (GUID 기반) ID를 조합하여 (동적) shared secret 있도록 하였다 해답 :

FormId:QuestionId 

내 Salt 현재의 GUID의 순서 즉 역에서만, 같은 방법으로 생성됩니다.

QuestionID:FormID. 

저는이 재료에 익숙하지 않으므로이 전략이 합리적인지 아니면 다른 방법으로해야하는지 확실하지 않습니다.

Answer 1

소금은 임의로 생성 된 값이어야합니다. 그 목적은 사전/무차별 공격을 실행하기 어렵게 만드는 것입니다. 위키 피디 어에는 암호화 된 소금에 대한 멋진 기사가 있습니다. http://en.wikipedia.org/wiki/Salt_(cryptography

공유 암호는 암호화 된 데이터 (예 : ID)로 암호화되지 않은 상태로 저장되는 것이 가장 이상적입니다. 일반적으로 최종 사용자 또는 관리자가 주기적으로 키를 돌리거나 보안 위반이 발생한 경우 키를 선택하는 것이 가장 좋습니다. 이 암호 키는 CMS의 각 사용자 또는 관리 계정에 의해 소유 될 수 있습니다. 매우 심각한 보안 요구 사항이있는 경우 타사 키 관리 서버를 사용할 수 있습니다.

여기에서 주요 목표가 난독 화가 더 심하고 CMS가 보안 감사의 형태를 따르지 않으면 초기 아이디어의 일부를 따르는 것이됩니다. 데이터의 일시적인 액세스를 막을 수는 있지만 무작위 소금, 키를 회전하는 방법 및 시스템의 "소유자"가 암호를 변경하는 방법을 요구하는 공식 표준에 대한 감사는 통과하지 못할 것입니다. 너 자신은 데이터에 접근 할 수 없었다.