집 > 단어 > Lissy 소프트 루트 인증서. 위키 섹션. CA 사용자는 전자 서명 키가 다른 사람에 의해 사용되었거나 이전에 사용되었음을 알게 된 경우 전자 서명 키를 사용하지 않을 의무가 있습니다.


Lissy 소프트 루트 인증서. 위키 섹션. CA 사용자는 전자 서명 키가 다른 사람에 의해 사용되었거나 이전에 사용되었음을 알게 된 경우 전자 서명 키를 사용하지 않을 의무가 있습니다.




시스템 요구 사항

  • 인터넷 접속
  • 운영 체제: 윈도우 8, 7, XP SP 3/2
  • 프로세서: 1.6GHz 이상
  • RAM: 512MB
  • 지원되는 암호화 공급자 중 하나의 가용성: CryptoPro CSP 3.6 이상, LISSI CSP, VIPNet CSP, Signal-COM CSP
  • 화면 해상도: 최소 800x600px

인증된 암호화폐 공급자를 사용하세요

Ekey.Signature 프로그램이 작동하려면 직장에 GOST 알고리즘에 따라 문서를 암호화하는 암호화 정보 보호 도구(CIPF)가 있어야 합니다. 3.6 이상의 CryptoPro CSP 시스템, LISSI CSP, VIPNet CSP, Signal-COM CSP를 CIPF로 사용할 수 있습니다.

암호화 정보 보호 도구는 Ekay.Signature와 호환되지만 서로 호환되지 않습니다. 하나의 사업장에는 하나의 CIPF만 설치할 수 있습니다.

바이러스 백신 사용

직장에 널리 사용되는 바이러스 백신을 설치하고 정기적으로 업데이트하십시오. 바이러스 백신은 바이러스, 스파이웨어로부터 보호하고 대부분의 보안 위협을 독립적으로 제거합니다.

비밀번호로 전자 서명과 직장에 대한 접근을 보호하세요

EKEY.Signature 및 암호화 보호를 사용할 때 낯선 사람의 물리적 접근으로부터 컴퓨터를 보호하십시오. 비밀번호 액세스를 사용하세요.

전자 서명에 접근하려면 복잡한 비밀번호를 사용하세요. 좋은 비밀번호는 데이터의 보안을 보장합니다. 비밀번호를 기억하는 좋은 방법은 전자서명 거래 시 비밀번호를 지속적으로 입력하는 것입니다.

비밀번호를 저장하기에 가장 좋은 장소는 메모리입니다. 비밀번호를 어디에든 적어 두는 것은 바람직하지 않습니다. 물리적인 전자 서명 매체 옆에 비밀번호를 저장하지 말고, 시스템에 비밀번호를 저장하지 마십시오.

라이센스가 있는 최신 프로그램만 사용하십시오.

귀하의 사업장에 설치된 프로그램은 정기적으로 업데이트되어 업무의 안정성과 보안성을 높여드립니다.

프로그램 업데이트는 공식 사이트에서만 설치하시기 바라며, 설치 전 사이트 주소와 프로그램 게시자 정보를 확인하시기 바랍니다.

Ekey.Signature 설치

1. 다운로드

2. 프로그램 설치를 시작하려면 설치 파일을 실행하세요. 사용자 계정 컨트롤을 실행하는 경우 Ekey Transfer 프로그램이 변경되도록 허용해야 합니다.

Rosreestr용 파일 준비

1. 기본 프로그램 창이나 파일 컨텍스트 메뉴에서 "Rosreestr" 작업 유형을 선택합니다.


3. 파일 첨부 버튼을 사용하여 보고서를 추가하거나 마우스를 사용하여 파일을 끌어서 놓습니다.
4. "생성" 버튼을 클릭하세요.
6. 작업 완료 후 서명 파일은 원본 파일과 동일한 디렉터리에 저장되며, 분리된 서명 파일은 원본 파일을 사용할 수 있는 경우에만 유효합니다.

러시아 연방 금융 시장 서비스, 러시아 은행 서비스, 중앙 은행용 컨테이너 준비

1. "러시아의 FSFM" 작업 유형을 선택합니다.

2. 개인 인증서를 선택합니다.

3. "파일 첨부" 버튼을 사용하여 확장자가 xtdd 또는 smcl인 보고서를 추가하거나 마우스를 사용하여 파일을 끌어서 놓습니다.

5. 필요한 경우 개인 키 컨테이너의 비밀번호를 입력하세요.

7. 공동 서명을 추가하려면 이전에 생성된 컨테이너를 첨부하고 원하는 인증서를 선택한 후 생성 버튼을 클릭합니다.

8. 러시아 은행 서비스(FSFM) 포털로 보고서를 보내려면 추가 버튼을 클릭하고 표시되는 메뉴에서 보고서가 포함된 필수 컨테이너를 선택한 다음 포털에 업로드 버튼을 클릭합니다.

FSIS TP 러시아 지역 개발부

1. "FSIS TP" 작업 유형을 선택합니다.

2. 개인 인증서를 선택합니다.

3. 파일 첨부 버튼을 사용하여 보고서를 추가하거나 마우스를 사용하여 파일을 끌어서 놓습니다.

4. '생성' 버튼을 클릭하세요.

5. 필요한 경우 개인 키 컨테이너의 비밀번호를 입력하세요.

6. 나타나는 저장 메뉴에서 작업 결과를 저장할 위치를 선택합니다.

Roskomnadzor 등록 (zapret-info.gov.ru)

1. Roskomnadzor 레지스트리 작업을 선택하십시오.

2. 개인인증서를 선택하세요.

3. 레지스트리의 마지막 업데이트 시간을 확인하려면 "레지스트리에서 언로드한 마지막 업데이트 시간"을 클릭하세요.

4. 요청을 보내려면 '요청 보내기'를 클릭하세요.

요청을 생성하려면 필드를 채우세요.

5. 요청 처리 결과를 확인하려면 “결과 요청”을 클릭하세요.

레지스트리를 자동으로 다운로드하려면 "자동 다운로드" 확인란을 선택하고 필요한 다운로드 기간을 설정한 후 다운로드 결과를 저장할 디렉터리를 지정해야 합니다.

ISED

1. 동작 유형을 'ISED'로 선택하세요.

2. 파일 첨부 버튼을 사용하여 보고서를 추가하거나 마우스를 사용하여 파일을 끌어서 놓습니다.

3. 수신자 인증서 선택

4. '생성' 버튼을 클릭하세요.

5. 나타나는 저장 메뉴에서 작업 결과를 저장할 위치를 선택합니다.

파일 서명

1. "수동으로 서명" 작업 유형을 선택합니다.

2. 개인 인증서를 선택합니다.

4. 필요한 서명 옵션을 선택합니다.

5. '서명' 버튼을 클릭하세요.

6. 필요한 경우 개인 키 컨테이너의 비밀번호를 입력하세요.

설명:

서명을 별도의 파일에 저장

플래그를 체크하면 첨부되지 않은 전자 서명이 생성됩니다.플래그가 없는 경우 파일 끝에 서명을 추가합니다. (이 경우 문서와 전자서명이 함께 저장됩니다.)

아카이브 파일

서명 후 파일을 보관해야 합니까?

확대 - 기본 서명 파일 확장자는 sig이며, 자신만의 확장자를 지정할 수도 있습니다.

부호화 - Der 또는 Base-64가 필요한 인코딩을 선택하세요.

서비스 헤더 비활성화- Base-64 인코딩을 선택한 경우(제3자 소프트웨어와의 호환성을 위해 헤더가 사용됨)

파일 암호화

1. "수동 암호화" 작업 유형을 선택합니다.

2. 개인 인증서를 선택합니다.

3. 파일 첨부 버튼을 이용하여 파일을 추가하거나, 마우스로 파일을 끌어다 놓습니다.

4. 필요한 암호화 옵션을 선택합니다.

5. 사용 가능한 수신자 인증서(파일이 암호화될 대상)를 추가하거나 선택합니다.

6. "암호화" 버튼을 클릭하세요.

7. 필요한 경우 개인 키 컨테이너의 비밀번호를 입력하세요.

8. 나타나는 저장 메뉴에서 작업 결과를 저장할 위치를 선택합니다. 설명:

부호화

Der 또는 Base-64가 필요한 인코딩을 선택하세요.

확대

최종 파일의 확장자(기본적으로 enc)를 사용자가 직접 지정할 수도 있습니다. 서비스 헤더 비활성화 - Base-64 인코딩이 선택된 경우(타사 소프트웨어와의 호환성을 위해 필요)

암호화 전 파일 보관

암호화하기 전에 파일을 보관해야 하는 경우 해당 상자를 선택하십시오.

여러 파일을 추가하면 모든 파일이 하나의 아카이브로 압축됩니다.

파일 복호화

1. 작업 유형 "암호 해독"을 선택합니다.

2. 개인 인증서를 선택합니다.

3. 파일 첨부 버튼을 이용하여 파일을 추가하거나, 마우스로 파일을 끌어다 놓습니다.

4. “암호해독” 버튼을 클릭하세요.

5. 필요한 경우 개인 키 컨테이너의 비밀번호를 입력하세요.

6. 나타나는 저장 메뉴에서 작업 결과를 저장할 위치를 선택합니다.

서명 확인

1. 서명 확인을 시작하려면 귀하에게 편리한 확인 방법을 사용하십시오.

  • 서명이 포함된 파일을 두 번 클릭합니다.
  • 기본 프로그램 메뉴에서 "서명 확인" 작업 유형을 선택합니다.
  • 확인해야 할 파일의 컨텍스트 메뉴를 통해.

2. 파일 첨부 버튼을 이용해 파일을 추가하거나, 마우스로 파일을 끌어다 놓습니다.

3. 확인 버튼을 클릭하세요.

“확인” 버튼을 클릭하면 서명 확인 결과 창이 나타납니다. 여기에서 서명 트리를 보고, 확인 결과를 인쇄하고, 보기 위해 소스 파일을 열 수 있습니다.

또한, 스캔하는 동안 doc xls csv pdf html htm txt xml zip png jpeg jpg bmp gif 확장자를 가진 파일의 내용을 볼 수 있습니다.

설명:

파일에서 서명 제거

첨부된 서명이 생성된 경우 이 옵션을 사용하면 서명이 포함되지 않은 원본 파일을 얻을 수 있습니다.

서명 추가

1. '서명 추가' 작업 유형을 선택합니다.

2. 개인 인증서를 선택합니다.

4. '서명' 버튼을 클릭하세요.

5. 필요한 경우 개인 키 컨테이너의 비밀번호를 입력하세요.

6. 나타나는 저장 메뉴에서 작업 결과를 저장할 위치를 선택합니다.

서명을 확인하세요

1. "서명 인증" 작업 유형을 선택합니다.

2. 개인 인증서를 선택합니다.

3. 파일 첨부 버튼을 이용하여 서명 파일을 추가하거나 마우스로 파일을 끌어다 놓습니다.

4. '확인' 버튼을 클릭하세요.

5. 필요한 경우 개인 키 컨테이너의 비밀번호를 입력하세요.

6. 나타나는 메뉴에서 인증이 필요한 서명을 선택하세요

7. 나타나는 저장 메뉴에서 작업 결과를 저장할 위치를 선택합니다.

자동 업데이트

업데이트가 가능해지면 실행 중인 Ekey Signature 애플리케이션의 오른쪽 상단에 해당 메시지가 나타납니다. 업데이트를 시작하려면 업데이트를 마우스 왼쪽 버튼으로 클릭하세요.

업데이트 프로세스가 완료되면 일부 변경 사항은 재부팅 후에만 적용된다는 메시지가 표시되면 "확인"을 클릭하세요. 마침 버튼을 클릭하세요. 그런 다음 컴퓨터를 다시 시작하는 것이 좋습니다. Windows 상황에 맞는 메뉴 작동과 관련된 업데이트를 적용하려면 먼저 재부팅해야 합니다.

루트 인증서 자동 설치

저장소에 루트 인증서가 없는 경우 EKEY 서명 애플리케이션을 실행하면 해당 오류가 사용자 로그에 표시됩니다. 이 경우 "문제가 있는" 개인 인증서를 사용하여 모든 파일에 서명해야 합니다. 서명 작업을 수행할 때 누락된 루트 인증서를 설치하라는 대화 상자가 표시됩니다. 누락된 루트 인증서를 설치하려면 예를 클릭합니다.

독자들은 연구 작업에 초대되며, 그 동안 Linux 사용자들 사이에서 발생하는 디지털 서명 도구 사용과 관련된 여러 가지 문제가 확인되었습니다. 특히, 완전히 명확하지 않은 다음 사항이 명확해졌습니다.

  • 개인 전자 디지털 서명 인증서를 획득하고 사용하여 정부 서비스에 액세스할 수 있는 기회는 현재 상업 기관에서 유료로만 제공됩니다.
  • 서로 다른 승인된 조직이 최종 사용자에게 발행한 전자 서명 데이터 매체는 서로 호환되지 않을 수 있으며 정부 포털을 포함하여 서비스에 대한 액세스를 제공하는 포털과도 호환되지 않을 수 있습니다.
  • 최종 사용자에게 대량 생산되는 전자 서명 데이터 매체의 보안 수준은 일반적으로 현재 사용 가능한 기술 수준에 비해 크게 저하됩니다.
  • 국내 소프트웨어 등록부의 OS 사용자 대부분의 경우 EPGU 소프트웨어와 개인 전자 서명 인증서를 발급하는 승인된 조직의 소프트웨어의 비호환성으로 인해 공공 서비스 통합 포털의 EDS 메커니즘을 사용할 수 없습니다.
  • 경우에 따라 공공 서비스를 제공하는 포털 개발자는 등록부에 포함되지 않은 운영 체제는 물론 사용자 데이터의 보안을 명백히 저하시키는 소프트웨어 및 구성을 사용할 것을 권장합니다.

