스마트 카드 아키텍처

• 적용 대상:

  ✅ Windows 11, ✅ Windows 10, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

IT 전문가를 위한 이 항목에서는 자격 증명 공급자 아키텍처 및 스마트 카드 하위 시스템 아키텍처를 포함하여 Windows 운영 체제에서 스마트 카드를 지원하는 시스템 아키텍처에 대해 설명합니다.

인증은 개체 또는 사람의 ID를 확인하는 프로세스입니다. 스마트 카드 같은 개체를 인증하는 경우 목표는 개체가 정품인지 확인하는 것입니다. 사람을 인증할 때 목표는 사기꾼을 다루고 있지 않은지 확인하는 것입니다.

네트워킹 컨텍스트에서 인증은 네트워크 애플리케이션 또는 리소스에 대한 ID를 증명하는 행위입니다. 일반적으로 ID는 사용자가 알고 있는 키(예: 공개 키 암호화) 또는 공유 키를 사용하는 암호화 작업에 의해 입증됩니다. 인증 교환의 서버 쪽은 서명된 데이터를 알려진 암호화 키와 비교하여 인증 시도의 유효성을 검사합니다. 암호화 키를 안전한 중앙 위치에 저장하면 인증 프로세스를 확장 가능하고 유지 관리할 수 있습니다.

스마트 카드의 경우 Windows는 보안 인증 요구 사항을 충족하고 사용자 지정 자격 증명 공급자를 포함할 수 있도록 확장 가능한 공급자 아키텍처를 지원합니다. 이 항목에는 다음에 대한 정보가 포함되어 있습니다.

• 자격 증명 공급자 아키텍처
• 스마트 카드 하위 시스템 아키텍처

자격 증명 공급자 아키텍처

다음 표에서는 대화형 로그인 아키텍처에 포함된 구성 요소를 나열합니다.

구성 요소	설명
Winlogon	대화형 로그인 인프라를 제공합니다.
로그온 UI	대화형 UI 렌더링을 제공합니다.
자격 증명 공급자(암호 및 스마트 카드)	자격 증명 정보 및 직렬화 자격 증명에 대해 설명합니다.
LSA(로컬 보안 기관)	로그인 자격 증명을 처리합니다.
인증 패키지	NTLM 및 Kerberos 프로토콜을 포함합니다. 서버 인증 패키지와 통신하여 사용자를 인증합니다.

Windows의 대화형 로그인은 사용자가 Ctrl+Alt+DEL을 누르면 시작됩니다. CTRL+Alt+DEL 키 조합을 SAS(보안 주의 시퀀스)라고 합니다. 다른 프로그램 및 프로세스가 이를 사용하지 못하도록 하기 위해 Winlogon은 부팅 프로세스 중에 이 시퀀스를 등록합니다.

SAS를 받은 후 UI는 등록된 자격 증명 공급자로부터 받은 정보에서 로그인 타일을 생성합니다. 다음 그래픽에서는 Windows 운영 체제의 자격 증명 공급자에 대한 아키텍처를 보여 줍니다.

일반적으로 로컬 계정 또는 도메인 계정을 사용하여 컴퓨터에 로그인하는 사용자는 사용자 이름과 암호를 입력해야 합니다. 이러한 자격 증명은 사용자의 ID를 확인하는 데 사용됩니다. 스마트 카드 로그인의 경우 사용자의 자격 증명이 스마트 카드 보안 칩에 포함됩니다. 스마트 카드 판독기를 사용하면 컴퓨터가 스마트 카드 보안 칩과 상호 작용할 수 있습니다. 사용자가 스마트 카드 사용하여 로그인하면 사용자 이름과 암호 대신 PIN(개인 식별 번호)을 입력합니다.

자격 증명 공급자는 로컬 시스템에서 실행되고 자격 증명을 수집하는 데 사용되는 프로세스 내 COM 개체입니다. 로그온 UI는 대화형 UI 렌더링을 제공하고, Winlogon은 대화형 로그인 인프라를 제공하며, 자격 증명 공급자는 자격 증명을 수집하고 처리하는 데 도움이 되도록 이러한 두 구성 요소와 함께 작동합니다.

