이 기사는 Linux 및 기타 시스템에서 널리 사용되는 프로덕션 등급 라이브러리이자 툴킷인 OpenSSL을 사용하여 암호화의 기본을 다루는 두 기사 중 첫 번째 기사입니다. (최신 버전의 OpenSSL을 설치하려면 여기를 참조하십시오.) OpenSSL 유틸리티는 명령줄에서 사용할 수 있으며 프로그램은 OpenSSL 라이브러리의 함수를 호출할 수도 있습니다. 이 기사의 샘플 프로그램은 OpenSSL 라이브러리의 소스 언어인 C를 사용합니다.
두 부분으로 구성된 이 시리즈는 암호화 해시, 디지털 서명, 암호화 및 암호 해독, 디지털 인증서를 다룹니다. 내 웹사이트의 ZIP 파일에서 코드와 명령줄 예제를 찾을 수 있습니다.
먼저 OpenSSL 이름에서 SSL을 살펴보겠습니다.
SSL(Secure Socket Layer)은 1995년 넷스케이프가 발표한 암호화 프로토콜입니다. 이 프로토콜 계층은 HTTP 위에 위치하여 HTTPS에 S: 보안을 제공할 수 있습니다. SSL 프로토콜은 HTTPS에서 중요한 두 가지를 포함하여 다양한 보안 서비스를 제공합니다.
SSL에는 여러 버전(예: SSLv2 및 SSLv3)이 있으며 1999년에는 SSLv3 기반 버전이 등장했습니다. TLS(전송 계층 보안). TLSv1과 SSLv3은 유사하지만 서로 작동할 만큼 강력하지는 않습니다. 그러나 SSL/TLS는 종종 동일한 프로토콜이라고 합니다. 예를 들어 SSL이 아닌 TLS가 사용되는 경우에도 OpenSSL 함수에는 이름에 SSL이 포함되는 경우가 많습니다. 또한 OpenSSL 명령줄 유틸리티 호출은 openssl로 시작됩니다.
OpenSSL 문서는 OpenSSL 툴킷의 크기로 인해 찾고 사용하기 어려운 매뉴얼 페이지를 제외하고는 드물습니다. 명령줄과 코드 예제는 주요 주제를 하나로 묶습니다. 익숙한 예(HTTPS를 사용하여 웹 사이트에 액세스)부터 시작하여 해당 예를 사용하여 관심 있는 암호화 부분을 선택해 보겠습니다.
여기에 표시된 클라이언트 프로그램은 HTTPS를 통해 Google에 연결됩니다.
이 프로그램은 명령줄에서 컴파일하고 실행할 수 있습니다(-lssl 및 -lcrypto의 소문자 L에 유의하세요). < /p>
이 프로그램은 www.google.com 웹사이트에 대한 보안 연결을 시도합니다. Google 웹 서버와의 TLS 핸드셰이크 중에 클라이언트 프로그램은 하나 이상의 디지털 인증서를 수신하며, 클라이언트 프로그램은 이를 검증하려고 시도하지만 내 시스템에서는 실패했습니다. 그럼에도 불구하고 클라이언트 프로그램은 보안 채널을 통해 계속해서 Google 홈페이지를 확보합니다. 위 코드에서는 디지털 인증서만 강조 표시되어 있지만 이 프로그램은 이전에 언급한 보안 아티팩트에 의존합니다. 그러나 다른 아티팩트들은 여전히 이면에서 작동하고 있으며 이에 대해서는 나중에 자세히 설명하겠습니다.
일반적으로 HTTP(비보안) 채널을 여는 C 또는 C의 클라이언트 프로그램은 두 개의 프로세스인 파일 설명자 또는 네트워크 소켓과 같은 구조를 사용합니다(예: 이 클라이언트에 대한 엔드포인트 프로그램과 Google 웹 서버 간의 연결). 반면에 파일 설명자는 해당 프로그램에서 열린 파일 클래스를 식별하기 위해 프로그램 내에서 사용되는 구조인 음수가 아닌 정수 값입니다. 이러한 프로그램은 또한 구조를 사용하여 웹 서버 주소에 대한 세부 정보를 지정합니다.
이러한 상대적으로 낮은 수준 구조는 OpenSSL 라이브러리가 소켓 인프라 및 주소 사양과 같은 항목을 상위 수준 보안 구조로 캡슐화하기 때문에 클라이언트 프로그램에 나타나지 않습니다. 결과는 간단한 API입니다. 먼저 클라이언트 프로그램 예제의 보안 세부 사항을 살펴보겠습니다.
웹 서버와의 핸드셰이크 중에 클라이언트 프로그램은 서버의 신원을 인증하기 위해 하나 이상의 디지털 인증서를 받습니다. 그러나 클라이언트 프로그램은 자체 인증서를 보내지 않습니다. 이는 이 인증이 단방향임을 의미합니다. (웹 서버는 클라이언트 인증서를 요구하지 않도록 구성되는 경우가 많습니다.) 웹 서버 인증서 확인에 실패했지만 클라이언트 프로그램은 웹 서버에 연결된 보안 채널을 통해 계속해서 Google 홈페이지를 획득했습니다.
Google 인증서 확인 시도가 실패하는 이유는 무엇입니까? 일반적인 OpenSSL 설치 디렉터리는 ca-certificates.crt 파일이 포함된 /etc/ssl/certs입니다. 이 디렉터리와 파일에는 OpenSSL과 함께 제공되는 디지털 인증서가 포함되어 신뢰 저장소를 형성합니다. 신뢰 저장소는 필요에 따라 업데이트될 수 있으며, 특히 새로 신뢰된 인증서를 포함하고 더 이상 신뢰되지 않는 인증서를 제거할 수 있습니다.
클라이언트 프로그램이 Google 웹 서버로부터 세 개의 인증서를 받았지만 내 컴퓨터의 OpenSSL 신뢰 저장소에 정확히 일치하는 인증서가 없습니다. 현재 작성된 대로 클라이언트 프로그램은 예를 들어 Google 인증서(인증서를 인증하는 데 사용되는 서명)의 디지털 서명을 확인하는 방식으로 이 문제를 해결하지 않습니다. 서명을 신뢰할 수 있으면 서명이 포함된 인증서도 신뢰할 수 있어야 합니다. 그럼에도 불구하고 클라이언트 프로그램은 계속해서 페이지를 가져온 다음 Google 홈페이지를 인쇄합니다. 이에 대해서는 다음 섹션에서 더 자세히 설명합니다.
클라이언트 예(디지털 인증서)에 표시되는 보안 아티팩트부터 시작한 다음 다른 보안 아티팩트가 이와 어떻게 연관되어 있는지 살펴보겠습니다. 디지털 인증서의 주요 형식 표준은 X509이며, 프로덕션 수준 인증서는 Verisign과 같은 인증 기관(CA)에서 발급됩니다.
디지털 인증서에는 발급자의 신원과 디지털 서명(암호화된 암호화 해시)뿐만 아니라 다양한 정보(예: 활성화 및 만료 날짜, 소유자의 도메인 이름)가 포함됩니다. 인증서에는 식별 지문으로 사용되는 암호화되지 않은 해시 값도 있습니다.
해시 값은 임의 개수의 바이너리 비트를 고정 길이 다이제스트에 매핑하여 생성됩니다. 비트가 무엇을 나타내는지는 중요하지 않습니다(회계 보고서, 소설, 디지털 영화). 예를 들어, MD5(Message Digest 버전 5) 해시 알고리즘은 임의 길이의 입력 비트를 128비트 해시 값으로 매핑하는 반면, SHA1(Secure Hash Algorithm 버전 1) 알고리즘은 입력 비트를 160비트 해시 값으로 매핑합니다. 입력 비트가 다르면 (실제로는 통계적으로 고유한) 해시 값이 달라집니다. 다음 기사에서는 해시 함수를 암호학적으로 유용하게 만드는 요소에 대해 더 자세히 설명하고 중점을 둘 것입니다.
다양한 유형의 디지털 인증서(예: 루트 인증서, 중간 인증서, 최종 엔터티 인증서)가 있으며 이러한 인증서 유형을 반영하는 계층 구조가 형성됩니다. 이름에서 알 수 있듯이 루트 인증서는 계층 구조의 최상위에 있으며 그 아래의 인증서는 루트 인증서의 신뢰를 상속합니다. OpenSSL 라이브러리와 대부분의 최신 프로그래밍 언어에는 이러한 인증서를 처리하기 위한 X509 데이터 유형과 기능이 있습니다. Google의 인증서는 X509 형식이며 클라이언트 프로그램은 X509_V_OK인지 확인합니다.
X509 인증서는 키 쌍(공개* **키와 쌍을 이루는 개인 키)을 생성하기 위한 알고리즘(RSA가 주요 알고리즘)을 포함하는 공개 키 인프라(PKI)를 기반으로 합니다. 공개 키는 신원입니다. Amazon의 공개 키는 이를 식별하고 내 공개 키는 나를 식별합니다. 개인 키는 소유자에 의해 비밀로 유지되어야 합니다.
쌍으로 나타나는 키는 표준 용도로 사용됩니다. 메시지는 공개 키를 사용하여 암호화한 다음 동일한 키 쌍의 개인 키를 사용하여 해독할 수 있습니다. 개인 키는 문서나 기타 전자 가공물(예: 프로그램, 이메일)에 서명하는 데에도 사용할 수 있으며, 그런 다음 쌍의 공개 키를 사용하여 서명을 확인할 수 있습니다. 다음 두 가지 예에서는 몇 가지 세부 정보를 추가합니다.
첫 번째 예에서 Alice는 자신의 공개 키를 Bob을 포함한 전 세계에 배포합니다. 그런 다음 Bob은 Alice의 공개 키로 이메일을 암호화하고 암호화된 이메일을 Alice에게 보냅니다. Alice의 공개 키로 암호화된 메시지는 다음과 같이 그녀의 개인 키(자신의 개인 키로 가정)로 해독될 수 있습니다.
이론적으로는 Alice의 개인 키 메시지 없이도 해독이 가능하지만 실제 상황에서는 RSA와 같은 암호화 키 쌍 시스템을 사용하면 계산이 불가능합니다.
이제 두 번째 예에서는 문서의 진위를 증명하기 위해 문서에 서명해 주세요. 서명 알고리즘은 키 쌍의 개인 키를 사용하여 서명 중인 문서의 암호화 해시를 처리합니다.
Alice가 Bob에게 전송된 계약에 디지털 방식으로 서명한다고 가정합니다. 그런 다음 Bob은 Alice의 키 쌍에 있는 공개 키를 사용하여 서명을 확인할 수 있습니다.
Alice의 서명은 Alice의 개인 키 없이는 쉽게 위조될 수 없습니다. 따라서 Alice는 자신의 개인 키를 비밀로 유지해야 합니다.
클라이언트 프로그램에서는 디지털 인증서 외에는 이러한 보안 기능이 명시적으로 설명되지 않습니다. 다음 기사에서는 OpenSSL 유틸리티 및 라이브러리 기능을 사용하는 예제를 통해 더 자세히 설명합니다.
그동안 OpenSSL 명령줄 유틸리티, 특히 TLS 핸드셰이크 중에 웹 서버에서 인증서를 확인하는 유틸리티를 살펴보겠습니다. OpenSSL 유틸리티는 openssl 명령을 사용하여 호출한 다음 매개변수와 플래그의 조합을 추가하여 원하는 작업을 지정할 수 있습니다.
다음 명령을 살펴보십시오.
출력은 암호 모음()을 구성하는 관련 알고리즘 목록입니다. 다음은 약어를 명확히 하기 위한 설명과 함께 목록의 시작 부분입니다.
s_client 매개변수를 사용하는 다음 명령은 www.google.com에 대한 보안 연결을 열고 이 연결에 대한 정보를 화면에 표시합니다. . 모든 정보:
Google과 같은 주요 웹사이트에서는 인증을 위해 여러 개의 인증서를 보내는 경우가 많습니다.
출력은 암호화 알고리즘 제품군의 세부 정보를 포함하여 TLS 세션에 대한 요약 정보로 끝납니다.
프로토콜 TLS 1.2는 클라이언트 프로그램에서 사용되며 Session-ID는 openssl 유틸리티 프로그램과 Google 웹 서버 간의 연결입니다. 암호 항목은 다음과 같이 구문 분석할 수 있습니다.
암호 알고리즘 제품군은 지속적으로 발전하고 있습니다. 예를 들어, 얼마 전까지만 해도 Google은 RC4 스트림 암호화 알고리즘(나중에 RSA의 Ron Rivest가 개발한 Ron's Cipher 버전 4)을 사용했습니다. RC4에는 이제 알려진 취약점이 있으며, 이로 인해 Google이 AES128로 전환하게 된 것으로 추정됩니다.
보안 C 웹 클라이언트와 다양한 명령줄 예제를 통해 OpenSSL을 처음 살펴보니 추가 설명이 필요한 몇 가지 주제가 전면에 드러났습니다. 다음 기사에서는 암호화 해시부터 시작하여 디지털 인증서가 키 배포 문제를 해결하는 방법에 대한 보다 포괄적인 논의로 끝나는 등 더 자세히 설명합니다.
경유: /article/19/6/cryptography-basics-openssl-part-1
작성자: Marty Kalin 주제 선택: lujun9972 번역자: wxy 교정자: wxy