작업 작성자는 얻은 결과가 EDS 메커니즘을 사용하는 솔루션 사용자, 해당 솔루션을 구현하는 통합자에게 유용할 것이며 정부 정보 서비스 제공 및 구현을 담당하는 조직에서도 고려할 것이라고 기대합니다. 특정 EDS 인프라 메커니즘과 해당 소프트웨어 및 하드웨어 개발자.

무엇에 관한 내용인가요?

이 기사는 ALT OS에서 문서의 전자 디지털 서명(EDS) 지원과 러시아 연방에서 EDS를 사용하는 구체적인 내용을 다루고 있습니다.

주요 임무는 개인이든 법인이든 관계없이 "일반 사용자"™가 일반적으로 수행해야 하는 작업을 이해하여 국내 소프트웨어 등록부의 OS에서 작업할 때 전자 거래 플랫폼 및 정부 서비스 포털의 기능. "전체 사용"이란, 우선 별도의 물리적 매체에 있는 인증서를 사용하여 해당 사이트에서 인증할 수 있는 가능성과 사이트 인터페이스에서 생성된 문서에 전자 서명할 수 있는 가능성을 의미합니다.

이 주제에 대해 이미 많은 연구가 수행되었으며 그 결과 원칙적으로 모든 것이 작동한다는 결론이 나왔습니다. 여기서 이해하는 것이 중요합니다. Linux에서 실행되는 최신 암호화 도구와 러시아 정부 서비스 포털의 호환성에 대한 대부분의 연구는 실험실 조건에서 수행되었습니다. 예를 들어, 연구자와 인증서를 발급하는 인증센터 사이에 특별한 합의가 있는 경우. 불행하게도 이러한 작업의 결과를 바탕으로 일반적으로 행동하는 사람의 실제 능력을 판단하는 것은 어렵습니다.

어떻게 작동하나요?

로그인 및 비밀번호를 입력하지 않고 단순히 하드웨어 토큰을 USB 커넥터에 연결하여 사이트에 액세스하려면 특수 소프트웨어 스택이 운영 체제에서 올바르게 작동해야 합니다(물리적 장치 지원, 암호화 알고리즘, 소프트웨어 인터페이스). , 데이터 교환을 위한 형식 및 프로토콜. 동시에 OS의 책임 영역 외부(인증서를 발급하는 인증 센터 및 액세스가 제공되어야 하는 웹 사이트)에서 암호화 알고리즘, 형식 및 프로토콜의 호환성도 보장되어야 합니다.

그리고 정부 기관의 웹사이트에 대해서도 이야기하고 있다면, 사용되는 암호화폐가 러시아 연방에서 적절하게 사용되도록 인증을 받는 것도 필요합니다.

기본 메커니즘

러시아 연방에서 공식적으로 사용되는 디지털 서명 기술은 공개 키 인프라를 기반으로 합니다. 예제를 사용하여 해당 작업을 살펴보겠습니다.

명확성을 위해 전자 서명과 암호화 모두에 적합한 범용 알고리즘의 작동 메커니즘을 고려해 보겠습니다. 이러한 알고리즘에는 인터넷 표준으로 채택된 RSA와 2001년까지 러시아 연방에서 전자 서명 표준으로 시행되었던 Russian GOST R 34.10-94가 포함됩니다. 일반적으로 현재 유효한 GOST R 34.10-2001 및 GOST R 34.10-2012를 포함하는 보다 현대적인 디지털 서명 알고리즘이 전문화되어 있습니다. 이는 문서 서명에만 사용되며 암호화에는 적합하지 않습니다. 기술적으로 특수 알고리즘 간의 차이점은 해당 경우의 해시가 암호화되지 않는다는 것입니다. 이를 암호화하는 대신 개인 키를 사용하여 다른 계산도 수행되며 그 결과는 서명으로 저장됩니다. 서명을 검증할 때 공개 키를 사용하여 해당 보완 계산이 수행됩니다. 이 경우 다양성의 상실은 더 높은 암호화 강도를 위해 지불해야 하는 대가입니다. 범용 알고리즘을 사용한 아래 예는 관련성이 다소 낮을 수 있지만 훈련받지 않은 독자에게는 확실히 더 이해하기 쉽습니다.

문서 서명

따라서 공개 키 인프라에서 전자 서명을 생성하려면 한 쌍의 키를 사용하는 것이 특징인 비대칭 암호화 방식이 사용됩니다. 이 키 중 하나로 암호화된 내용은 쌍의 다른 키로만 해독할 수 있습니다. 쌍의 키 중 하나는 비밀 또는 비공개라고 하며 가능한 한 비밀리에 저장되고, 다른 하나는 공개 또는 공개라고 하며 일반적으로 인증서의 일부로 자유롭게 배포됩니다. 키 외에도 전자 서명 인증서에는 인증서 소유자에 대한 정보는 물론 신뢰할 수 있는 당사자가 작성한 키 서명과 소유자에 대한 정보가 포함됩니다. 따라서 인증서에는 소유자 정보가 해당 키 쌍과 일치함을 확인하는 전자 서명이 이미 포함되어 있습니다.

조직적으로 이 서명은 소유자와 키의 준수 여부를 확인하고 확인하는 권한을 위임받은 법인인 인증 센터(CA)에 의해 수행됩니다. 준수 여부는 종이 문서 제시 후 확정되며, 전자 서명을 통해 정확하게 확인되므로 인증서 발급 예시를 활용하면 편리합니다.

인증 기관에는 클라이언트 인증서 서명을 위한 키 쌍도 있습니다. 특별히 설계된 테이블 형태의 인증서 소유자에 대한 확인된 정보는 공개 키를 통해 하나의 문서로 결합됩니다. 그런 다음 이 문서는 두 가지 변환을 거칩니다. 첫째, 해싱 함수는 문서를 고유한 고정 길이 문자 시퀀스(해시)로 변환합니다. 다음으로 결과 해시는 인증 기관의 개인 키로 암호화됩니다. 암호화의 결과는 실제 전자 서명입니다. 이는 서명된 문서(이 경우 사용자 및 해당 키에 대한 정보)에 첨부되어 함께 배포됩니다. 이 모든 것 - 사용자 및 공개 키에 대한 정보가 포함된 문서와 CA의 공개 키로 이 문서에 서명하는 문서는 특별한 방식으로 작성되며 사용자 인증서라고 합니다.

인증서에 포함된 사용자 데이터의 경우와 마찬가지로 다른 문서의 전자 서명이 발행됩니다. 예를 들어 일부 서비스를 받기 위한 애플리케이션이 포함된 파일입니다. 파일은 해시되고 결과 해시는 사용자의 비밀 키로 암호화되어 문서에 첨부됩니다. 결과는 서명된 문서입니다.

서명 확인

일반적으로 비대칭 암호화의 경우와 마찬가지로, 한 키로 암호화된 내용은 쌍의 다른 키로만 해독될 수 있습니다. 따라서 인증서의 경우 사용자의 공개 키와 사용자에 대한 확인된 정보가 포함된 문서의 암호화된 해시를 인증 기관 인증서의 일부로 무료로 배포되는 인증 기관의 공개 키를 사용하여 복호화할 수 있습니다. 따라서 CA 인증서를 받은 사람은 누구나 사용자 인증서에서 해독된 해시를 얻을 수 있습니다. 해싱 함수는 고유한 결과를 생성하므로 이를 사용자의 공개키와 그에 대한 정보가 포함된 문서에 적용하면 두 해시가 일치하는지 확인할 수 있습니다. 그렇다면 인증 센터에서 서명한 것과 동일한 문서가 우리 앞에 있으며 그 안에 포함된 정보는 신뢰할 수 있습니다. 그렇지 않다면 서명이 문서와 일치하지 않으며 가짜입니다.

CA 인증서를 확인하는 상황은 정확히 동일합니다. 또한 일종의 키로 서명됩니다. 결과적으로 서명된 인증서 체인은 자체적으로 서명된 "루트" 인증서로 끝납니다. 이러한 인증서를 자체 서명이라고 합니다. 러시아 연방의 공식 공인 인증 센터의 경우 루트 인증서는 통신 및 매스커뮤니케이션부의 수석 인증 센터 인증서입니다.

사용자 및 공개 키에 대한 정보 외에도 인증서에는 몇 가지 추가 데이터, 특히 인증서 유효 기간이 포함됩니다. 체인에 있는 하나 이상의 인증서가 만료된 경우 서명이 유효하지 않은 것으로 간주됩니다.

또한 인증 기관이 클라이언트 인증서를 취소하면 서명이 유효하지 않은 것으로 간주됩니다. 예를 들어, 개인 키가 유출된 상황에서 인증서를 취소하는 기능은 유용합니다. 은행 카드를 분실한 경우 은행에 연락하는 것과 유사합니다.

인증 센터 서비스

따라서 인증 기관은 서명을 통해 특정 공개 키와 특정 레코드 집합의 일치를 확인합니다. 이론적으로 하나의 인증서에 서명하기 위한 CA 비용은 0에 가깝습니다. 서명 자체는 현대 장비에서는 그다지 비싸지 않은 잘 자동화된 컴퓨팅 작업입니다. 동시에 CA 서비스가 지급됩니다. 그러나 웹 사이트에 대한 인증서를 발급하는 CA와 달리 여기서는 돈이 허공에서 만들어지지 않습니다.

인증서 비용의 첫 번째 구성 요소는 공인 CA 서비스에 드는 간접비입니다. 여기에는 CA 인증서 비용(지불), 인증 소프트웨어 라이선스 비용, 개인 데이터 보호를 위한 조직적 조치 보장 비용 등이 포함됩니다. 예를 들어 개인의 개인 인증서 비용이 결정되는 방법입니다. 이를 통해 로컬 파일, 정부 서비스 웹사이트의 문서 및 이메일 메시지에 서명할 수 있습니다.

인증서 비용의 두 번째 구성 요소는 사용자가 예를 들어 전자 거래 플랫폼에서 작업하기 위해 인증서를 사용하려고 할 때 나타납니다. 현행 규정에 따르면 전자 거래 플랫폼의 웹사이트는 두 가지 조건이 충족되면 고객을 인증합니다. 첫째, 인증서가 만료되지 않은 경우 인증서가 취소되지 않았으며 서명이 유효합니다. 둘째, 인증서에 특정 사이트에서 작동하도록 의도된 것이 명확하게 명시되어 있는 경우입니다. 이에 대한 항목은 나머지 인증서 데이터를 저장하는 동일한 테이블의 일반 항목처럼 보입니다. 각 사용자 인증서의 각 항목에 대해 인증 센터는 일정 금액을 제공합니다. 그는 인증서 소유자를 희생하여 보상하려고 합니다. 따라서 전자 거래 플랫폼에 진입할 수 있는 인증서는 더 비쌉니다.

위협과 공격

암호화와 달리 전자 서명의 경우 공격자의 주요 임무는 해독된 텍스트를 얻는 것이 아니라 임의의 문서를 위조하거나 전자적으로 서명하는 능력입니다. 즉, 상대적으로 말하면 복호화가 아니라 암호화입니다. 조건부 - 위에서 언급한 것처럼 최신 특수 디지털 서명 알고리즘은 문서의 해시를 암호화하지 않고 의미는 유사하지만 기술적으로 다른 수학적 연산을 수행하기 때문입니다.

러시아 연방에서 채택한 표준에 따라 문서에 전자 서명할 때 러시아 연방 국가 표준(GOST R)을 준수하는 암호화 알고리즘이 사용됩니다. 이 글을 쓰는 시점(2016년 하반기)에는 디지털 서명과 관련된 알고리즘이 없고 러시아 연방에서 표준 지위를 갖고 있는 알고리즘이 없기 때문에 단순한 무차별 공격과 복잡성이 크게 다른 공격 방법이 알려져 있습니다. 실제로 이는 대규모 상태보다 컴퓨팅 리소스에 대한 액세스 수준이 낮은 공격자의 경우 알고리즘을 해킹하고 서명을 위조하는 것보다 키를 훔치려는 것이 더 쉽다는 것을 의미합니다.

따라서 전자서명의 경우 공격자가 비밀키를 탈취하는 것을 주요 공격 벡터로 삼는다. 키가 디스크의 파일에 저장되어 있는 경우 적절한 읽기 액세스 권한을 얻으면 언제든지 도난당할 수 있습니다. 예를 들어, 바이러스를 사용합니다. 키가 암호화된 형식으로 저장되어 있는 경우 사용 시 얻을 수 있습니다. 예를 들어 전자 서명을 수행하는 프로그램이 이미 키를 해독하고 이를 사용하여 데이터를 처리하는 경우입니다. 이 경우 작업은 훨씬 더 복잡해집니다. 프로그램에서 취약점을 찾거나 키를 직접 해독해야 합니다. 작업이 상당히 복잡함에도 불구하고 여전히 현실적입니다. 해당 분야의 전문가라면 루틴(routine)의 범주에 속합니다.

키가 물리적 장치를 떠나지 않도록 별도의 하드웨어 장치에 비밀 키를 배치하면 공격자가 비밀 키를 획득하는 것을 더욱 어렵게 만들 수 있습니다. 이 경우 공격자는 물리적 장치를 훔쳐야만 키에 액세스할 수 있습니다. 장치가 분실되면 소유자에게 키가 도난당했다는 신호가 됩니다. 다른 경우에는(이것이 가장 중요한 뉘앙스입니다) 키 도난이 눈에 띄지 않을 수 있으며 키 소유자는 긴급하게 CA에 연락하여 인증서를 취소해야 한다는 사실을 제때 알지 못할 것입니다.

여기서도 은행 계좌에 접근하기 위한 인증 도구인 은행 카드에 비유하는 것이 적절합니다. 주인이 가지고 있는 한 그는 침착합니다. 카드를 분실한 경우 즉시 차단해야 합니다. 이 경우 공격자의 임무는 카드를 훔치는 것이 아니라 소유자가 액세스를 차단하지 않도록 조용히 복사본을 만드는 것입니다. 최신 하드웨어 토큰의 경우 복제 방법은 현재 알려져 있지 않습니다.

토큰