Winlogon은 SAS 이벤트를 받은 후 자격 증명 공급자 타일을 표시하도록 로그온 UI에 지시합니다. 로그온 UI는 각 자격 증명 공급자에게 열거하려는 자격 증명 수를 쿼리합니다. 자격 증명 공급자는 이러한 타일 중 하나를 기본값으로 지정할 수 있습니다. 모든 공급자가 타일을 열거하면 로그온 UI가 사용자에게 표시됩니다. 사용자는 타일과 상호 작용하여 적절한 자격 증명을 제공합니다. 로그온 UI는 인증을 위해 이러한 자격 증명을 제출합니다.

지원 하드웨어와 결합된 자격 증명 공급자는 Windows 운영 체제를 확장하여 사용자가 생체 인식(예: 지문, 망막 또는 음성 인식), 암호, PIN, 스마트 카드 인증서 또는 사용자 지정 인증 패키지를 사용하여 로그인할 수 있도록 할 수 있습니다. 엔터프라이즈 및 IT 전문가는 모든 도메인 사용자에 대한 사용자 지정 인증 메커니즘을 개발하고 배포할 수 있으며 사용자가 이 사용자 지정 로그인 메커니즘을 사용하도록 명시적으로 요구할 수 있습니다.

참고

자격 증명 공급자는 적용 메커니즘이 아닙니다. 자격 증명을 수집하고 직렬화하는 데 사용됩니다. LSA 및 인증 패키지는 보안을 적용합니다.

자격 증명 공급자는 SSO(Single Sign-In)를 지원하도록 설계할 수 있습니다. 이 프로세스에서는 컴퓨터에 로그인하기 위해 RADIUS 및 기타 기술을 사용하여 보안 네트워크 액세스 지점에 사용자를 인증합니다. 자격 증명 공급자는 애플리케이션별 자격 증명 수집을 지원하도록 설계되었으며 네트워크 리소스 인증, 도메인에 컴퓨터 조인 또는 UAC(사용자 계정 제어)에 대한 관리자 동의를 제공하는 데 사용할 수 있습니다.

여러 자격 증명 공급자는 컴퓨터에서 공존할 수 있습니다.

자격 증명 공급자는 Windows를 실행하는 컴퓨터에 등록해야 하며 다음을 담당합니다.

• 인증에 필요한 자격 증명 정보 설명
• 외부 인증 기관과의 통신 및 논리 처리
• 대화형 및 네트워크 로그인을 위한 자격 증명 패키징

참고

자격 증명 공급자 API는 UI를 렌더링하지 않습니다. 렌더링해야 하는 항목에 대해 설명합니다.
암호 자격 증명 공급자만 안전 모드에서 사용할 수 있습니다.
스마트 카드 자격 증명 공급자는 네트워킹 중에 안전 모드에서 사용할 수 있습니다.

스마트 카드 하위 시스템 아키텍처

공급업체는 스마트 카드와 스마트 카드 판독기를 제공하며, 대부분의 경우 공급업체는 스마트 카드 스마트 카드 판독기와 다릅니다. 스마트 카드 판독기용 드라이버는 PC/SC(개인용 컴퓨터/스마트 카드) 표준에 기록됩니다. 각 스마트 카드 암호화 작업을 사용하도록 설정하기 위해 CryptoAPI 인터페이스를 사용하는 CSP(암호화 서비스 공급자)와 스마트 카드 하드웨어와의 통신을 사용하도록 설정하는 WinSCard API가 있어야 합니다.

기본 CSP 및 스마트 카드 미니드라이버 아키텍처

다음 그래픽은 CryptoAPI, CSP, 기본 CSP(스마트 카드 기본 암호화 서비스 공급자) 및 스마트 카드 미니 드라이버 간의 관계를 보여 줍니다.

기본 CSP 및 스마트 카드 KSP를 사용하여 캐싱

스마트 카드 아키텍처는 캐싱 메커니즘을 사용하여 작업을 간소화하고 PIN에 대한 사용자의 액세스를 개선합니다.

