CSP 및 암호화 프로세스

CryptoAPI 함수는 CSP( 암호화 서비스 공급자 )를 사용하여 암호화 및 암호 해독을 수행하고 키 스토리지 및 보안을 제공합니다. 이러한 CSP는 독립적인 모듈입니다. 이상적으로 CSP는 특정 애플리케이션과 독립적으로 작성되므로 모든 애플리케이션이 다양한 CSP로 실행됩니다. 그러나 실제로 일부 애플리케이션에는 사용자 지정된 CSP가 필요한 특정 요구 사항이 있습니다. 이는 Windows GDI 모델과 비교됩니다. CSP는 그래픽 디바이스 드라이버와 유사합니다.

시스템 내 키에 대한 보호 품질은 시스템 전체가 아닌 CSP의 디자인 매개 변수입니다. 이렇게 하면 애플리케이션을 수정하지 않고 다양한 보안 컨텍스트에서 실행할 수 있습니다.

암호화 내부 액세스 애플리케이션은 신중하게 제한됩니다. 이렇게 하면 안전하고 이식 가능한 애플리케이션 개발이 용이합니다.

다음 세 가지 디자인 규칙이 적용됩니다.

• 애플리케이션은 키 지정 자료에 직접 액세스할 수 없습니다. 모든 키 재질은 CSP 내에서 생성되고 불투명 핸들을 통해 애플리케이션에서 사용되므로 애플리케이션 또는 관련 DLL이 키 지정 자료를 공개하거나 잘못된 임의 소스에서 키 지정 자료를 선택할 위험이 없습니다.
• 애플리케이션은 암호화 작업의 세부 정보를 지정할 수 없습니다. CSP 인터페이스를 사용하면 애플리케이션에서 암호화 또는 서명 알고리즘을 선택할 수 있지만 모든 암호화 작업의 구현은 CSP에서 수행됩니다.
• 애플리케이션은 사용자 자격 증명 또는 기타 사용자 인증 데이터를 처리하지 않습니다. 사용자 인증은 CSP를 통해 수행됩니다. 따라서 생체 인식 입력과 같은 고급 인증 기능이 있는 향후 CSP는 애플리케이션 인증 모델을 변경할 필요 없이 작동합니다.

최소한 CSP는 DLL(동적 연결 라이브러리) 및 서명 파일로 구성됩니다. 서명 파일은 CryptoAPI 가 CSP를 인식하도록 하는 데 필요합니다. CryptoAPI는 이 서명의 유효성을 주기적으로 검사하여 CSP 변조가 감지되었는지 확인합니다.

일부 CSP는 로컬 RPC를 통해 호출되거나 시스템 디바이스 드라이버를 통해 호출되는 하드웨어에서 주소로 구분된 서비스에서 해당 기능의 일부를 구현할 수 있습니다. 주소로 구분된 서비스 또는 하드웨어에서 글로벌 키 상태 및 중앙 암호화 작업을 격리하면 키와 작업이 애플리케이션 데이터 공간 내에서 변조되지 않도록 안전하게 유지됩니다.

애플리케이션이 특정 CSP에 특정한 특성을 활용하는 것은 현명하지 않습니다. 예를 들어 Microsoft 기본 암호화 공급자(CryptoAPI와 함께 제공)는 40비트 세션 키와 512비트 공개 키를 지원합니다. 이러한 키를 조작하는 애플리케이션은 다른 CSP를 사용하는 경우 애플리케이션이 실패할 가능성이 있으므로 이러한 키를 저장하는 데 필요한 메모리 양에 대한 가정을 피해야 합니다. 잘 작성된 애플리케이션은 다양한 CSP에서 작동해야 합니다.

CryptoAPI와 함께 사용할 수 있는 암호화 공급자 유형 및 미리 정의된 CSP에 대한 자세한 내용은 암호화 공급자 유형 및 Microsoft 암호화 서비스 공급자를 참조하세요.