현재 전자 서명 키를 저장하는 데 사용되는 개별 물리적 장치를 지정하는 데 일반적으로 허용되는 용어는 토큰입니다. 토큰은 USB, Bluetooth 또는 특수 리더 장치를 통해 컴퓨터에 연결할 수 있습니다. 대부분의 최신 토큰은 USB 인터페이스를 사용합니다. 그러나 토큰 유형 간의 주요 차이점은 연결 인터페이스에 있지 않습니다. 토큰은 실제로 키 저장소로만 사용되는 유형과 자체 수단을 사용하여 암호화 작업을 수행하는 방법을 "알고 있는" 두 가지 유형으로 나눌 수 있습니다.

첫 번째 유형의 토큰은 기본적으로 특수 소프트웨어를 통해서만 데이터를 읽을 수 있다는 점에서만 일반 플래시 드라이브와 다릅니다. 그렇지 않은 경우 이것은 일반 외부 데이터 저장소이며 비밀 키를 여기에 저장하면 장치에 대한 액세스 권한이 있고 장치에서 키를 읽는 방법을 아는 사람은 누구나 그것을 훔칠 수 있습니다. 이러한 토큰을 소프트웨어라고 하며 컴퓨터 디스크에 키를 저장하는 것에 비해 사실상 이점이 없습니다. 키 소유자도 자신의 비밀 키가 저장된 모든 장소를 알고 있는지 확신할 수 없습니다.

두 번째 유형의 토큰은 하드웨어 토큰이라고 하며, 주요 차이점은 비밀 키는 검색할 수 없다는 것입니다. 즉, 토큰을 떠나지 않습니다. 이를 위해 토큰이 컴퓨터에 연결될 때 활성화되는 특수 소프트웨어 세트가 토큰에 배치됩니다. 기본적으로 이러한 토큰은 컴퓨터와 데이터를 교환하는 자체 프로세서, 메모리 및 응용 프로그램을 갖춘 독립적인 컴퓨팅 장치입니다.

비밀 키는 토큰 자체에서 직접 생성되므로 하드웨어 토큰을 떠나지 않습니다. 문서에 서명하기 위해 문서의 해시가 토큰에 로드되고, 거기에 저장된 비밀 키를 사용하여 토큰에 직접 계산이 이루어지며 완성된 서명이 다시 업로드됩니다. 따라서 토큰의 위치를 ​​알면 비밀 키의 위치도 항상 알 수 있습니다.

하드웨어 토큰의 주요 특징 중 하나는 지원되는 암호화 알고리즘 세트입니다. 예를 들어, 가정용 컴퓨터에서 인증을 위해 하드웨어 토큰을 사용하려는 경우 최신 토큰이면 충분합니다. 그리고 State Services 포털에서 인증하려면 러시아에서 인증된 암호화 알고리즘을 지원하는 토큰이 필요합니다.

다음은 eToken 및 JaCarta GOST 토큰에 지원되는 암호화 메커니즘 목록입니다. 메커니즘 목록을 요청하려면 개방형 유틸리티 pkcs11-tool을 "-M" 매개변수("mechanism"이라는 단어에서 유래)와 함께 사용합니다. 이 매개변수는 PKCS#11 인터페이스를 구현하는 모든 라이브러리에 대한 클라이언트 애플리케이션 역할을 할 수 있습니다. 방향. libeToken.so 및 libjcPKCS11.so.1은 각각 eToken 및 JaCarta용 PKCS#11 라이브러리로 사용되었습니다. eToken용 라이브러리는 SafeNet 소프트웨어의 일부로 배포되며 JaCarta용 라이브러리는 Aladdin R.D. 회사 웹사이트에서 다운로드할 수 있습니다.

$ pkcs11-tool --module /usr/local/lib64/libeToken.so.9.1.7 -M 지원되는 메커니즘: DES-MAC, keySize=(8,8), 서명, 확인 DES-MAC-GENERAL, keySize=( 8,8), 서명, 확인 DES3-MAC, keySize=(24,24), 서명, 확인 DES3-MAC-GENERAL, keySize=(24,24), 서명, 확인 AES-MAC, keySize=(16,32 ), 서명, 확인 AES-MAC-GENERAL, keySize=(16,32), 서명, RC4 확인, keySize=(8,2048), 암호화, 해독 DES-ECB, keySize=(8,8), 암호화, 해독 , 래핑, DES-CBC 언래핑, keySize=(8,8), 암호화, 해독, 래핑, DES-CBC-PAD 래핑 해제, keySize=(8,8), 암호화, 해독, 래핑, DES3-ECB, keySize= (24,24), hw, 암호화, 해독, 래핑, DES3-CBC, keySize=(24,24), hw, 암호화, 해독, 래핑, DES3-CBC-PAD, keySize=(24,24), hw, 암호화, 암호 해독, 랩핑, 랩핑 해제 AES-ECB, keySize=(16,32), 암호화, 암호 해독, 랩핑, 랩핑 해제 AES-CBC, keySize=(16,32), 암호화, 암호 해독, 랩핑, AES-CBC 랩핑 해제 -PAD, keySize=(16,32), 암호화, 해독, 래핑, mechtype-0x1086 래핑 해제, keySize=(16,32), 암호화, 해독, 래핑, mechtype-0x1088, keySize=(16,32), 암호화 , 암호 해독, 래핑, 래핑 해제 RSA-PKCS-KEY-PAIR-GEN, keySize=(1024,2048), hw, generate_key_pair RSA-PKCS, keySize=(1024,2048), hw, 암호화, 암호 해독, 서명, sign_recover, 확인 , verify_recover, 랩, 랩핑 해제 RSA-PKCS-OAEP, keySize=(1024,2048), hw, 암호화, 암호 해독, 랩, 랩핑 해제 RSA-PKCS-PSS, keySize=(1024,2048), hw, 서명, SHA1- 확인 RSA-PKCS-PSS, keySize=(1024,2048), hw, 서명, mechtype-0x43 확인, keySize=(1024,2048), hw, 서명, mechtype-0x44 확인, keySize=(1024,2048), hw, 서명, mechtype-0x45 확인, keySize=(1024,2048), hw, 서명, RSA-X-509 확인, keySize=(1024,2048), hw, 암호화, 해독, 서명, sign_recover, 확인, verify_recover, 래핑, MD5-RSA-PKCS, keySize=(1024,2048), hw, 서명, SHA1-RSA-PKCS 확인, keySize=(1024,2048), hw, 서명, SHA256-RSA-PKCS 확인, keySize=(1024, 2048), hw, 서명, SHA384-RSA-PKCS 확인, keySize=(1024,2048), hw, 서명, SHA512-RSA-PKCS 확인, keySize=(1024,2048), hw, 서명, RC4-KEY 확인- GEN, keySize=(8,2048), DES-KEY-GEN 생성, keySize=(8,8), DES2-KEY-GEN 생성, keySize=(16,16), DES3-KEY-GEN 생성, keySize=( 24,24), AES-KEY-GEN 생성, keySize=(16,32), PBE-SHA1-RC4-128 생성, keySize=(128,128), PBE-SHA1-RC4-40 생성, keySize=(40,40 ), PBE-SHA1-DES3-EDE-CBC, keySize=(24,24) 생성, PBE-SHA1-DES2-EDE-CBC, keySize=(16,16) 생성, GENERIC-SECRET-KEY-GEN, keySize 생성 =(8,2048), hw, PBA-SHA1-WITH-SHA1-HMAC 생성, keySize=(160,160), hw, PBE-MD5-DES-CBC 생성, keySize=(8,8), PKCS5-PBKD2 생성, MD5-HMAC-GENERAL 생성, keySize=(8,2048), 서명, MD5-HMAC 확인, keySize=(8,2048), 서명, SHA-1-HMAC-GENERAL 확인, keySize=(8,2048), 서명 , SHA-1-HMAC 확인, keySize=(8,2048), 서명, mechtype-0x252 확인, keySize=(8,2048), 서명, mechtype-0x251 확인, keySize=(8,2048), 서명, mechtype 확인 -0x262, keySize=(8,2048), 서명, mechtype 확인-0x261, keySize=(8,2048), 서명, mechtype 확인-0x272, keySize=(8,2048), 서명, mechtype 확인-0x271, keySize= (8,2048), 서명, MD5 확인, SHA-1 다이제스트, SHA256 다이제스트, SHA384 다이제스트, SHA512 다이제스트, mechtype-0x80006001 다이제스트, keySize=(24,24), $ pkcs11-tool --module /usr/local 생성 /lib64/libjcPKCS11.so. 1 -M 지원되는 메커니즘: GOSTR3410-KEY-PAIR-GEN, hw, generate_key_pair GOSTR3410, hw, 서명, GOSTR3410-WITH-GOSTR3411 확인, hw, 서명, mechtype-0x1204 확인, hw, GOSTR3411 파생, hw, mechtype-0x1220 다이제스트 , mechtype-0xC4321101 mechtype-0xC4321102 mechtype-0xC4321103 mechtype-0xC4321104 mechtype-0xC4900001을 생성합니다.

eToken에 대해 지원되는 메커니즘 목록은 매우 길지만 GOST 알고리즘은 포함되어 있지 않음을 알 수 있습니다. 지원되는 JaCarta 메커니즘 목록에는 GOST 알고리즘만 포함되어 있지만 하드웨어 토큰에 디지털 서명 기능을 구현하는 데 필요한 범위까지만 포함됩니다.

일반적으로 최신 하드웨어 토큰은 소프트웨어 토큰으로도 사용될 수 있다는 점을 이해하는 것이 중요합니다. 즉, 일반적으로 외부에서 액세스할 수 있는 작은 메모리 영역이 있으며, 원하는 경우 외부에서 생성된 비밀 키를 기록하고 저장하는 데 사용할 수 있습니다. 기술적으로 이것은 의미가 없지만 실제로 이 방법은 불행히도 꽤 널리 사용됩니다. 안타깝게도 토큰 소유자는 소액의 비용이 아닌 정직하게 구입한 최신 하드웨어 토큰이 소프트웨어 토큰으로 사용된다는 사실을 모르는 경우가 많습니다.

독점적인 소프트웨어 토큰의 예로는 "Rutoken S" 및 "Rutoken Lite"가 있습니다. 러시아에서 인증된 암호화 알고리즘을 지원하지 않는 하드웨어 토큰의 예로는 "eToken" 장치가 있습니다. 러시아 암호화 지원 - "Rutoken EDS", "JaCarta GOST".

암호화폐 제공업체

운영자에게 암호화 기능(전자 서명, 암호화, 복호화, 해싱)에 대한 액세스를 제공하는 소프트웨어를 암호화 공급자, 암호화 기능 공급자라고 합니다. 하드웨어 토큰의 경우 암호화 공급자는 토큰에 직접 구현되고, 소프트웨어 토큰의 경우 또는 컴퓨터 디스크에 키를 저장하는 경우 일반 사용자 애플리케이션의 형태로 구현됩니다.

사용자 데이터 보안의 관점에서 주요 공격 벡터 중 하나는 암호화 공급자를 대상으로 합니다. 즉, 비밀 키가 해독된 형식으로 포함되어 있는 것은 암호화 공급자의 메모리에 있습니다. 공격이 성공할 경우, 키가 일반적으로 암호화된 형태로 저장되어 있더라도 공격자는 애플리케이션 코드를 자신의 코드로 교체하고 비밀 키의 복사본을 만들 수 있습니다. 따라서 법적 효력이 있는 전자서명을 위해 암호화를 사용하는 경우, 국가는 비밀키가 유출될 가능성으로부터 국민을 보호하고자 한다. 이는 적격 전자 서명을 사용하려면 적절한 인증서를 갖고 적절한 검사를 통과한 암호화폐 제공자만 공식적으로 사용할 수 있다는 사실로 표현됩니다.

EDS에 대해 러시아 연방 영토에서 인증된 암호화 공급자에는 특히 "Rutoken EDS", "JaCarta GOST", "CryptoPro CSP", "LISSI-CSP", "VipNet CSP"가 포함됩니다. 처음 두 개는 하드웨어 토큰에 직접 구현되고 나머지는 사용자 애플리케이션 형태로 구현됩니다. 러시아 연방에서 인증된 하드웨어 토큰을 구매할 때 우리는 이미 러시아 연방에서 인증된 암호화폐 공급자를 획득하고 있으며 기술적으로나 법적으로 다른 암호화폐 공급자를 구매할 필요가 없다는 점을 이해하는 것이 중요합니다.

지원되는 알고리즘 세트 외에도 암호화 공급자는 문서 암호화 및 암호 해독, 서명 서명 및 확인, 그래픽 사용자 인터페이스 존재 등 암호화 기능 세트도 다릅니다. 또한 인증된 암호화 제공자는 이 전체 기능 세트 중에서 암호화 알고리즘 구현과 직접적으로 관련된 기능만 수행해야 합니다. 다른 모든 작업은 타사 응용 프로그램을 통해 수행할 수 있습니다. 이것이 바로 암호화 공급자가 하드웨어 토큰에서 작동하는 방식입니다. 사용자 인터페이스는 필수 인증이 적용되지 않는 타사 애플리케이션에 의해 구현됩니다. 사용자 인터페이스를 구현하는 애플리케이션은 다른 표준 인터페이스인 PKCS#11을 통해 토큰의 암호화 공급자와 통신합니다. 동시에 사용자의 관점에서 키 작업은 예를 들어 Firefox html 브라우저에서 직접 발생합니다. 실제로 브라우저는 PKCS#11 인터페이스를 통해 특정 하드웨어 토큰에 액세스하기 위한 메커니즘을 구현하는 특수 소프트웨어 계층을 사용합니다.

"암호화 제공자"라는 용어 외에도 "암호화 정보 보호 도구"(CIPF)라는 의미와 유사한 또 다른 용어가 있습니다. 이 두 개념 사이에는 명확한 차이가 없습니다. 첫 번째 용어는 덜 공식적인 용어이고, 두 번째 용어는 인증된 기술 솔루션과 관련하여 더 자주 사용됩니다. 이 문서는 공식적인 측면보다는 기술적인 측면을 주로 설명하므로 "암호화폐 공급자"라는 용어를 자주 사용합니다.