• 데이터 캐싱: 데이터 캐시는 스마트 카드 I/O 작업을 최소화하는 단일 프로세스를 제공합니다.
• PIN 캐싱: PIN 캐시는 스마트 카드 인증되지 않은 경우 사용자가 PIN을 다시 입력할 필요가 없도록 도와줍니다.

데이터 캐싱

각 CSP는 현재 스마트 카드 데이터 캐시를 별도로 구현합니다. 기본 CSP는 단일 프로세스가 스마트 카드 I/O 작업을 최소화할 수 있는 강력한 캐싱 메커니즘을 구현합니다.

기존 전역 캐시는 다음과 같이 작동합니다.

1. 애플리케이션은 암호화 작업을 요청합니다. 예를 들어 사용자 인증서는 스마트 카드 읽어야 합니다.
2. CSP는 항목에 대한 캐시를 확인합니다.
3. 항목이 캐시에 없거나 항목이 캐시되었지만 최신 상태가 아닌 경우 스마트 카드
4. 스마트 카드 항목을 읽은 후 캐시에 추가됩니다. 해당 항목의 기존 오래된 복사본이 대체됩니다.

세 가지 유형의 개체 또는 데이터는 CSP에 의해 캐시됩니다. 핀(자세한 내용은 PIN 캐싱 참조), 인증서 및 파일. 캐시된 데이터가 변경되면 해당 개체는 연속 작업에서 스마트 카드 읽습니다. 예를 들어 파일이 스마트 카드 기록되면 CSP 캐시가 파일에 대한 최신 상태가 되고 다른 프로세스는 스마트 카드 한 번 이상 읽어 CSP 캐시를 새로 고칩니다.

전역 데이터 캐시는 Windows용 스마트 카드 서비스에서 호스트됩니다. Windows에는 SCardWriteCache 및 SCardReadCache라는 두 개의 공용 스마트 카드 API 호출이 포함되어 있습니다. 이러한 API 호출은 애플리케이션에서 사용할 수 있는 전역 데이터 캐싱 기능을 만듭니다. 스마트 카드 미니 드라이버 사양을 준수하는 모든 스마트 카드 16 바이트 카드 식별자가 있습니다. 이 값은 지정된 스마트 카드 관련된 캐시된 데이터를 고유하게 식별하는 데 사용됩니다. 표준 Windows GUID 유형이 사용됩니다. 이러한 API를 사용하면 애플리케이션에서 전역 캐시에 데이터를 추가하고 데이터를 읽을 수 있습니다.

PIN 캐싱

PIN 캐시는 스마트 카드 인증되지 않은 경우 사용자가 PIN을 입력하지 못하도록 보호합니다. 스마트 카드 인증된 후에는 호스트 쪽 애플리케이션과 구분되지 않습니다. 모든 애플리케이션은 스마트 카드 프라이빗 데이터에 액세스할 수 있습니다.

이를 완화하기 위해 스마트 카드 애플리케이션이 스마트 카드 인증할 때 배타적 상태가 됩니다. 그러나 이는 다른 애플리케이션이 스마트 카드 통신할 수 없고 차단됨을 의미합니다. 따라서 이러한 배타적 연결은 최소화됩니다. 문제는 프로토콜(예: Kerberos 프로토콜)에 여러 서명 작업이 필요하다는 것입니다. 따라서 프로토콜은 장기간에 걸쳐 스마트 카드 대한 단독 액세스가 필요하거나 여러 인증 작업이 필요합니다. 여기서 PIN 캐시는 사용자가 PIN을 여러 번 입력하도록 강제하지 않고 스마트 카드 단독 사용을 최소화하는 데 사용됩니다.

다음 예제에서는 작동 방식을 보여 줍니다. 이 시나리오에는 Outlook 및 인터넷 Explorer 두 가지 애플리케이션이 있습니다. 애플리케이션은 다양한 용도로 스마트 카드를 사용합니다.

