암호 의존성 감사와 선택

선택하는 암호 라이브러리는 프로젝트에서 가장 중대한 보안 결정 중 하나입니다. 선의의 개발자라도 부적절한 라이브러리를 사용하면 안전하지 않은 시스템을 만들 수 있습니다. 반대로 잘 설계된 라이브러리는 치명적인 실수를 저지르기 어렵게 만듭니다. 선택 과정은 체계적이어야 하며, 보안 실적, API 설계, 유지 관리 상태 및 목적 적합성을 평가해야 합니다.

암호 라이브러리에 대해 가장 먼저 확인할 사항 중 하나는 마지막으로 독립 감사를 받은 시점과 해당 감사의 범위입니다. 5년 전에 버전 1.0을 대상으로 수행된 감사는 현재 사용 중인 버전 3.0에 대해 상대적으로 적은 확신만 제공합니다. NCC Group, Trail of Bits, Quarkslab, Cure53와 같은 평판이 좋은 보안 업체가 수행했으며 사용하려는 구체적인 기능을 다루는 감사를 찾아야 합니다. 일부 라이브러리는 감사 보고서를 공개하지만, 감사가 전혀 없다는 것은 중요한 위험 요소입니다.

NVD(국가 취약점 데이터베이스)에서 라이브러리의 CVE 이력을 검토해야 합니다. CVE가 몇 건이나 존재하는지, 심각도 등급은 어떠한지, 어떤 유형의 취약점인지(논리 오류, 메모리 손상 또는 알고리즘 취약점), 유지 관리자가 얼마나 신속하게 패치를 출시했는지를 살펴보십시오. 가끔 CVE가 발생하더라도 신속하게 수정하는 라이브러리는 대응력 있는 유지 관리를 보여 줍니다. 심각도가 높은 CVE가 많거나 패치가 느린 라이브러리는 위험 신호입니다.

유지 관리되지 않는 암호 라이브러리는 위험합니다. 마지막 커밋 날짜, 릴리스 빈도, 보안 권고가 처리되고 있는지를 확인해야 합니다. 마지막 커밋이 3년 전인 라이브러리에는 알려진 취약점이 있어도 영원히 패치되지 않을 수 있습니다. 커뮤니티 규모는 검토의 폭에도 영향을 줍니다. 널리 사용되는 라이브러리는 틈새 프로젝트보다 보안 연구자의 검토를 더 많이 받습니다.

더 작고 설계 원칙이 분명한 API 범위가 보안에 더 유리합니다. 다양한 알고리즘 옵션과 구성 조정 기능을 노출하는 라이브러리는 잘못 구성될 가능성을 높입니다. 사용 사례마다 하나의 함수와 고정 알고리즘을 제공하는 libsodium을 암호 방식, 모드, 키 크기, 패딩, 초기화 벡터 처리를 각각 선택해야 하는 OpenSSL EVP와 비교해 보십시오. 라이브러리를 잘못 사용하기 어려울수록 보안을 중시하는 프로젝트에 더 적합합니다.

비밀 데이터와 관련된 작업(키 비교, 복호화, 서명 검증)에서는 비밀 값에 따라 분기하거나 메모리에 접근하지 않는 상수 시간 알고리즘을 구현에서 사용해야 합니다. 라이브러리 문서에 민감한 작업에 대한 상수 시간 보장이 명시되어 있는지, 또는 소스 코드가 승인된 상수 시간 비교 함수를 사용하는지 확인해야 합니다. 이러한 보장이 없는 라이브러리는 타이밍 부채널 공격에 취약합니다.

좋은 암호 라이브러리는 최신 알고리즘을 지원하고 오래된 알고리즘을 폐기할 계획을 세워야 합니다. 암호화에는 ChaCha20-Poly1305 또는 AES-256-GCM을, 서명에는 Ed25519 또는 ECDSA P-256을, 키 교환에는 X25519를, 비밀번호 해싱에는 Argon2id를 제공해야 합니다. 레거시 알고리즘(DES, RC4, MD5, SHA-1)만 제공하는 라이브러리는 다른 특성이 아무리 좋아도 신규 배포에 적합하지 않습니다.

전이 의존성을 평가해야 합니다. 암호 라이브러리가 어떤 라이브러리에 의존하며, 해당 라이브러리의 보안 상태는 어떠한지 확인하십시오. libsodium처럼 외부 의존성이 없는 라이브러리는 공급망 위험이 최소입니다. 자체 의존성을 가진 npm 패키지 수십 개에 의존하는 라이브러리는 공급망을 통한 공격 표면이 큽니다. 재현 가능한 빌드를 사용하는지도 확인하여 배포된 바이너리가 소스 코드와 일치하는지 검증할 수 있어야 합니다.

규제 산업(의료, 금융, 정부)에서는 FIPS 140-2 또는 140-3 검증을 받은 암호 모듈을 요구하는 경우가 많습니다. FIPS 검증에는 많은 비용과 시간이 들기 때문에 이를 획득한 라이브러리는 일부에 불과합니다. FIPS 공급자를 포함한 OpenSSL, Go의 crypto/tls에서 사용되는 BoringCrypto, 일부 HSM 라이브러리는 FIPS 검증을 받았습니다. 배포에 FIPS 준수가 필요하다면 이 요구 사항으로 인해 선택할 수 있는 라이브러리의 범위가 크게 좁아집니다.

하드웨어 보안 모듈(HSM)과 클라우드 KMS 서비스에는 키 작업을 위한 독점 API가 사용되는 경우가 많습니다. 애플리케이션을 AWS KMS나 특정 HSM 공급업체에 긴밀하게 결합하면 종속 위험이 발생합니다. 공급자를 전환할 수 있도록 라이브러리가 Tink의 KMS 통합과 같은 추상화 계층을 제공하는지 평가해야 합니다. 또한 HSM 공급업체가 지원을 중단하거나 가격을 인상하면 마이그레이션 비용이 상당할 수 있다는 점도 고려해야 합니다.

암호 라이브러리 종속 항목을 선택할 때 가장 중요한 원칙은 확립된 표준을 구현하는 잘 알려지고 널리 배포된 라이브러리를 사용하며, 암호 프리미티브를 직접 구현하지 않는 것입니다. 이론을 아무리 잘 이해하더라도 운영 코드에서 AES, RSA, 타원 곡선 연산 또는 인증 암호화를 올바르게 구현하는 일은 매우 어렵습니다. 검증된 라이브러리를 사용하는 것과 비교하면 직접 구현은 거의 언제나 감수할 가치가 없는 위험입니다.

라이브러리 선택 점검 목록: 최근 독립 감사의 범위와 보고서를 확인하고, CVE 이력과 패치 대응 시간을 검토하며, 활발한 유지 관리와 커뮤니티 참여를 확인하십시오. 오용을 방지하는 더 작은 API 범위를 우선하고, 민감한 작업에 대한 상수 시간 보장을 확인하며, 최신 알고리즘을 지원하는지 확인하십시오. 공급망 의존성을 평가하고, 규제 대상이라면 FIPS 검증 여부를 확인하며, KMS 공급업체 종속 위험을 고려하십시오. 또한 항상 프리미티브를 직접 구현하기보다 확립된 라이브러리를 사용해야 합니다.