메커니즘 구현

전자 서명 알고리즘

현재 러시아 연방에서는 적격 전자 서명에 공식적으로 두 개의 서명 알고리즘과 두 개의 해싱 알고리즘만 허용됩니다. 2017년 말까지 해싱 알고리즘 GOST R 34.11-94와 함께 GOST R 34.10-2001을 사용할 수 있습니다. 2018년 초부터 GOST R 34.10-2012 및 GOST R 34.11-2012에 따른 해시만 사용할 수 있습니다. GOST 알고리즘의 필수 사용이 필요하지 않은 상황에서는 사용 가능한 알고리즘을 사용할 수 있습니다.

예를 들어, 현재 HTTP 프로토콜을 통해 액세스할 수 있는 대부분의 웹사이트는 클라이언트와 서버의 상호 인증을 위해 GOST 알고리즘을 사용하는 방법을 모릅니다. 이러한 사이트 중 하나와 상호 작용하는 경우 클라이언트 측도 "외국산" 알고리즘을 적용해야 합니다. 그러나 예를 들어 하드웨어 토큰을 국가 서비스 웹사이트 인증용 키 저장소로 사용하려면 GOST에 따라 디지털 서명을 지원하는 토큰을 선택해야 합니다.

정부 기관과 상호 작용할 때 러시아 알고리즘을 사용해야 하는 이유는 시민의 선택을 제한하려는 욕구 때문이 전혀 아닙니다. 그 이유는 이러한 알고리즘의 개발에 투자한 국가가 암호화 강도와 선언되지 않은 기능의 부재에 대한 책임이 있기 때문입니다. 러시아 연방에서 표준화된 모든 암호화 알고리즘은 반복적으로 독립적인 감사를 거쳐 그 유효성이 확실하게 입증되었습니다. 다른 많은 일반적인 암호화 알고리즘에 대해서도 마찬가지입니다. 그러나 안타깝게도 선언되지 않은 기능이 없다는 사실을 쉽게 증명할 수는 없습니다. 국가의 관점에서 볼 때, 예를 들어 시민의 개인 데이터를 처리하기 위해 신뢰할 수 없는 수단을 사용하는 것은 불합리하다는 것은 매우 분명합니다.

인터페이스, 형식 및 프로토콜

전자 서명 작업 시 호환성을 보장하기 위해 데이터 저장 및 액세스와 관련된 다양한 국제 표준이 개발되었습니다. 주요 표준은 다음과 같습니다.

  • PC/SC - 소프트웨어 및 하드웨어 토큰을 포함한 암호화 장치에 액세스하기 위한 하위 수준 인터페이스입니다.
  • PKCS#11 - 하드웨어 암호화 모듈과의 상호 작용을 위한 상위 수준 인터페이스는 암호화 공급자에 대한 통합 액세스 인터페이스로 간주될 수 있습니다.
  • PKCS#15 - 전자 서명 키가 포함된 컨테이너 형식으로, 물리적 장치에 저장하기 위한 것입니다.
  • PKCS#12, PEM - 각각 파일, 바이너리 및 텍스트로 저장하기 위한 전자 서명 키가 있는 컨테이너 형식입니다.
  • PKCS#10은 서명된 인증서를 받기 위해 클라이언트가 CA에 보낸 서명 요청인 문서의 형식입니다.

PKCS#11 또는 PKCS#15와 같은 표준은 처음에는 러시아 연방에서 인증된 암호화폐의 세부 사항을 고려하지 않고 개발되었다는 점을 이해하는 것이 중요합니다. 따라서 국내 암호화폐에 대한 완전한 지원을 구현하기 위해서는 표준을 수정해야 했고, 여전히 수정해야 합니다. 표준 개정안을 채택하는 과정은 길기 때문에 개정된 표준이 최종적으로 채택될 때까지 구현이 서로 호환되지 않는 것으로 나타났습니다. 이는 러시아 연방에서 인증된 암호화폐 제공업체에도 적용됩니다. 따라서 이제 모든 인증된 암호화폐 제공업체는 토큰에 키를 저장하기 위한 컨테이너 구현이 호환되지 않습니다. 데이터 교환 표준(PKCS#10, PKCS#12, PEM)의 경우 다행스럽게도 해당 구현은 일반적으로 서로 호환됩니다. 또한 일반적으로 PC/SC 표준 해석에는 불일치가 없습니다.

러시아 연방 디지털 서명 분야의 표준 확정, 권장 사항 개발 및 호환성 보장 문제는 현재 전문가가 포함된 "암호 정보 보안"표준화 기술 위원회(TK 26)라는 특수 조직에서 처리되고 있습니다. 정부 기관 대표, 암호화폐 제공업체 개발자 및 기타 관심 있는 사람들. 위원회 업무의 효율성에 대해 논쟁할 수 있지만 그러한 플랫폼이 존재한다는 사실조차 매우 중요합니다.

소프트웨어 부분

전자 서명 작업을 위한 소프트웨어 스택은 다음 구성 요소로 구성됩니다.

  • 키를 사용하여 컨테이너 스토리지에 대한 하위 수준 액세스를 위한 인터페이스 구현(예: 물리적 장치에 액세스하기 위한 PC/SC 인터페이스) 토큰
  • 암호화 공급자와의 상호 작용을 위해 PKCS#11 인터페이스를 구현하는 모듈(예: 하드웨어 토큰에 구현됨)
  • 해당 암호화 알고리즘을 구현하고 해당 알고리즘을 사용하여 작업(예: 전자 서명 또는 데이터 암호화)을 수행하는 암호화 공급자
  • PKCS#11 모듈을 사용하여 상대방(암호화 공급자와 관련하여)과 상호 작용하고 사용자를 대신하여 전자 서명 또는 인증과 같은 작업을 수행하는 사용자 애플리케이션입니다.

스택 예:

  • CryptoPro CSP 소프트웨어의 cryptcp 명령줄 애플리케이션은 PKCS#11 인터페이스를 통해 libcppksc11.so 라이브러리와 상호 작용하고 사용자의 비밀 키로 문서에 서명하는 기능을 제공합니다. 이 경우 암호화 공급자의 기능은 CryptoPro CSP 소프트웨어의 구성 요소에서 완전히 구현되며 하드웨어 토큰의 암호화 공급자는 관련되지 않습니다.

다른 예시:

  • 오픈 소스 소프트웨어인 PCSC-lite는 하드웨어 토큰 "Rutoken EDS"와의 상호 작용을 위해 PC/SC 인터페이스를 구현합니다.
  • CryptoPro CSP 소프트웨어의 libcppksc11.so 라이브러리는 개인 키와 사용자 인증서를 저장하는 토큰에 있는 컨테이너와의 상호 작용을 제공합니다.
  • Firefox HTML 브라우저의 일부로 작동하는 CryptoPro EDS 브라우저 플러그인 애플리케이션은 PKCS#11 인터페이스를 통해 libcppksc11.so 라이브러리와 상호 작용하고 전자 거래 플랫폼 사이트의 브라우저 인터페이스에서 문서에 서명하는 기능을 제공합니다. 이 경우 암호화 공급자의 기능은 CryptoPro CSP 소프트웨어의 구성 요소에서 완전히 구현되며 하드웨어 토큰의 암호화 공급자는 관련되지 않습니다.

세 번째 예:

  • 오픈 소스 소프트웨어인 PCSC-lite는 하드웨어 토큰 "Rutoken EDS"와의 상호 작용을 위해 PC/SC 인터페이스를 구현합니다.
  • Aktiv 회사에서 제작한 librtpksc11.so 라이브러리는 토큰 암호화 공급자와의 상호 작용을 보장합니다.
  • 토큰의 암호화 공급자는 전송된 데이터에 비밀 키를 사용하여 서명하는 기능을 수행합니다. 비밀 키는 토큰을 떠나지 않습니다.
  • Firefox html 브라우저의 일부로 실행되는 Rutoken 플러그인 애플리케이션은 PKCS#11 인터페이스를 통해 librtpksc11.so 라이브러리와 상호 작용하고 호환 사이트의 브라우저 인터페이스에서 문서에 서명하는 기능을 제공합니다. 또한 암호화폐 공급자의 기능은 하드웨어 토큰에서 완전히 구현됩니다.

현재 스택의 특정 구현 선택은 우선 디지털 서명의 의도된 적용 범위, 사용자의 기술 지식 수준 및 인증 기관의 작업 의지 등 세 가지 요소에 의해 결정됩니다. 인증서 서명 요청으로.

사용자 측에서 실행되는 위에 나열된 소프트웨어 세트 외에도 고려해야 할 기능을 가진 두 가지 응용 프로그램이 더 있습니다. 첫 번째는 인증 센터를 지원하는 소프트웨어입니다. 두 번째는 우리가 호환되기를 원하는 소프트웨어입니다. 예를 들어 주정부 서비스 웹 사이트가 있습니다. 또는 전자 문서에 서명하기 위한 소프트웨어.

인증서를 얻으려는 인증 기관이 PKCS#10 형식의 서명 요청을 처리할 준비가 되어 있지 않고 소프트웨어 토큰으로만 작업할 수 있는 경우(즉, 모든 토큰을 소프트웨어로 인식하는 경우) 선택의 여지가 없습니다. 일반적으로 이 경우 CA 소프트웨어는 우리를 위해 키 쌍을 생성하고 이를 토큰에 기록하며 공개 키와 개인 데이터를 기반으로 즉시 서명 요청을 생성하고 서명한 다음 인증서를 토큰. 인증서와 키는 CA 소프트웨어 개발자에게만 알려진 폐쇄형 형식의 컨테이너에 들어 있습니다. 따라서 키를 사용하여 컨테이너에 액세스하려면 동일한 개발자로부터 암호화폐 공급자를 구입해야 합니다. 그리고 디지털 서명의 적용 범위는 특정 개발자의 소프트웨어 기능에 따라 제한됩니다. 이 경우 하드웨어 토큰을 구매할 필요가 없습니다. 소프트웨어 토큰을 사용하면 됩니다. 이 경우 토큰을 CA로 가져와야 합니다.

인증서를 얻으려는 인증 기관이 PKCS#10 형식의 서명 요청을 처리할 준비가 되어 있으면 이 CA에서 어떤 종류의 소프트웨어가 사용되는지는 중요하지 않습니다. 우리는 대상 애플리케이션과 호환되는 암호화 공급자를 사용할 수 있습니다. 예를 들어 전자 거래 플랫폼이나 주정부 서비스 웹사이트가 있습니다. 이 경우 토큰을 CA에 가져올 필요가 없으며 서명 요청을 생성하여 종이 문서와 함께 제시하는 것으로 충분합니다. 인증서를 받고 선택한 암호화 공급자를 사용하여 토큰에 독립적으로 저장합니다.

안타깝게도 현재(2016년 말) 서명 요청을 처리할 준비가 되어 있는 CA는 거의 없습니다. 이러한 상황은 부분적으로 서명 요청이 적절하게 완료되었는지(필요한 모든 속성과 해당 값을 표시) 확인할 수 없는 사용자의 기술 교육 수준이 부족하기 때문입니다. 이 가이드는 무엇보다도 이 문제를 해결하는 것을 목표로 합니다.

하드웨어

러시아 시장에 제시된 토큰 중 다음 사항을 확인할 수 있습니다.

러시아어 암호화를 지원하는 하드웨어 미디어: Rutoken EDS, JaСarta GOST, MS_KEY K.

예를 들어 하드웨어 Rutoken EDS 및 소프트웨어 Rutoken_Lite의 지원되는 암호화 메커니즘 목록을 고려해 보겠습니다.

$ pkcs11-tool --module /usr/local/lib64/librtpkcs11ecp.so -M 지원되는 메커니즘: RSA-PKCS-KEY-PAIR-GEN, keySize=(512,2048), hw, generate_key_pair RSA-PKCS, keySize=( 512,2048), hw, 암호화, 해독, 서명, RSA-PKCS-OAEP 확인, keySize=(512,2048), hw, 암호화, MD5 해독, SHA-1 다이제스트, GOSTR3410-KEY-PAIR-GEN 다이제스트, hw , generate_key_pair GOSTR3410, hw, 서명, mechtype-0x1204 확인, hw, GOSTR3411 파생, hw, 다이제스트 GOSTR3410-WITH-GOSTR3411, hw, 다이제스트, 서명 mechtype-0x1224, hw, 랩, mechtype-0x1221 래핑 해제, hw, 암호화, 해독 mechtype-0x1222, hw, 암호화, mechtype-0x1220 해독, hw, mechtype-0x1223 생성, hw, 서명, 확인 $ pkcs11-tool --module /usr/local/lib64/librtpkcs11ecp.so -M 지원되는 메커니즘:

보시다시피, 지원되는 암호화 메커니즘 Rutoken Lite의 목록은 GOST 및 RSA 알고리즘을 포함하는 Rutoken EDS와 달리 비어 있습니다.

위에서 언급한 대로 러시아 암호화를 지원하지 않는 하드웨어 토큰에는 특히 JaCarta PKI 및 eToken이 포함됩니다.

러시아 암호화를 지원하는 하드웨어 토큰의 상대적으로 저렴한 가격을 고려하면 우리는 자신있게 이를 사용하는 것을 권장할 수 있습니다. 검색할 수 없는 비밀 키의 명백한 이점 외에도 하드웨어 토큰에는 인증된 암호화 공급자도 포함됩니다. 즉, 값비싼 소프트웨어를 추가로 구매할 필요가 없는 방식으로 토큰을 사용하여 작업을 구성하는 것이 가능합니다.

최근 개발 중에서 GOST R 34.10-2012 표준을 지원하는 Rutoken EDS 2.0을 언급하고 싶습니다.

애플리케이션

사용자 도구

도구 열기

현재 오픈 소스 소프트웨어를 사용하면 디지털 서명 작업을 위한 거의 완전한 소프트웨어 스택을 구현할 수 있습니다.

PCSC 라이트