1. 사용자가 Outlook을 시작하고 서명된 전자 메일을 보내려고 합니다. 프라이빗 키는 스마트 카드
2. Outlook에서 사용자에게 스마트 카드 PIN을 묻는 메시지를 표시합니다. 사용자가 올바른 PIN을 입력합니다.
3. 서명 작업을 위해 전자 메일 데이터가 스마트 카드 전송됩니다. Outlook 클라이언트는 응답 형식을 지정하고 전자 메일을 보냅니다.
4. 사용자가 인터넷 Explorer 열고 클라이언트에 대한 TLS(전송 계층 보안) 인증이 필요한 보호된 사이트에 액세스하려고 시도합니다.
5. 인터넷 Explorer 사용자에게 스마트 카드 PIN을 묻는 메시지를 표시합니다. 사용자가 올바른 PIN을 입력합니다.
6. TLS 관련 프라이빗 키 작업은 스마트 카드 발생하며 사용자가 인증되고 로그인됩니다.
7. 사용자가 Outlook으로 돌아와서 서명된 다른 전자 메일을 보냅니다. 이번에는 PIN이 이전 작업에서 캐시되었기 때문에 사용자에게 PIN을 묻는 메시지가 표시되지 않습니다. 마찬가지로 사용자가 다른 작업에 인터넷 Explorer 다시 사용하는 경우 인터넷 Explorer 사용자에게 PIN을 묻는 메시지가 표시되지 않습니다.

기본 CSP는 내부적으로 PIN의 프로세스별 캐시를 유지 관리합니다. PIN은 암호화되어 메모리에 저장됩니다. PIN을 보호하는 데 사용되는 함수는 RTlEncryptMemory, RtlDecryptMemory 및 RtlSecureZeroMemory이며, 이 함수는 PIN이 포함된 버퍼를 비워 줍니다.

스마트 카드 선택

이 문서의 다음 섹션에서는 Windows가 스마트 카드 아키텍처를 사용하여 성공적인 스마트 카드 로그인을 위해 올바른 스마트 카드 판독기 소프트웨어, 공급자 및 자격 증명을 선택하는 방법을 설명합니다.

• 컨테이너 사양 수준
• 컨테이너 작업
• 컨텍스트 플래그
• 자동 컨텍스트에서 새 컨테이너 만들기
• 스마트 카드 선택 동작
• 스마트 카드 판독기 일치
• 스마트 카드 일치
• 기존 기본 컨테이너 열기(판독기가 지정되지 않음)
• 기존 GUID 명명 컨테이너 열기(판독기가 지정되지 않음)
• 새 컨테이너 만들기(판독기가 지정되지 않음)
• 컨테이너 삭제

컨테이너 사양 수준

CryptoAPI의 CryptAcquireContext 호출에 대한 응답으로 기본 CSP는 호출자가 지정하는 컨테이너를 특정 스마트 카드 및 판독기와 일치시키려고 시도합니다. 호출자는 다음 표와 같이 다양한 수준의 특이성을 가진 컨테이너 이름을 제공하고 가장 구체적인 요청에서 최소 특정 요청으로 정렬할 수 있습니다.

마찬가지로 CNG의 NCryptOpenKey 호출에 대한 응답으로 스마트 카드 KSP는 컨테이너를 동일한 방식으로 일치시키려고 시도하며 다음 표와 같이 동일한 컨테이너 형식을 사용합니다.

참고

스마트 카드 KSP를 사용하여 키를 열기 전에 NCryptOpenStorageProvider(MS_SMART_CARD_KEY_STORAGE_PROVIDER)를 호출해야 합니다.

Type	이름	Format
나	판독기 이름 및 컨테이너 이름	\.<Reader Name><Container Name>
Ii	읽기 권한자 이름 및 컨테이너 이름(NULL)	\.<Reader Name>
Iii	컨테이너 이름만	<Container Name>
IV	기본 컨테이너(NULL) 전용	Null

기본 CSP 및 스마트 카드 KSP 캐시 스마트 카드 호출 프로세스 및 프로세스에서 액세스한 스마트 카드에 대한 정보를 처리합니다. 스마트 카드 컨테이너를 검색할 때 기본 CSP 또는 스마트 카드 KSP는 먼저 프로세스에 대한 캐시를 확인합니다. 캐시된 핸들이 잘못되었거나 일치하는 항목이 없으면 SCardUIDlg API가 호출되어 카드 핸들을 가져옵니다.

컨테이너 작업

CryptAcquireContext를 사용하여 다음 세 가지 컨테이너 작업을 요청할 수 있습니다.

1. 새 컨테이너를 만듭니다. (dwFlags가 CRYPT_NEWKEYSET 설정된 CryptAcquireContext에 해당하는 CNG는 NCryptCreatePersistedKey입니다.)
2. 기존 컨테이너를 엽니다. (컨테이너를 열기 위한 CryptAcquireContext에 해당하는 CNG는 NCryptOpenKey입니다.)
3. 컨테이너를 삭제합니다. (dwFlags가 CRYPT_DELETEKEYSET 설정된 CryptAcquireContext에 해당하는 CNG는 NCryptDeleteKey입니다.)

암호화 핸들을 특정 스마트 카드 및 판독기와 연결하는 데 사용되는 추론은 요청된 컨테이너 작업 및 사용된 컨테이너 사양 수준을 기반으로 합니다.

다음 표에서는 컨테이너 만들기 작업에 대한 제한을 보여 줍니다.

사양	제한
자동 컨텍스트 없음	키 컨테이너 만들기는 항상 PIN 프롬프트와 같은 UI를 표시할 수 있어야 합니다.
기존 컨테이너를 덮어쓰지 않음	선택한 스마트 카드 지정된 컨테이너가 이미 있는 경우 다른 스마트 카드 선택하거나 작업을 취소합니다.

컨텍스트 플래그

다음 표에서는 컨테이너 만들기 작업에 대한 제한으로 사용되는 컨텍스트 플래그를 보여 줍니다.

Flag	설명
CRYPT_SILENT	이 작업 중에는 UI를 표시할 수 없습니다.
CRYPT_MACHINE_KEYSET	이 작업 중에는 캐시된 데이터를 사용하지 않아야 합니다.
CRYPT_VERIFYCONTEXT	스마트 카드 공용 데이터만 액세스할 수 있습니다.

컨테이너 작업 및 컨테이너 사양 외에도 스마트 카드 선택하는 동안 CryptAcquireContext 플래그와 같은 다른 사용자 옵션을 고려해야 합니다.

중요

CRYPT_SILENT 플래그를 사용하여 새 컨테이너를 만들 수 없습니다.

자동 컨텍스트에서 새 컨테이너 만들기

애플리케이션은 를 사용하여 기본 CSP를 CRYPT_DEFAULT_CONTAINER_OPTIONAL호출하고, 자동 컨텍스트에서 PIN을 설정한 다음, 자동 컨텍스트에서 새 컨테이너를 만들 수 있습니다. 이 작업은 다음과 같이 발생합니다.

1. 의 스마트 카드 판독기 이름을 형식 II 컨테이너 사양 수준으로 전달하고 플래그를 지정하여 CryptAcquireContext를 CRYPT_DEFAULT_CONTAINER_OPTIONAL 호출합니다.
2. 또는 PP_SIGNATURE_PIN 및 null로 종료된 ASCII PIN을 지정하여 PP_KEYEXCHANGE_PIN CryptSetProvParam을 호출합니다.
3. 1단계에서 얻은 컨텍스트 해제
4. 를 사용하여 CryptAcquireContext를 CRYPT_NEWKEYSET호출하고 I 컨테이너 사양 수준 형식을 지정합니다.
5. CryptGenKey를 호출하여 키 만들기

스마트 카드 선택 동작

다음 시나리오 중 일부에서는 스마트 카드 삽입하라는 메시지가 사용자에게 표시될 수 있습니다. 사용자 컨텍스트가 자동인 경우 이 작업이 실패하고 UI가 표시되지 않습니다. 그렇지 않으면 UI에 대한 응답으로 스마트 카드 삽입하거나 취소를 선택할 수 있습니다. 사용자가 작업을 취소하면 작업이 실패합니다. 흐름도에는 Windows 운영 체제에서 수행하는 선택 단계가 표시됩니다.