PCSC 라이트 프로젝트 내에서 개발된 PC/SC 구현은 Linux OS 제품군에 대한 참조입니다. 이는 디지털 서명 작업을 위해 이 문서에 설명된 모든 소프트웨어 스택 옵션에 포함되어 있습니다. 향후에는 특정 구현 옵션을 지정하지 않으면 기본적으로 활성화된 것으로 간주합니다.

오픈SC

PKCS#11 인터페이스를 구현하는 라이브러리와 해당 기능을 사용하는 응용 프로그램 도구 세트는 OpenSC 프로젝트의 일부로 개발되었습니다. 이 툴킷은 Rutoken 제품군의 토큰을 개발하는 Aktiv 회사의 전문가가 추가한 지원인 Rutoken EDS를 포함하여 많은 하드웨어 토큰을 지원합니다.

OpenSC 유틸리티를 사용하면 특히 하드웨어 토큰에 대해 다음 작업을 수행할 수 있습니다.

  • 토큰 초기화 - 설정을 원래 상태로 재설정합니다.
  • 관리자 및 사용자 PIN 코드 설정(지원되는 경우)
  • 키 쌍을 생성합니다(PKCS#11 라이브러리에서 지원하는 경우).
  • 인증 기관에서 서명한 인증서를 토큰으로 가져옵니다.

OpenSC 키트의 PKCS#11 라이브러리를 사용하면 지원되는 토큰에 대해 모든 범위의 전자 서명 작업을 수행할 수 있습니다. 지원되는 토큰에는 Rutoken EDS도 포함됩니다.

여기서 Rutoken EDS에는 토큰에 키를 저장하는 형식 측면에서 서로 호환되지 않는 두 가지 소프트웨어 지원 옵션이 있다는 점을 이해하는 것이 중요합니다. OpenSC의 PKCS#11 라이브러리를 사용할 때는 개방형 소프트웨어 스택을 사용할 수 있고, Aktiv사에서 제작한 무료 배포 폐쇄형 라이브러리를 사용할 때는 폐쇄형 Aktiv 스택을 사용할 수 있습니다.

OpenSSL

디지털 서명의 기능을 완전히 사용하려면 PKCS#11 라이브러리 자체 외에도 운영자에게 라이브러리 기능 및 토큰 기능에 대한 액세스를 제공하는 사용자 애플리케이션을 구현해야 합니다. 이러한 구현의 놀라운 예는 OpenSSL 프로젝트의 오픈 소스 소프트웨어입니다. 특히 다음 기능을 지원합니다.

  • 데이터 암호화;
  • 데이터 암호 해독;
  • 문서 서명;
  • 서명 확인;
  • 인증서 서명 요청을 생성하는 단계;
  • 수입증명서;
  • 인증서 내보내기.

또한 OpenSSL을 사용하면 다음을 포함하여 본격적인 인증 기관의 기능을 구현할 수 있습니다.

  • PKCS#10 형식의 서명 요청에 서명하여 클라이언트 인증서를 발급합니다.
  • 클라이언트 인증서 해지;
  • 발급 및 취소된 인증서를 계산합니다.

오픈 소스 소프트웨어를 기반으로 하는 디지털 서명 소프트웨어 스택의 완전한 기능 버전 구현을 아직 허용하지 않는 OpenSSL의 유일한 현재 결함은 GOST 알고리즘을 지원하는 PKCS#11 라이브러리와 상호 작용하기 위한 개방형 모듈이 없다는 것입니다. Aktiv 회사에서 만든 이러한 모듈의 폐쇄형 구현이 있지만 기본 OpenSSL 배포판에는 포함되어 있지 않으므로 새 버전의 OpenSSL이 출시되면 호환성이 주기적으로 중단됩니다. 이 모듈의 공개 구현은 아직 GOST 알고리즘을 지원하지 않습니다.

파이어폭스

OpenSSL 외에도 잘 알려진 HTML 브라우저 Firefox도 PKCS#11 라이브러리와 상호 작용할 수 있습니다. PKCS#11 라이브러리를 연결하려면 "기본 설정" 설정 관리 메뉴로 이동한 후 왼쪽 세로 목록에서 "고급"을 선택하고 가로 목록에서 "인증서"를 선택한 후 "보안 장치" 버튼을 클릭해야 합니다. 을 클릭하고 나타나는 대화 상자에서 "로드" 버튼을 클릭합니다. PKCS#11 라이브러리가 있는 파일의 경로를 선택하는 옵션과 해당 특정 라이브러리에 대한 로컬 이름을 입력하는 옵션이 있는 또 다른 창이 나타납니다. 다양한 유형의 물리적 장치와 가상 장치에 대해 이러한 방식으로 여러 가지 PKCS#11 모듈을 로드할 수 있습니다.

불행하게도 Firefox 기능은 웹사이트 인터페이스에서 문서에 서명하는 데 아직 충분하지 않습니다. 따라서 GOST를 지원하는 본격적인 개방형 전자 디지털 서명 소프트웨어 스택의 경우 사이트 소프트웨어에서 토큰의 개체에 액세스할 수 있는 플러그인 모듈(플러그인)이 여전히 누락되어 있습니다. 우리는 그러한 플러그인이 가까운 장래에 작성되기를 바랍니다. 아니면 열어보세요.

크립토프로

CryptoPro CSP 버전 4.0 이하에서는 로컬 캐시의 수동 관리를 사용하여 사용자 인증서와 CA 인증서를 저장합니다. 사용자 인증서를 완벽하게 사용하려면 해당 복사본이 하나의 로컬 캐시에 있어야 하고 루트 인증서를 포함하는 전체 CA 인증서 체인이 다른 캐시에 있어야 합니다. 엄밀히 말하면 CryptoPro의 이 기능은 기술적으로 완전히 정당하지 않습니다. 인증 중에 체인을 확인하는 것이 합리적입니다. 인증서의 실제 유효성은 서명 기능에 영향을 미치지 않습니다. 더욱이 그것이 우리 자신의 인증서이고 그것이 어디서 왔는지 알고 있다면. 개발자에 따르면, 작성 당시 CryptoPro CSP의 최신 베타 버전에서는 CA 인증서 체인의 자동 로딩이 구현되었습니다. 그러나 사용자 인증서의 로컬 캐시에 현재 사용 중인 인증서만 포함되도록 하려면 여전히 수동으로 수행해야 하는 것 같습니다.

타사 개발자는 일상적인 사용자 작업을 더 쉽게 만드는 CryptoPro CSP용 그래픽 인터페이스를 작성하려고 시도하고 있습니다. 이러한 유틸리티의 예로는 문서 서명 및 암호화를 자동화하는 rosa-crypto-tool이 있습니다. ALT 배포판의 패키지.

크립토프로 CA

Lissy SOFT 소프트웨어는 표준 및 기술 사양을 엄격하게 준수하는 것이 특징입니다. 고유한 공급자를 포함한 암호화 공급자는 PKCS#11 라이브러리로 설계되었습니다. 개발자에 따르면 오픈 소스 소프트웨어와 잘 어울리며 표준 지원에도 중점을 둡니다. 예를 들어 OpenSSL 키트의 html 브라우저 및 유틸리티를 사용합니다.

정부 서비스 웹 사이트에 대한 액세스 구성과 관련하여 Lissy SOFT 제품도 관심을 끌고 있습니다. 우선, State Services 포털에서 디지털 서명 메커니즘을 구현하는 브라우저 플러그인인 "IFCPlugin"과의 호환성입니다. 둘째, PKCS#10 형식의 인증서 서명 요청을 처리하는 인증 기관 소프트웨어의 기능입니다.

브라우저

때때로 전자 서명 메커니즘을 사용하려는 사이트에 액세스하려면 러시아 암호화를 사용하는 다른 기술을 사용해야 합니다. 예를 들어, GOST 알고리즘을 사용하여 암호화된 데이터 전송 채널을 구성할 수 있습니다. 이 경우 브라우저에서 해당 알고리즘을 지원해야 합니다. 불행히도 Firefox 및 Chromium의 공식 빌드는 아직 러시아어 암호화를 완전히 지원하지 않습니다. 따라서 대체 어셈블리를 사용해야 합니다. 예를 들어 이러한 어셈블리는 Alt 배포판뿐만 아니라 CryptoPro 및 Lissy SOFT 회사의 암호화 도구 무기고에도 있습니다.

웹사이트

작업을 위해 전자 서명 기술을 사용해야 하는 사이트 중에서 우리는 주로 정부 서비스를 제공하는 사이트와 전자 거래 플랫폼(ETP)에 관심이 있습니다. 안타깝게도 일부 ETP는 아직 국내 소프트웨어 등록부의 OS 작업을 지원하지 않습니다. 그러나 상황은 점차 좋은 방향으로 변화하고 있습니다.

웹사이트에 대한 디지털 서명의 사용은 일반적으로 사이트 인터페이스에서 생성된 문서의 인증 및 서명으로 귀결됩니다. 기본적으로 인증은 다른 문서에 서명하는 것과 동일해 보입니다. 클라이언트가 인증하려는 사이트는 클라이언트에 보내는 일련의 문자를 생성합니다. 클라이언트는 자신의 비밀 키와 인증서(인증서는 조금 더 빠릅니다)를 사용하여 만들어진 이 시퀀스의 서명을 다시 보냅니다. 사이트는 클라이언트 인증서에서 공개 키를 가져와 원본 시퀀스의 서명을 확인합니다. 문서에 서명할 때도 마찬가지입니다. 여기서는 임의의 순서 대신 문서 자체가 나타납니다.

공공 서비스

연구 결과, 2016년 12월 14일 현재 대부분의 연방 거래 플랫폼인 "", "RTS-tender" 및 "Sberbank-AST"가 Linux 운영 체제를 실행하는 작업장에서 사용할 준비가 되어 있는 것으로 나타났습니다. 나머지 두 사이트는 아직 클라이언트 인증서를 사용하여 로그인하는 기능도 제공하지 않습니다. 안타깝게도 개발자가 호환성을 보장하기 위한 조치를 계획하고 있는지 여부는 아직 확인할 수 없습니다.

동시에 "통합 전자 거래 플랫폼"을 제외한 모든 플랫폼의 공식 지침에는 Windows 운영 체제가 유일하게 지원되는 것으로 표시되어 있습니다. 기술 지원 서비스의 공식 응답은 이 정보를 확인합니다. 통합 전자 거래 플랫폼(Unified Electronic Trading Platform) 웹사이트의 지침에는 특정 운영 체제를 지정하지 않고 브라우저를 설정하는 방법이 설명되어 있습니다.

연구 결과는 표에 요약되어 있습니다.

전자시장 사용자 인증서를 사용하여 로그인하는 기능 사이트 인터페이스에서 문서에 서명하는 기능 레지스트리의 OS 플랫폼 작업에 대한 문서
Sberbank - 자동 거래 시스템 예 예 아니요
통합 전자거래 플랫폼 예 예 예

Linux와의 호환성을 제공하는 ETP의 경우 현재 지원되는 유일한 암호화 도구는 CryptoPro CSP를 암호화 공급자로만 사용할 수 있는 Cades 플러그인입니다. 따라서 좋은 소식은 전자 거래 플랫폼에 액세스하기 위한 토큰을 얻는 것이 매우 간단하다는 것입니다. 대부분의 CA가 이를 발행합니다. 나쁜 소식은 토큰이 소프트웨어이며 주정부 서비스 웹사이트와 호환되지 않는다는 것입니다.

다른 거래 플랫폼의 경우 지금까지 디지털 서명 기능에 액세스하는 유일한 방법은 CAPICOM이라는 Windows OS 구성 요소입니다. Etersoft 회사의 전문가들이 연구 작업을 수행한 결과 Wine 환경에서 CAPICOM을 시작할 수 있는 이론적 가능성이 명확해졌습니다.

다른 사이트

디지털 서명을 사용하여 사이트에 직접 들어가 사이트 인터페이스에서 생성된 문서에 서명하는 나열된 사이트 외에도 이전에 적격 전자 서명으로 서명된 문서를 다운로드할 수 있는 기능을 제공하는 사이트가 많이 있습니다. 주요 무선 주파수 센터(Main Radio Frequency Center)의 웹사이트가 그 예입니다. 사이트에 대한 액세스는 로그인 및 비밀번호를 사용하여 수행되며 사용자 OS 인터페이스에서 미리 문서를 준비하고 서명합니다. 따라서 이러한 사이트에서 작업하려면 로컬 문서 서명 기능만 필요합니다. 즉, 이 경우 암호화폐 공급자 선택에 사실상 제한이 없습니다.

기성 솔루션의 예

안타깝게도 현재 이 문서의 작성자는 주정부 서비스 웹사이트와 전자 거래 플랫폼에서 동일한 토큰을 동시에 사용하는 방법을 모릅니다. 따라서 각각 2개의 키 쌍과 2개의 인증서로 구성된 2개의 토큰을 만들어야 합니다. 이는 법으로 금지된 것은 아니지만 기술적으로는 가능합니다. 재정적으로도 매우 현실적입니다. 예를 들어 하나의 토큰은 하드웨어 Rutoken EDS이고 다른 하나는 소액의 수수료로 찾을 수 있는 오래된 eToken 모델이 될 것입니다.

주정부 서비스 웹사이트 접속

정부 서비스에 액세스하려면 Rutoken EDS를 사용하고 다음 단계를 수행하십시오.

  1. 링크를 통해 페이지에서 "Rutoken Plugin" 소프트웨어를 다운로드하십시오.
  2. Rutoken 플러그인 설치 - 플러그인 파일(npCryptoPlugin.so 및 librtpkcs11ecp.so)을 ~/.mozilla/plugins/에 복사합니다.
  3. "등록 센터" 소프트웨어가 있는 사이트로 이동하여 지침에 따라 지침을 따르십시오. 토큰을 초기화하고, 키 쌍을 생성하고, PKCS#10 형식의 서명 요청이 포함된 파일을 로컬에 생성 및 저장합니다.
  4. 서명 요청 시 인증서를 발급할 준비가 되어 있는 CA에 문의하면 파일 형식으로 인증서를 받게 됩니다.
  5. "등록 센터" 인터페이스에서 받은 파일의 인증서를 토큰에 저장합니다.
  6. 링크를 클릭하면 "deb" 형식의 패키지(IFCPlugin-x86_64.deb 파일)를 다운로드할 수 있습니다.
  7. "Midnight Commander" 소프트웨어(mc 명령)를 사용하여 패키지 파일을 디렉터리로 "이동"합니다.
  8. 디렉토리의 내용을 복사 목차/usr/lib/mozilla/플러그인로컬 디렉토리 ~/.mozilla/plugins ;
  9. State Services 웹사이트의 Firefox 브라우저에서 "로그인" 및 "전자 수단을 사용하여 로그인" 링크를 따라갑니다.

이 지침을 구현할 때의 주요 문제는 서명 요청을 처리할 인증 기관을 찾는 것입니다.

전자 거래 플랫폼에 대한 액세스

Linux 작업을 지원하는 전자 거래 플랫폼 사이트에 액세스하려면 다음 단계를 따르세요.

  1. 러시아 연방에서 공식적으로 판매되는 토큰에 대해 당사는 CryptoPro CA를 사용하는 인증 센터에 연락하고 CryptoPro 소프트웨어에서 지원하는 형식의 컨테이너에 토큰에 저장된 사용자 인증서와 비밀 키를 받게 됩니다.
  2. 지침에 따라 Chromium 브라우저용 소프트웨어 "CryptoPro CSP" 및 "Cades 플러그인"을 설치합니다.
  3. Chromium 브라우저를 사용하여 전자 거래 플랫폼의 웹사이트로 이동하여 공식 지침에 따라 작업을 시작합니다.

파일 형식의 문서에 서명하는 기능은 CryptoPro 콘솔 유틸리티와 이미 언급한 rosa-crypto-tool과 같은 타사 래퍼 애플리케이션을 통해 사용할 수 있습니다.

인증 기관 CAFL63을 기반으로 작성되었습니다. 데이터(쿼리, 인증서, 설정 등)를 저장하기 위해 SQLite3 DBMS가 사용됩니다. 인증 기관은 Tcl/Tk로 개발된 그래픽 인터페이스를 가지고 있습니다.

CAFL63 CA는 2011년 4월 6일 연방법의 요구 사항을 고려하여 개발되었습니다. 63-FZ "전자 서명" 및 "전자 서명 확인 키의 적격 인증서 형식에 대한 요구 사항"은 2011년 12월 27일자 러시아 FSB 명령 No. 795에 의해 승인되었습니다.

CA에는 시민의 인증서 신청을 수락하는 등록 센터(CR)가 포함되어 있습니다. 오늘날 법인, 개인 및 개인 기업가를 위해 인증서가 발급됩니다. 신청서는 PKCS#10, CSR(인증서 서명 요청) 또는 SPKAC 형식으로 전자적으로 접수됩니다. CSR 형식은 -----BEGIN REQUEST CERTIFICATE----- 헤더가 있는 PEM 인코딩 PKCS#10 요청입니다.

요청은 완성된 양식으로, 인증서가 필요한 목적, 사용자의 공개 키, 사용자의 개인 키로 보증(서명)됩니다. 다음으로, 특히 신청자의 신원을 증명하는 문서 패키지와 요청이 저장된 전자 매체(요청, 개인 키는 다른 장소에 저장하는 것이 더 낫다는 것을 강조합니다)를 사용하여 시민이 옵니다. CR CA에.

CR은 서류와 요청사항(입력된 데이터, 전자서명의 정확성 등)을 확인하고, 이상이 없으면 요청을 수락하고 승인한 후 인증센터(CA)로 이관합니다.

신청자가 기성 요청없이 오면 그와 CR 직원은 인증서 요청이 준비되는 별도의 직장으로 이동합니다. 이미 언급한 바와 같이 전자 매체에 준비된 요청이 CR로 전송됩니다. 여기서 지원자가 기억해야 할 점은 무엇입니까? 무엇보다도 신청자는 생성된 개인 키가 있는 미디어를 수령해야 합니다!

전자 매체에 대한 승인된 요청은 CA로 전송되며 CA에서 이를 기반으로 인증서가 발급됩니다.

이는 CA 운영의 기본 다이어그램입니다. 자세한 내용은 아래에서 명확해집니다. 한 가지 참고 사항: 데모의 편의를 위해 요청 준비 유틸리티인 CR 및 CA가 하나의 데모 콤플렉스로 결합되었습니다. 하지만 기능 분리에는 문제가 없습니다. 가장 간단한 해결책은 각 작업장에 CAFL63 사본을 두고 필요한 기능만 사용하는 것입니다.

프로젝트가 한창 진행되던 중 SimpleCA 프로젝트가 눈길을 끌었습니다. 이 프로젝트를 연구한 것은 CAFL63의 최종 구현에 매우 도움이 되었습니다.

Win32/Win64, Linux_x86/Linux_x86_64 플랫폼용 CAFL63 배포판을 다운로드하세요.

따라서 CAFL63 유틸리티를 실행합니다. CAFL63 시작 페이지가 화면에 나타납니다.

“Create DB” 버튼을 클릭하여 작업을 시작합니다. CA 데이터베이스는 크로스 플랫폼 SQLite3 DBMS를 사용하여 생성됩니다. CA 데이터베이스에는 여러 테이블이 포함되어 있습니다. 기본 테이블인 mainDB에는 루트 인증서, 비밀번호로 암호화된 개인 키, CA 설정을 저장하는 하나의 레코드만 포함되어 있습니다. 인증서 요청과 관련된 두 개의 테이블이 있습니다: 현재 reqDB 요청과 reqDBArc 요청 아카이브. 인증서에 대해 새 인증서 테이블 certDBNew, 인증서 보관 테이블 CertDB 및 해지된 인증서 테이블 CertDBRev의 세 가지 테이블이 생성됩니다. 모든 요청 및 인증서 테이블은 공개 키의 해시 값(sha1)을 기본 키로 사용합니다. 예를 들어 요청에 따라 인증서를 검색하거나 그 반대로 검색할 때 이는 매우 편리한 것으로 나타났습니다. 데이터베이스에는 해지된 인증서 목록을 저장하는 또 다른 테이블 crlDB가 있습니다. 그래서 “Create DB” 버튼을 클릭했습니다.

CA 생성은 데이터베이스를 저장할 디렉터리를 선택하고 CA의 개인 키에 액세스하기 위한 비밀번호를 설정하는 것부터 시작됩니다. "다음" 버튼을 누르면 CA에 대한 키 쌍의 유형과 매개변수를 선택하는 페이지로 이동합니다.

생성되는 인증 기관의 루트 인증서에 대한 키 쌍을 결정한 후 소유자에 대한 정보로 양식을 작성합니다(첫 번째 스크린샷은 건너뛰었습니다).

CAFL63 유틸리티에는 특정 "지능"이 있으므로 필드의 데이터 존재뿐만 아니라 TIN, OGRN, SNILS, OGRNIP, 이메일 주소와 같은 필드 작성의 정확성(빨간색 강조 표시 - 부정확함)도 제어합니다. , 등.

CA 소유자에 대한 정보로 필드를 채운 후 CA의 시스템 설정을 결정하라는 메시지가 표시됩니다.

러시아어 암호화를 사용하지 않으려면 일반 OpenSSL을 사용할 수 있습니다. 러시아어 암호화를 사용하려면 OpenSSL의 적절한 버전, 수정 사항을 지정해야 합니다. 자세한 내용은 다운로드한 배포판의 README.txt를 읽어보세요. 또한 연방법 -63에 따라 CA 자체의 인증과 CA가 사용하는 CIPF에 대한 정보를 지정하는 것이 제안되었습니다.

모든 필드를 올바르게 입력한 후 다시 한 번 정확성을 확인하고 "마침" 버튼을 클릭하라는 메시지가 표시됩니다.

"마침" 버튼을 클릭하면 CA 루트 인증서, 개인 키, 시스템 설정 등이 저장되는 CA 데이터베이스가 생성됩니다. 그러면 CAFL63 유틸리티의 시작 페이지가 화면에 다시 나타납니다. 이제 새로 생성된 CA의 데이터베이스를 생성했으므로 "DB 열기" 버튼을 클릭하고 데이터베이스가 있는 디렉터리를 선택한 다음 CA의 기본 작업 창으로 이동합니다.

"CA CA 보기" 버튼을 클릭하면 이것이 정확히 루트 인증서인지 확인됩니다.

다음 단계는 법인, 개인 및 개인 기업가를 위한 애플리케이션 템플릿/프로필을 준비하는 것입니다( 도구->설정->인증서 유형->새로 만들기 ):

새 프로필의 이름을 지정하면 해당 프로필의 구성을 결정하라는 메시지가 표시됩니다.

프로필을 준비한 후 CA는 지원자와 신청서를 받을 준비가 됩니다. 위에서 언급한 바와 같이, 신청자는 인증서 신청서를 작성하거나 작성하지 않고 올 수 있습니다.

신청자가 기성 신청서를 가지고 오면 서류를 확인한 후 신청서를 CA 데이터베이스로 가져옵니다. 이렇게 하려면 기본 작업 창에서 "인증서 요청" 탭을 선택하고 "요청/CSR 가져오기" 버튼을 클릭한 후 요청이 포함된 파일을 선택하세요. 그런 다음 요청에 대한 정보가 포함된 창이 나타납니다.

요청을 검토하고 올바르게 작성되었는지 확인한 후 "가져오기" 버튼을 클릭하여 데이터베이스에 입력할 수 있습니다. CA 데이터베이스에 요청을 다시 입력하려고 하면 다음 메시지가 표시됩니다.

CA 데이터베이스의 요청은 CA에서 생성된 "Locale" 또는 신청자가 직접 생성한 "Import"로 표시되며("유형" 열) CA에서 신청서를 받은 시간도 기록됩니다. . 이는 갈등 상황을 처리할 때 유용할 수 있습니다.

신청자가 신청서 없이 와서 신청서 작성을 요청하는 경우 먼저 결정해야 할 사항( 설정->인증서 유형->개인->편집 ) 키 쌍 유형( ->키 쌍 ), 무슨 목적을 위해 ( ->키 사용법 ) 인증서 필요:

키 쌍은 CIPF "LIRSSL-CSP"(OpenSSL 버튼)를 사용하여 생성하고 파일에 저장하거나 PKCS#11 토큰(PKCS#11 버튼)에 저장할 수 있습니다. 후자의 경우 토큰에 액세스하려면 라이브러리도 지정해야 합니다(예: RuToken ECP 토큰의 경우 rtpkcs11ecp 또는 ls11cloud ).

프로필을 결정하고 “다음” 버튼을 클릭한 후, 추가 절차는 루트 인증서 발급과 크게 다르지 않습니다. 한 가지 중요한 참고 사항: 개인 키가 저장되는 위치와 키에 액세스하기 위한 비밀번호를 기억하세요. 키 쌍을 생성하기 위해 PKCS#11 토큰/스마트 카드를 CIPF로 사용하는 경우 이를 컴퓨터에 연결해야 합니다.

생성되거나 가져온 응용 프로그램은 CA 데이터베이스에 있으며 기본 창의 "인증서 요청" 탭에 표시됩니다. 접수된 요청은 "고려" 단계("인증서 요청" 및 "요청 아카이브" 탭의 "상태" 열)에 있습니다. 새로 수신된 각 요청에 대해 결정을 내려야 합니다(선택한 요청을 마우스 오른쪽 버튼으로 클릭하면 상황에 맞는 메뉴).

각 요청은 거부되거나 승인될 수 있습니다.


요청이 거부되면 현재 reqDB 요청 테이블에서 reqDBArc 요청 아카이브 테이블로 이동되어 "인증서 요청" 탭에서 사라지고 "요청 아카이브" 탭에 나타납니다.

승인된 애플리케이션은 인증서가 발급될 때까지 reqDB 테이블과 "인증서 요청" 탭에 남아 있다가 보관됩니다.

인증서 발급 절차("인증서 발급" 메뉴 항목)는 애플리케이션 생성 절차와 거의 다릅니다.

발급된 인증서는 인증서 탭에 즉시 나타납니다. 이 경우 인증서 자체는 CA 데이터베이스의 certDBNew 테이블에 들어가고 게시될 때까지 그대로 유지됩니다. 인증서는 공용 서비스로 전송되는 새 인증서의 SQL 덤프로 내보낸 후에 게시된 것으로 간주됩니다. 인증서를 게시하면 인증서가 certDBNew 테이블에서 certDB 테이블로 이동됩니다.

"인증서" 탭에서 선택한 줄을 마우스 오른쪽 버튼으로 클릭하면 기능이 포함된 메뉴가 나타납니다.

키가 생성되어 파일에 저장된 CA에서 요청이 생성된 경우 PKCS#12 컨테이너를 생성하여 신청자에게 전송해야 합니다.

"친숙한 이름"에 주의를 기울여야 합니다. 그 안의 따옴표는 이스케이프되어야 합니다.

PKCS#12 보호 컨테이너가 생성된 후 신청자의 개인 키가 포함된 파일은 파기됩니다.

따라서 CA는 생명을 시작하고 첫 번째 인증서를 발급했습니다. CA의 임무 중 하나는 발급된 인증서에 대한 무료 액세스를 구성하는 것입니다. 인증서는 일반적으로 웹 서비스를 통해 게시됩니다. CAFL63에는 다음과 같은 서비스도 있습니다.

공용 서비스에 인증서 및 인증서 해지 목록을 게시하기 위해 CA는 먼저 인증서를 파일에 업로드하거나(인증서->인증서 내보내기) 전체 인증서 테이블의 SQL 덤프를 만듭니다. 이 테이블에서 인증서 데이터베이스를 생성하고 인증서 목록을 여기에 로드한 후 새 인증서의 SQL 덤프를 만들어 공공 서비스 데이터베이스에 추가합니다.

CA의 기본 기능은 내무부가 만료된 여권과 관련하여 수행하는 작업과 유사하게 취소된 인증서 목록을 게시하는 것입니다. 소유자가 신청하면 인증서가 취소될 수 있습니다. 해지의 주된 이유는 개인 키의 손실 또는 그에 대한 신뢰 상실입니다.

인증서를 취소하려면 "인증서" 탭에서 인증서를 선택하고 마우스 오른쪽 버튼을 클릭한 후 "인증서 취소" 메뉴 항목을 선택하세요.

해지 절차는 요청 생성 또는 인증서 발급 절차와 다르지 않습니다. 해지된 인증서는 CA 데이터베이스의 cerDBRev 테이블로 이동하고 "해지된 인증서" 탭에 나타납니다.

CA의 마지막 기능인 CRL 발행, 인증서 해지 목록을 고려해야 합니다. CRL 목록은 "CRL/CRL 생성" 버튼을 클릭하면 "해지된 인증서" 탭에 생성됩니다. 여기에서 관리자에게 필요한 것은 CA 비밀번호를 입력하고 CRL 발행 의사를 확인하는 것뿐입니다.

발급된 CRL은 데이터베이스의 crlDB 테이블로 이동하여 “CRL/SOS” 탭에 표시됩니다. CRL을 보거나 공개 서비스에 게시하기 위해 내보내려면 항상 그렇듯이 원하는 줄을 선택하고 마우스 오른쪽 버튼을 클릭한 후 메뉴 항목을 선택해야 합니다.

CAFL63 배포판 다운로드플랫폼 Win32/Win64, Linux_x86/Linux_x86_64의 경우. 게다가 이 모든 것이 Android 플랫폼에서 성공적으로 작동합니다.

규정

인증센터

-부드러운"

1. 인증기관 정보.................................................................... ......... ................................................ 2

2. 용어 및 정의....................................................................... ...... ............................................ ............ .......... 2

3. 일반 조항................................................................. ........... ................................................. ..................................... 4

4. 당사자의 권리와 의무.................................................................. ................... ................................................... ............... ..... 6

5. 인증센터 서비스 이용규칙.................................................................. ............. ....9

6. 기타 조건................................................................. ..... ............................................ .......................................... 13

7. 인증센터의 보수.................................................................. ........................................... 21

8. 분쟁 해결........................................................... ...................... ............................ ............................ ................. 21

9. 당사자의 책임.................................................................. ........ ................................................. ............................... 21

1. 인증 기관에 대한 정보

대리인 - 대표 인증센터, 계약에 기초하여 다음을 대신하여 수행합니다. 인증센터여권이나 기타 신분 증명서를 사용하여 개인을 식별하고, 사용자가 제출한 문서를 수락하고 확인함으로써 사용자 또는 위임된 대리인을 식별하는 절차 인증센터.

전자 서명 - 전자 형식의 다른 정보(서명된 정보)에 첨부되거나 다른 방식으로 연관되어 있고 정보에 서명한 사람을 식별하는 데 사용되는 전자 형식의 정보.

전자서명확인키 인증서 - 회사가 발행한 전자문서 또는 종이문서 인증센터또는 권한을 위임받은 대리인 인증센터및 상기 전자서명확인키가 상기 전자서명확인키 인증서 소유자의 것임을 확인하는 단계를 포함한다.

적격 전자 서명 확인 키 인증서 (이하 인증서라고 함) - 공인기관이 발행한 전자서명확인키 인증서 인증센터또는 공인된 공인 대리인 인증센터.

전자서명확인키 인증서 소유자 - 이 규정에서 정한 절차에 따라 전자서명확인키 인증서를 발급받은 자.

전자서명키 - 전자 서명을 생성하기 위한 고유한 문자 시퀀스입니다.


전자서명 확인키 - 전자 서명 키와 고유하게 연관되어 있고 전자 서명의 진위 여부를 확인(이하 전자 서명 확인)하기 위한 고유한 문자 시퀀스입니다.

전자 서명 도구 - 전자 서명 생성, 전자 서명 확인, 전자 서명 키 생성 및 전자 서명 확인 키 중 적어도 하나의 기능을 구현하는 데 사용되는 암호화(암호화) 도구입니다.

단일 레지스터 – 다음을 포함하는 일반적인 구조의 참고서적:

· 공인 인증 기관에서 발행한 주문 참여자의 서명 키에 대한 취소된 인증서 목록 및 취소된 인증서 목록에 대한 배포 지점 표시.

전자 서명 키 손상 - 사용된 전자서명키가 정보의 보안을 보장한다는 신뢰 상실.

인증 기관 사용자 (이하 이용자)– 규정에 가입하여 등록된 개인 인증센터(법인 또는 개인 기업가의 규정에 가입한 경우 - 법인, 개인 기업가의 권한을 위임받은 대표자인 개인).

공인 인증 기관의 사용자 – 주문에 참여하는 개인 또는 법인의 위임된 대리인인 개인 - 주문에 참여하고 인증센터에 등록되어 있으며 인증센터에서 발급한 전자서명확인키 인증서를 소유한 자 ;

별명 – 개인이 고의로 합법적으로 등록을 위해 사용하는 가상의 이름 인증센터.

전자문서 – 전자 서명으로 서명(보호)되고 종이 문서와 동등한 법적 효력을 가지며 권한 있는 사람의 자필 서명과 인증된 인장이 서명된 전자 형식의 문서입니다.

인증센터 근무일(이하 근무일) - 이용시간은 주말, 공휴일을 제외한 평일 09:00 ~ 18:00 입니다. 주말과 공휴일은 러시아 연방 정부의 결정에 따라 날짜 이전을 고려하여 결정됩니다.

인증기관 등록 – 문서 세트 인증센터다음 정보를 포함하여 전자 및/또는 종이 형태로 제공됩니다.

· 규정 가입 신청 등록 인증센터;

· 사용자 등록 신청 등록 인증센터;

· CA에 등록된 사용자 등록;

· 전자서명 확인키 인증서 생성을 위한 신청서 등록;

· 전자서명확인키인증서의 취소(폐기) 신청 등록

· 전자서명확인키인증서 정지/갱신 신청 등록

· 전자 문서의 전자 서명의 진위 여부를 확인하기 위한 신청서 등록

· 위임자의 전자서명 확인 신청서 등록 인증센터발급된 인증서에서

· 전자서명 확인키 인증서 등록;

· 생산된 인증서 폐기 목록을 등록합니다.

인증서 해지 목록(CRL) – 권한 있는 사람의 전자 서명이 포함된 전자 문서 인증센터에는 특정 시점에 취소되거나 정지된 인증서의 일련번호 목록이 포함되어 있습니다.

공식 대리인 – 법인 또는 개인으로부터 서비스 이용을 허가받은 개인 인증센터.

인증센터 지정자 – 직원인 개인 인증센터그리고 부여 인증센터전자서명확인키인증서 및 폐지된 인증서 목록을 인증하는 기관입니다.

공인 운영자 전자 플랫폼(인가된 운영자) - 인증 센터와 승인 계약을 체결하고, 인증 센터가 생성한 전자 서명 확인 키 인증서의 사용을 보장할 의무가 있는 전자 플랫폼의 운영자 인증센터.

3. 일반 조항

3.1. 규정의 주제

이 규정 인증센터(이하 '규정'이라 한다)은 서비스의 제공조건과 이용규칙을 정한다. 인증센터, 권리, 의무, 책임을 포함합니다. 인증센터및 사용자 인증센터, 데이터 형식, 작업 보장을 위한 기본 조직 및 기술 조치 인증센터.

3.2. 규정에 대한 가입

3.2.1. 인증 센터는 지정된 사람이 LISSI-Soft 인증 센터의 서비스 제공을 위한 공모 계약을 체결한 경우에만 개인 및 법인의 위임된 대리인의 등록을 수행합니다.

3.2.2. CA 사용자 등록이란 인증센터 등록센터의 등록부에 CA 사용자에 대한 등록정보를 입력하는 것을 의미합니다.

3.3. 규정 개정

3.3.1. 부록을 포함한 규정의 수정(추가)이 이루어졌습니다. 인증센터일방적으로.

3.3.2. 규정의 개정(추가) 통지가 수행됩니다. 인증센터이러한 변경 사항(추가 사항)을 웹사이트에 의무적으로 게시함으로써 인증센터주소로 -
http://ca. 부드러운. ***** 개정 번호와 개정 날짜를 의무적으로 입력해야 합니다.

3.3.3. 모든 변경(추가)이 이루어졌습니다. 인증센터러시아 연방 현행법의 변경과 관련되지 않은 자체 주도로 규정이 발효되며 웹 사이트에 규정에 대한 변경 및 추가 사항이 게시된 날로부터 2개월 후에 의무화됩니다. 인증센터주소 - http://ca. 부드러운. *****

3.3.4. 모든 변경(추가)이 이루어졌습니다. 인증센터러시아 연방 현행법의 변경과 관련된 규정은 이러한 법률의 변경(추가) 발효와 동시에 발효됩니다.

3.3.5. 발효 시점부터 규정에 대한 모든 변경 및 추가 사항은 서비스 제공을 위해 공모 계약에 동의한 모든 사람에게 동일하게 적용됩니다. 인증센터, 개정(추가) 발효일 이전에 계약에 가입한 사람을 포함합니다. 변경(추가)에 동의하지 않는 경우 계약 당사자는 해당 변경(추가)이 발효되기 전에 공모 계약 제11조에 규정된 방식으로 공모 계약을 종료할 권리가 있습니다.

3.3.6. 본 규정의 모든 부속서, 개정 및 추가 사항은 필수적이고 필수적인 부분입니다.

3.4. 인증기관에서 제공하는 서비스

그 활동 과정에서 인증센터소비자(CA 사용자)에게 다음과 같은 유형의 서비스를 제공합니다.

· 등록부에 입력 인증센터사용자 등록 정보 인증센터(이하 CA 사용자라고 함).

· CA 사용자의 전자 서명을 확인하기 위한 키 인증서를 전자 형식으로 생성하고 CA 사용자의 전자 서명을 확인하기 위한 키 인증서 사본을 종이로 생성합니다.

· CA 사용자의 전자 서명을 확인하기 위해 제조된 키 인증서 등록을 유지합니다.

· CA 이용자의 요청에 따라 제작된 전자서명 확인키 인증서 등록부에 있는 전자서명 확인키 인증서 사본을 전자적 형태로 제공합니다.

· 소유자의 요청에 따라 전자서명확인키인증서를 취소(철회)합니다.

· 소유자의 요청에 따라 전자서명 확인키 인증서의 정지 및 갱신.

· CA 사용자에게 취소 및 정지된 전자서명확인키인증서에 대한 정보를 제공합니다.

· CA 사용자의 요청 시 전자 문서의 전자 서명의 진위 여부를 확인합니다.

· 위임자의 전자서명 진위 여부 확인 인증센터 CA 사용자의 요청에 따라 생성한 전자서명 확인키 인증서에 있습니다.

4. 당사자의 권리와 의무

4.1. 인증센터다음과 같은 권리가 있습니다:

4.1.1. CA 사용자의 전자서명 확인키 인증서에 해당하는 전자서명키의 설정된 유효기간이 만료된 경우 해당 인증서의 취소(폐기)를 거부합니다.

4.1.2. 해당 인증서에 해당하는 전자서명키의 설정된 유효기간이 만료된 경우 CA 사용자의 전자서명 확인키 인증서 정지를 거부합니다.

4.1.3. 해당 인증서에 해당하는 전자서명키의 설정된 유효기간이 만료된 경우 CA 사용자의 전자서명확인키 인증서 갱신을 거부합니다.

4.1.4. 해당 전자서명키의 훼손사실이 확인된 경우 CA 이용자의 전자서명확인키 인증서를 취소(폐기)하고, 취소(폐기)된 인증서의 소유자에게 통지하고 정당한 사유를 명시합니다.

4.1.5. CA 사용자의 전자서명 확인키 인증서의 유효성을 정지하고 정지된 인증서의 소유자에게 통지하고 정당한 사유를 명시합니다.

4.1.6. 전자서명 확인키 인증서 요청을 생성한 CA 사용자가 암호정보 보호 도구에서 지원되지 않는 경우 CA 사용자의 전자서명 확인키 인증서 발급을 거부합니다. 인증센터.

4.2. 사용자 인증센터다음과 같은 권리가 있습니다:

4.2.1. 에서 생성한 전자서명확인키의 해지된 인증서 목록을 수신합니다. 인증센터.

4.2.2. 권한 있는 사람의 전자서명을 확인하기 위한 키인증서를 취득합니다. 인증센터.

4.2.3. 위임자의 전자서명 확인을 위한 열쇠인증서 적용 인증센터권한 있는 사람의 전자 서명을 확인하기 위해 인증센터인증기관이 발행한 전자서명확인키 인증서에 포함됩니다.

4.2.4. 이용자의 전자서명 확인을 위한 핵심인증서 적용 인증센터전자서명검증키인증서에 기재된 정보에 따라 전자문서의 전자서명을 검증합니다.

4.2.5. 에서 생성한 전자서명확인키 폐지증명서 목록 적용 인증센터, 전자서명확인키인증서 상태를 확인합니다.

4.2.6. 연락하다 인증센터전자 문서의 전자 서명의 진위 여부를 확인합니다.

4.2.7. 연락하다 인증센터위임된 사람의 전자 서명의 진위 여부를 확인하기 위해 인증센터그가 제작한 전자서명 확인키 인증서에.

4.2.8. 전자 서명 키를 저장하려면 사용된 암호화 정보 보호 도구가 지원하고 러시아 연방 인증 규칙에 따라 인증되었으며 러시아 연방 법률 및 규제 법률 문서의 요구 사항을 준수하는 매체를 사용하십시오.

4.2.9. 제공되는 혜택을 활용하세요 인증센터통신 회선을 통해 전송하는 소프트웨어 인증센터전자서명인증키인증서를 전자문서로 발급 요청합니다.

4.2.10. 연락하다 인증센터해당 전자서명키의 유효기간 내에 해당 전자서명확인키의 인증서를 취소(철회)하는 행위

4.2.11. 연락하다 인증센터해당 전자서명키의 유효기간 동안 전자서명확인키 인증서의 유효성을 정지합니다.

4.2.12. 연락하다 인증센터해당 전자서명키의 유효기간 및 인증서가 정지된 기간 동안 전자서명확인키 인증서의 유효기간을 갱신합니다.

4.3. 책임 인증센터

4.3.1. 인증센터전자 서명 키를 생성하려면 승인된 사람을 사용해야 합니다. 인증센터전자 서명의 형성은 러시아 연방의 인증 규칙에 따라 인증된 암호화 정보 보호 수단일 뿐입니다.

4.3.2. 인증센터반드시 권한 있는 사람의 전자 서명 키를 사용해야 합니다. 인증센터 CA가 발행한 서명 인증서, CA 사용자의 전자 서명을 확인하기 위한 키 및 해지된 인증서 목록에만 해당됩니다.

4.3.3. 인증센터권한을 부여받은 자의 전자서명키를 보호하기 위한 조치를 취할 의무가 있습니다. 인증센터무단 접근으로부터.

4.3.4. 인증센터모스크바시의 시간대를 고려하여 GMT(그리니치 표준시)에 따라 작업을 구성할 의무가 있습니다. 인증센터활동을 지원하기 위해 모든 소프트웨어와 하드웨어를 적시에 동기화해야 합니다.

4.3.5. 인증센터는 본 규정에 명시된 등록 절차에 따라 CA 사용자의 등록을 보장할 의무가 있습니다. 인증센터사용자 등록 정보의 고유성을 보장할 의무가 있습니다. 인증센터, 전자서명확인키인증서의 소유자를 식별하는 데 사용됩니다.

4.3.6. 인증센터는 본 규정에 정의된 절차에 따라 CA 등록 사용자의 전자 서명을 확인하기 위한 키 인증서 생성을 보장할 의무가 있습니다.

4.3.7. 인증 기관은 다음을 수행할 의무가 있습니다.


· CA 사용자의 전자 서명을 확인하기 위해 생성된 키 인증서의 일련 번호의 고유성을 보장합니다.

· 발급된 CA 사용자 인증서의 전자 서명 확인 키 값의 고유성을 보장합니다.

4.3.8. 인증센터이용자의 요청에 따라 전자서명확인키 인증서를 취소(폐기)할 의무가 있습니다. 인증센터전자서명확인키 인증서를 취소(폐지)하려면 신청서를 제출한 영업일의 다음 영업일까지 폐기된 인증서 목록에 취소(폐지)된 인증서에 대한 정보를 날짜와 함께 입력해야 합니다. 입국 시간 및 철회 사유.

4.3.9. 인증센터 CA 이용자가 전자서명 확인키 인증서의 효력을 정지해 달라는 요청이 있는 경우, 신청서를 제출한 영업일의 다음 영업일까지 전자서명 확인키 인증서의 유효성을 정지시켜야 할 의무가 있는 경우, 해당 정보를 입력하십시오. 정지된 인증서에 대해 폐기된 인증서 목록에 포함되어 정지 날짜 및 시간 입력과 정지 기호를 나타냅니다.

4.3.10. 인증센터 CA 이용자가 전자서명확인키인증서의 유효성 갱신을 신청한 경우(인증서의 유효기간이 정지된 기간 중에 신청이 접수된 경우) 전자서명확인키인증서의 유효성을 갱신하여야 할 의무가 있으며, 취소된 인증서 목록에서 정지된 인증서에 관한 정보를 제외하기 위한 신청서가 제출된 영업일 다음 영업일까지.

4.3.11. 인증센터은(는) 전자서명확인키인증서의 유효기간이 정지된 기간이 경과한 경우 전자서명확인키인증서를 취소(폐기)할 의무가 있습니다.

4.3.12. 인증 기관은 인증 기관의 등록을 유지해야 할 의무가 있습니다.

4.4. 사용자 책임 인증센터

4.4.1. CA 사용자는 전자 서명 키를 비밀로 유지하고 해당 키의 분실, 공개, 왜곡 및 무단 사용을 방지하기 위해 가능한 모든 조치를 취할 의무가 있습니다.

4.4.2. CA 사용자는 전자 서명 키가 이전에 다른 사람에 의해 사용되었거나 사용되었다는 사실을 알게 된 경우 전자 서명 키를 사용하지 않을 의무가 있습니다.

4.4.3. CA 이용자는 전자서명키에 해당하는 전자서명확인키 인증서에 명시된 유효범위에 따라서만 전자서명키를 사용할 의무가 있습니다.

4.4.4. CA 사용자는 즉시 연락할 의무가 있습니다. 인증센터전자서명키가 분실, 유출, 왜곡된 경우 및 해당 키가 타인에 의해 사용되었거나 이전에 사용된 사실을 이용자가 인지한 경우 전자서명확인키 인증서의 취소(철회) 신청 .

4.4.5. CA 이용자는 해지(철회)신청을 한 전자서명확인키인증서와 연계된 전자서명키를 사용하지 않을 의무가 있습니다. 인증센터, 인증서 취소(해지) 신청서를 제출한 시점부터 사용자에게 인증서 취소(해지) 사실을 공식적으로 통지한 시점까지 계산된 시간.

4.4.6. CA 이용자는 정지신청이 접수된 전자서명확인키 인증서에 연계된 전자서명키를 사용하지 않을 의무가 있습니다. 인증센터, 인증서 정지 신청을 한 시점부터 사용자에게 인증서 정지 사실을 공식적으로 통지한 시점까지 계산된 기간입니다.

4.4.7. CA 이용자는 취소(폐기)되거나 유효기간이 정지된 전자서명확인키인증서와 연계된 전자서명키를 사용하지 않을 의무가 있습니다.

4.4.8. CA 사용자는 정기적으로, 적어도 10일에 한 번씩 인터넷 페이지를 볼 의무가 있습니다. 인증센터, http://ca에 있습니다. 부드러운. ***** 규정 변경에 관해.

5. 인증센터 서비스 이용 규칙

5.1. 사용자 등록

인증센터특정 개인이 본 규정의 3.2항에 따라 공모 계약에 동의한 경우에만 개인 및 법인의 권한 있는 대리인 등록을 수행합니다.

사용자 등록 인증센터첫 번째 전자 서명 확인 키 인증서의 생성은 등록 절차를 진행 중인 사용자 또는 그의 위임된 대리인이 사무실에 직접 도착한 후 등록 신청을 기반으로 수행됩니다. 인증센터아니면 에이전트 사무실로 가세요.

등록 신청서는 본 규정의 부록 2.1, 2.2에 나와 있습니다. 규정에 가입한 당사자(규정 당사자가 법인인 경우)의 권한 있는 대리인인 사용자는 본 부록 3.1의 형식으로 자신의 이름으로 발급된 위임장을 제출해야 합니다. 규정.

사용자 등록 인증센터등록을 수행하기 위한 위임장을 기반으로 CA 사용자의 승인된 대리인이 수행할 수 있습니다. 인증센터. 등록을 위한 위임장 인증센터본 규정의 부록 4.1, 4.2의 형식에 따라 작성되어야 합니다.

담당직원 인증센터여권을 사용하는 사람을 식별하여 등록 절차를 밟는 사람의 식별 절차를 수행합니다. 등록 절차를 밟는 사람이 확실하게 확인된 후 담당 직원은 인증센터문서를 수락하고 검토한 후 결정을 내립니다.

등록이 거부되는 경우, 신청 거부 이유를 명시하여 사용자에게 이를 통지합니다.

긍정적인 결정이 내려지면 담당 직원은 인증센터레지스터에 등록 정보를 입력하기 위한 등록 작업을 수행합니다. 인증센터, 전자서명 확인키 인증서를 생성합니다.

5.2. 전자서명확인키증명서 발급 및 수령

이용자의 전자서명 확인키 인증서가 생성됩니다. 인증센터전자서명 확인키 인증서 생성 요청에 따라 사용자 인증서 생성 요청은 CA 사용자 소프트웨어를 사용하여 전자적으로 제출됩니다.

전자서명확인키인증서 요청 처리는 요청이 접수된 영업일 다음 영업일까지 완료되어야 합니다. 인증센터.

전자서명 확인키 인증서 생성 요청을 전자적 형태로 생성할 수 없는 경우, 전자서명 소유자를 식별하는 데 필요한 정보가 포함된 사용자 애플리케이션을 기반으로 CA 사용자 인증서 생성이 수행됩니다. 확인 키 인증서. 종이 형태의 전자서명 확인키 인증서 제작 신청서를 제출합니다. 인증센터사용자가 사무실에 직접 도착한 경우 인증센터아니면 에이전트 사무실로 가세요.

전자서명 확인키 인증서 생성 신청서는 본 규정의 부록 5.1, 5.2에 나와 있습니다.

5.3. CA 이용자의 전자서명확인키인증서의 취소(폐기)

전자서명확인키인증서의 취소(해지)는 그 소유자가 인증센터에 제출한 신청 또는 공모계약에 동의한 당사자(계약당사자가 법인) 인증센터에 등록된 계약 당사자 대표의 위임장을 취소합니다.

전자서명인증키 인증서를 취소(철회)하려면 이용자는 다음 사이트에 신청서를 제출합니다. 인증센터인증서 취소(철회)를 위한 서면 또는 전자 형식.

전자서명검증키인증서 취소(철회) 신청서의 서면양식은 본 규정 별표 7.1, 7.2에 기재되어 있다.

규정에 동의한 당사자이자 법인인 당사자는 인증센터에 등록된 수권대리인의 전자서명 확인키 인증서를 취소(취소)할 권리가 있습니다. . 규정에 동의한 당사자의 승인된 대표자인 CA 사용자의 전자 서명 확인 키 인증서의 취소(철회)는 CA 사용자에게 다음 서비스를 제공한 근거가 되는 위임장을 취소함으로써 수행됩니다. 인증센터. 위임장 취소 신청서는 본 규정의 부록 11에 나와 있습니다.

전자서명확인키인증서의 취소(철회)신청서를 전자적 형태로 생성하여 제출합니다. 인증센터 CA 사용자 소프트웨어를 사용하며 PKCS#7 형식의 전자 문서입니다. 인증서 폐기 요청은 서명된 데이터로 사용되며, 전자 서명은 사용자의 유효한 전자 서명 키에 대해 수행됩니다.

신청서는 인증 센터의 근무 시간에만 접수되고 고려됩니다.

전자서명확인키인증서 취소(철회) 신청 처리 및 전자서명확인키인증서 취소(철회)에 대한 CA 이용자의 공식 통지는 늦어도 영업일 다음 영업일까지 이루어져야 합니다. 그 동안 인증 센터에서 신청서를 승인했습니다.

전자서명확인키인증서의 취소(폐지) 사실을 공식적으로 통지하는 것은 취소(폐기)된 인증서에 관한 정보를 포함하는 폐기된 인증서 목록을 공개하는 것입니다. 전자서명확인키 인증서의 해지(폐기) 시점은 폐기된 인증서 공개 목록의 thisUpdate 필드에 명시된 해지(폐기된) 인증서에 대한 정보가 포함된 폐기된 인증서 목록이 공개된 시점을 의미합니다.

해지된 인증서 목록 배치에 대한 정보는 CRL 배포 지점 필드의 인증 기관에서 발급한 서명 키 인증서에 입력됩니다.

5.4. 전자서명확인키인증서의 유효성 정지/갱신

5.4.1. 전자서명확인키인증서의 유효성 정지

전자서명확인키인증서의 유효성을 정지시키려면 이용자는 다음 주소로 신청서를 제출합니다. 인증센터서면 또는 전자 형식으로 인증서의 유효성을 정지합니다.

전자서명검증키인증서 정지신청서 양식은 본 규정 별표 8.1, 8.2에 기재되어 있다.

전자서명확인키인증서 정지신청서를 전자문서로 생성하여 제출합니다. 인증센터 CA 사용자 소프트웨어를 사용하며 PKCS#7 형식의 전자 문서입니다. 인증서의 유효성 정지 요청을 서명 데이터로 활용하며, 사용자의 유효한 전자 서명 키에 대한 전자 서명이 수행됩니다.

인증서의 유효성은 달력일로 계산된 기간 동안 정지됩니다. 인증서를 정지할 수 있는 최소 기간은 10일입니다.

종이로 발급된 증명서의 유효성을 정지하기 위한 신청서 제출 인증센터이에 대한 고려는 업무시간에만 이루어집니다.

인증서 정지 신청 처리 및 인증서 정지에 대한 사용자 통지는 신청서가 제출된 영업일 다음 영업일까지 완료되어야 합니다. 인증센터.

전자서명인증키 인증서의 정지 시점은 본 인증서의 정지 사실을 이용자에게 공식적으로 통지한 시점입니다.

이용자의 전자서명확인키인증서가 정지된 기준이 되는 전자문서에 서명한 시점은 해당 문서가 등록부에 입력된 시점으로 간주됩니다. 인증센터.

이용자의 전자서명확인키의 인증서 정지기간 중에 있는 경우 인증센터 CA 사용자로부터 인증서 갱신 신청을 받지 못한 경우 인증서가 취소(해지)됩니다. 인증센터.

5.4.2. 전자서명확인키 인증서의 유효성 갱신

전자서명확인키 인증서의 유효성을 갱신하기 위해 사용자는 다음 주소로 신청서를 제출합니다. 인증센터인증서 갱신을 위해 종이 또는 전자 형식으로 제공됩니다.

전자서명 확인키 인증서 갱신 신청서의 서면 양식은 본 규정의 부록 9.1, 9.2에 나와 있습니다.

전자서명확인키인증서 갱신신청서를 전자문서로 생성하여 제출합니다. 인증센터 CA 사용자 소프트웨어를 사용하며 PKCS#7 형식의 전자 문서입니다. 인증서 갱신 요청은 서명 데이터로 사용되며, 전자 서명은 사용자의 현재 전자 서명 키에 대해 수행됩니다.