일반적으로 스마트 카드 선택 동작은 SCardUIDlgSelectCard API에서 처리됩니다. 기본 CSP는 직접 호출하여 이 API와 상호 작용합니다. 또한 기본 CSP는 후보 스마트 카드를 필터링하고 일치시키는 용도의 콜백 함수를 보냅니다. CryptAcquireContext의 호출자는 스마트 카드 일치 정보를 제공합니다. 내부적으로 기본 CSP는 스마트 카드 일련 번호, 판독기 이름 및 컨테이너 이름의 조합을 사용하여 특정 스마트 카드를 찾습니다.

에 대한 SCardUI * 각 호출은 후보 스마트 카드 추가 정보를 읽을 수 있습니다. 기본 CSP 스마트 카드 선택 콜백은 이 정보를 캐시합니다.

스마트 카드 판독기 일치

형식 I 및 형식 II 컨테이너 사양 수준의 경우 명명된 판독기에서 스마트 카드 일치로 간주될 수 있으므로 스마트 카드 선택 프로세스가 덜 복잡합니다. 스마트 카드 스마트 카드 판독기를 일치시키는 프로세스는 다음과 같습니다.

1. 요청된 스마트 카드 판독기를 찾습니다. 찾을 수 없는 경우 프로세스가 실패합니다(읽기 권한자 이름으로 캐시 검색 필요).
2. 판독기에서 스마트 카드 없는 경우 스마트 카드 삽입하라는 메시지가 사용자에게 표시됩니다. (이는 비실용 모드에만 해당됩니다. 자동 모드에서 호출이 수행되면 실패함)
3. 컨테이너 사양 수준 II만의 경우 선택한 스마트 카드 기본 컨테이너의 이름이 결정됩니다.
4. 기존 컨테이너를 열거나 기존 컨테이너를 삭제하려면 지정된 컨테이너를 찾습니다. 이 스마트 카드 지정된 컨테이너를 찾을 수 없는 경우 사용자에게 스마트 카드 삽입하라는 메시지가 표시됩니다.
5. 시스템에서 새 컨테이너를 만들려고 하면 이 스마트 카드 지정된 컨테이너가 이미 있는 경우 프로세스가 실패합니다.

스마트 카드 일치

컨테이너 사양 수준 III 및 IV의 경우 여러 캐시된 스마트 카드가 제공된 조건을 충족할 수 있으므로 사용자 컨텍스트와 적절한 스마트 카드 일치시키는 데 더 광범위한 메서드가 사용됩니다.

기존 기본 컨테이너 열기(판독기가 지정되지 않음)

참고

이 작업을 수행하려면 기본 CSP에서 스마트 카드 사용해야 합니다.

1. 기본 CSP에서 액세스하고 핸들 및 컨테이너 정보가 캐시되는 각 스마트 카드 대해 기본 CSP는 유효한 기본 컨테이너를 찾습니다. 캐시된 SCARDHANDLE에서 해당 유효성을 확인하기 위한 작업이 시도됩니다. 스마트 카드 핸들이 유효하지 않으면 기본 CSP는 계속해서 새 스마트 카드 검색합니다.
2. 일치하는 스마트 카드 기본 CSP 캐시에 없는 경우 기본 CSP는 스마트 카드 하위 시스템을 호출합니다. SCardUIDlgSelectCard()는 적절한 콜백 필터와 함께 사용하여 유효한 기본 컨테이너와 일치하는 스마트 카드 찾습니다.

기존 GUID 명명 컨테이너 열기(판독기가 지정되지 않음)

참고

이 작업을 수행하려면 기본 CSP에서 스마트 카드 사용해야 합니다.

1. 기본 CSP에 이미 등록된 각 스마트 카드 대해 요청된 컨테이너를 검색합니다. 캐시된 SCARDHANDLE에서 작업을 시도하여 유효성을 확인합니다. 스마트 카드 핸들이 유효하지 않으면 스마트 카드 일련 번호가 API에 SCardUI * 전달되어 컨테이너 이름에 대한 일반적인 일치 항목이 아닌 이 특정 스마트 카드 계속 검색합니다.
2. 일치하는 스마트 카드 기본 CSP 캐시에 없는 경우 스마트 카드 하위 시스템에 대한 호출이 이루어집니다. SCardUIDlgSelectCard()는 요청된 컨테이너와 일치하는 스마트 카드 찾기 위해 적절한 콜백 필터와 함께 사용됩니다. 또는 1단계의 검색에서 스마트 카드 일련 번호가 발생한 경우 콜백 필터는 컨테이너 이름이 아닌 일련 번호와 일치하려고 시도합니다.

새 컨테이너 만들기(판독기가 지정되지 않음)

참고

이 작업을 수행하려면 기본 CSP에서 스마트 카드 사용해야 합니다.

PIN이 캐시되지 않은 경우 최소한 사용자에게 PIN을 묻는 메시지가 표시되어야 하므로 컨테이너 만들기에 대한 CRYPT_SILENT 허용되지 않습니다.

다른 작업의 경우 호출자는 기본 컨테이너 CRYPT_DEFAULT_CONTAINER_OPTIONAL 에 대한 확인 컨텍스트를 획득한 다음 CryptSetProvParam을 호출하여 후속 작업을 위해 사용자 PIN을 캐시할 수 있습니다.

1. CSP에서 이미 알려진 각 스마트 카드 대해 저장된 SCARDHANDLE을 새로 고치고 다음 검사를 수행합니다.
   1. 스마트 카드 제거된 경우 검색을 계속합니다.
   2. 스마트 카드 있지만 이미 명명된 컨테이너가 있는 경우 검색을 계속합니다.
   3. 스마트 카드 사용할 수 있지만 CardQueryFreeSpace를 호출하면 스마트 카드 추가 키 컨테이너에 대한 스토리지가 충분하지 않음을 나타내는 경우 검색을 계속합니다.
   4. 그렇지 않으면 컨테이너 만들기에 대해 위의 조건을 충족하는 사용 가능한 첫 번째 스마트 카드 사용합니다.
2. 일치하는 스마트 카드 CSP 캐시에 없는 경우 스마트 카드 하위 시스템을 호출합니다. 열거형 스마트 카드를 필터링하는 데 사용되는 콜백은 후보 스마트 카드 명명된 컨테이너가 없는지 확인하고 CardQueryFreeSpace는 스마트 카드 추가 컨테이너를 위한 충분한 공간이 있음을 나타냅니다. 적합한 스마트 카드 없는 경우 사용자에게 스마트 카드 삽입하라는 메시지가 표시됩니다.

컨테이너 삭제

1. 지정된 컨테이너 이름이 NULL이면 기본 컨테이너가 삭제됩니다. 기본 컨테이너를 삭제하면 새 기본 컨테이너가 임의로 선택됩니다. 이러한 이유로 이 작업은 권장되지 않습니다.
2. CSP에서 이미 알려진 각 스마트 카드 대해 저장된 SCARDHANDLE을 새로 고치고 다음 검사를 수행합니다.
   1. 스마트 카드 명명된 컨테이너가 없는 경우 검색을 계속합니다.
   2. 스마트 카드 명명된 컨테이너가 있지만 스마트 카드 핸들이 더 이상 유효하지 않은 경우 일치하는 스마트 카드 일련 번호를 저장하고 SCardUI에 전달합니다.
3. 일치하는 스마트 카드 CSP 캐시에 없는 경우 스마트 카드 하위 시스템을 호출합니다. 열거형 스마트 카드를 필터링하는 데 사용되는 콜백은 후보 스마트 카드 명명된 컨테이너가 있는지 확인해야 합니다. 이전 캐시 검색의 결과로 일련 번호가 제공된 경우 콜백은 컨테이너 일치가 아닌 일련 번호에 열거된 스마트 카드를 필터링해야 합니다. 컨텍스트가 비사음이고 적합한 스마트 카드 없는 경우 사용자에게 스마트 카드 삽입하라는 메시지를 표시하는 UI를 표시합니다.

Windows의 기본 CSP 및 KSP 기반 아키텍처

다음 다이어그램은 Windows 운영 체제에서 사용하는 암호화 아키텍처를 보여줍니다.

Windows의 기본 CSP 및 스마트 카드 KSP 속성

참고

API 정의는 WinCrypt.h 및 WinSCard.h에 있습니다.

속성	설명
PP_USER_CERTSTORE	- 스마트 카드 모든 사용자 인증서를 포함하는 를 반환 HCERTSTORE 하는 데 사용됩니다. - 읽기 전용(에서 CryptGetProvParam만 사용됨) - 인증서 저장소 닫기를 담당하는 호출자 - 또는 를 사용하여 PKCS_7_ASN_ENCODING 인코딩된 인증서 X509_ASN_ENCODING - 인증서에 CSP를 설정 KEY_PROV_INFO 해야 합니다. - 인증서 저장소는 메모리 내 저장소로 간주되어야 합니다. - 인증서는 속성으로 유효 CRYPT_KEY_PROV_INFO 해야 합니다.
PP_ROOT_CERTSTORE	- 읽기 및 쓰기(및 CryptSetProvParam에서 CryptGetProvParam 사용) - 스마트 카드 루트 인증서 컬렉션을 쓰거나 스마트 카드 루트 인증서를 포함하는 를 반환HCERTSTORE하는 데 사용됩니다. - 주로 스마트 카드 사용하여 도메인에 가입하는 데 사용됩니다. - 인증서 저장소 닫기를 담당하는 호출자
PP_SMARTCARD_READER	- 읽기 전용(에서 CryptGetProvParam만 사용됨) - 스마트 카드 판독기 이름을 정규화된 컨테이너 이름(즉, 스마트 카드 판독기 및 컨테이너)을 생성하는 데 사용되는 ANSI 문자열로 반환합니다.
PP_SMARTCARD_GUID	- 각 스마트 카드 대해 고유해야 하는 스마트 카드 GUID(일련 번호라고도 함)를 반환합니다. - 인증서 전파 서비스에서 루트 인증서의 원본을 추적하는 데 사용됩니다.
PP_UI_PROMPT	- 카드 삽입 대화 상자에 대한 검색 문자열을 SCardUIDlgSelectCard 설정하는 데 사용됩니다. - 설정 시 전체 프로세스에 대한 영구 - 쓰기 전용(에서 CryptSetProvParam만 사용됨)

Windows의 CSP에 대한 의미

사용자 지정 스마트 카드 CSP를 포함한 CSP(암호화 서비스 공급자)는 계속 지원되지만 이 방법은 권장되지 않습니다. 스마트 카드용 스마트 카드 미니드라이버 모델과 기존 기본 CSP 및 스마트 카드 KSP를 사용하면 성능 및 PIN 및 데이터 캐싱 측면에서 상당한 이점을 얻을 수 있습니다. CryptoAPI 및 CNG 계층에서 작동하도록 하나의 미니 드라이버를 구성할 수 있습니다. 이는 타원 곡선 암호화 및 AES를 포함하여 향상된 암호화 지원의 이점을 제공합니다.

스마트 카드 CSP 및 스마트 카드 미니 드라이버에 의해 등록된 경우 가장 최근에 설치된 스마트 카드 통신하는 데 사용됩니다.

스마트 카드 미니드라이버, CSP 또는 KSP 작성

CSP 및 KSP는 현재 스마트 카드 미니 드라이버 아키텍처에서 특정 기능을 사용할 수 없는 경우에만 작성됩니다. 예를 들어 스마트 카드 미니 드라이버 아키텍처는 하드웨어 보안 모듈을 지원하므로 하드웨어 보안 모듈용으로 미니 드라이버를 작성할 수 있으며, 기본 CSP 또는 스마트 카드 KSP에서 구현되지 않은 알고리즘을 지원하는 데 필요한 경우가 아니면 CSP 또는 KSP가 필요하지 않을 수 있습니다.

스마트 카드 미니드라이버, CSP 또는 KSP를 작성하는 방법에 대한 자세한 내용은 스마트 카드 미니 드라이버를 참조하세요.