Tim Hudson, OpenSSL Corporation 사장 – 인터뷰 시리즈

Tim Hudson는 SSLeay의 공동 저자이자 OpenSSL Conference의 조직자 중 한 명으로, 2026년 10월 13~15일 프라하에서 개최됩니다. 그는 시스템 및 네트워크 보안 분야에서 30년 이상 경력을 보유하고 있으며 OpenSSL Corporation의 사장이자 Cryptsoft Pty Ltd의 최고 기술 책임자(CTO)입니다. 1995년부터 그는 Eric Young과 함께 SSLeay를 공동 설립했으며, 이는 나중에 OpenSSL Library가 된 암호화 라이브러리를 공동 설립하고, RSA Security Australia 개발 센터를 공동 설립했으며, 미국 암호화 수출 규제 변화에 기여하고, 30건이 넘는 FIPS 140 검증을 주도했으며, OASIS KMIP 및 SAM 기술 위원회의 공동 의장을 역임하고, RSA Conference, AusCERT, ICMC, LinuxConf, OpenSSL Conference 등 주요 보안 컨퍼런스에서 발표했습니다.

OpenSSL은 전 세계 협업형 오픈 소스 프로젝트로, OpenSSL Library를 개발·유지 관리합니다. 이 라이브러리는 운영 체제, 클라우드 플랫폼, 엔터프라이즈 소프트웨어 및 연결된 디바이스 전반에 걸쳐 사용되며, 매일 수십억 건의 안전한 온라인 상호작용을 보호합니다. OpenSSL Foundation과 OpenSSL Corporation을 통해 프로젝트는 신뢰할 수 있는 암호화 기술을 발전시키고, 지속 가능한 오픈 소스 개발을 지원하며, 인터넷 보안을 강화하는 데 전념하고 있습니다.

당신은 1995년에 Eric Young과 함께 SSLeay를 공동 설립했으며, 미국이 아닌 SSL 구현이 필요하다는 것을 인식한 것이 OpenSSL의 기반이 되었습니다. 처음에 해결하려던 문제는 무엇이며, 그 기술이 인터넷 보안의 근본적인 부분이 될 것이라고 당시 예상했나요?

그 문제는 완전히 구체적이었으며, 먼저 상업적인 문제였습니다. 저는 브리즈번의 Mincom에서 일하고 있었고, 고객들이 통신을 보호할 방법을 필요로 했습니다. 그 기능을 구매할 방법이 없었습니다. 미국의 암호화 수출 통제 때문에 미국 제품은 전혀 공급되지 않거나, 키 길이가 지나치게 제한돼 실제로 배포하기 어려운 상황이었습니다. 이는 수출 정책에 대한 철학적 반대가 아니라, 구매할 수 있는 형태의 구성 요소가 존재하지 않아 고객을 기다리게 만든 엔지니어링 문제였습니다.

제가 가지고 있던 것은 대부분 사람들이 잊고 있던 지식이었습니다. Eric Young은 몇 년 전 좋은 품질의 DES 구현을 작성했었는데, 이는 순수하게 코드 자체를 위해 자유롭게 배포된 것이었습니다. Eric은 SSL 작업을 하고 있지 않았고, SSL에 대해서도 알지 못했습니다. Netscape가 사양을 발표했을 때 저는 이를 읽고, 문제를 Eric에게 전달했으며, 그가 이미 가지고 있던 것에서 비교적 작은 단계로 접근할 수 있다고 제안했습니다.

하지만 이것이 전부는 아니었습니다. 각 부분은 단순했지만 전체는 상당히 복잡했습니다. DES 구현은 하나의 대칭 암호만 제공했습니다. SSL은 공개키 암호, 임의 정밀도 연산, ASN.1, X.509 인증서 처리, 그리고 모든 것이 정확히 동작해야 하는 프로토콜 상태 머신을 필요로 했습니다. 암호학에서는 거의 정확함과 파손이 동일하기 때문입니다. 저는 규모를 낙관적으로 제시했지만, Eric은 곧 그 규모가 얼마나 큰지 깨달았고, 그것이 장애물이 아니라 매력이라고 생각했습니다. 다른 방식으로 시작했을 가능성은 거의 없다고 봅니다.

Eric이 암호 핵심을 담당했으며, 그래서 라이브러리 이름에 그의 이니셜이 들어갑니다. 저는 라이브러리를 실제로 배포할 수 있게 만드는 부분—응용 프로그램 통합, 테스트, 문서화, 커뮤니티 관리—을 맡았습니다. 또한 경쟁 암호 라이브러리가 사용되는 곳을 찾아 교체하거나 변환하는 작업도 적극적으로 했습니다. SSLtelnet, SSLftp, NCSA httpd 등 많은 패키지는 제가 만든 작업이며, Eric이 구현한 암호 알고리즘과 프로토콜 위에 구축된 응용 프로그램이었습니다. 이러한 역할 분담 덕분에 각자는 자신이 흥미를 느끼는 부분에 집중할 수 있었고, 이것이 프로젝트가 지속될 수 있었던 주요 이유라고 생각합니다.

호주에 있었기 때문에 문제를 해결할 수 있었고, 이후 많은 다른 사람들도 정확히 같은 이유로 같은 문제를 겪고 있었습니다. 브리즈번의 특정 고객 요구를 충족하기 위해 만든 것이 미국 외부는 물론 미국 내부에서도 유용하게 되었습니다.

우리가 그것이 무엇이 될지 알았나요? 아니요. 누구도 중요한 인프라를 만들려고 시작하지 않습니다. 중요한 인프라는 몇 년 뒤에 누가 그것에 의존하고 있는지를 알게 될 때 비로소 깨닫게 됩니다. 우리는 눈앞의 문제를 해결하고, 같은 벽에 부딪힌 다른 사람들의 질문에 답하는 것이 전부였습니다. 질문에 답하는 부분이 코드만큼이나 중요하게 되었습니다.

당신은 30년 넘게 암호학과 인터넷 보안 분야에 종사해 왔습니다. 그 기간 동안 위협 환경이 가장 크게 변한 점은 무엇이며, 기술이 크게 발전했음에도 불구하고 놀라울 정도로 비슷하게 남아 있는 보안 문제는 무엇입니까?

가장 큰 변화는 공격이 하나의 직업이 되었고, 경제적 모델이 뒤따랐다는 점입니다. 1990년대 중반에는 시스템을 해킹하는 사람들이 주로 흥미 때문에 했지만, 오늘날에는 전문화된 산업이 존재하고, 도구, 공급망, 고객 지원, 경우에 따라 국가 지원까지 있습니다. 이는 방어를 호기심에 대한 방어가 아니라, 예산과 마감일, 비즈니스 케이스를 가진 상대와 맞서야 함을 의미합니다.

두 번째 변화는 규모와 의존성입니다. 1995년 평균 애플리케이션은 직접 작성한 것이었지만, 오늘날 평균 애플리케이션은 조립된 것이며, 그 안의 대부분 코드는 한 번도 만나본 적 없는 사람들에 의해 작성되었습니다. 공격 표면은 여러분의 코드에서 의존성으로 이동했으며, 대부분 조직은 이에 맞게 사고 방식을 바꾸지 못했습니다.

놀랍게도 변하지 않은 부분은 실패 유형입니다. 우리는 여전히 신뢰할 수 없는 입력을 파싱하는 코드에 버그를 남깁니다. 기본값을 검토하지 않은 시스템을 배포합니다. 인증서는 토요일에 만료됩니다. 자격 증명은 있어서는 안 될 곳에 남아 있습니다. 그리고 암호학은 수학적으로 깨지는 경우는 거의 없으며, 우회되거나 잘못 구성되거나 단순히 비활성화됩니다. 1996년 상위 10대 침해 원인 목록과 지난달 목록을 나란히 보면 구분하기 어렵습니다. 기술은 완전히 변했지만 실수는 변하지 않았습니다.

OpenSSL 4.0은 2026년 4월에 출시되어 수년 만에 처음으로 주요 릴리즈를 맞이했습니다. 이번 릴리즈가 암호 인프라의 향후 방향을 무엇이라 말해 주며, OpenSSL에 의존하는 조직에 가장 큰 영향을 미칠 변화는 무엇이라고 보십니까?

4.0에서 가장 이해하기 쉬운 점은 이것이 기본적으로 ‘제거’ 릴리즈이며, 바로 그 점이 핵심이라는 것입니다.

우리는 ENGINE 인터페이스를 완전히 없앴고, SSLv3와 SSLv2 ClientHello도 제거했습니다. 더 이상 사용되지 않는 타원곡선과 명시적 EC 곡선도 컴파일 시 비활성화했습니다. ASN1_STRING을 불투명하게 만들고, 다수의 API 서명을 강화했습니다. 이러한 변경이 사람들에게 작업을 발생시키며, 동시에 중요한 변화이기도 합니다. 암호 라이브러리가 기능만 축적한다면 보안을 유지할 수 없기 때문입니다. 유지되는 모든 폐기된 코드 경로는 누군가가 대신 관리하는 공격 표면이며, 아무도 테스트하지 않습니다.

추가된 기능으로는 Encrypted Client Hello, RFC 8998 지원(하이브리드 SM2/ML‑KEM 그룹 포함), cSHAKE, SNMP 및 SRTP KDF, TLS 1.2용 협상된 FFDHE 등이 있습니다. 특히 ECH는 실제 프라이버시 격차를 메우는데, Server Name Indication이 TLS 1.3이 도입된 이후에도 방문하는 모든 사이트의 정체성을 누출하고 있기 때문입니다. 하지만 제거가 핵심 스토리입니다.

조직이 가장 기억했으면 하는 핵심은 4.0이 LTS 릴리즈가 아니라는 점입니다. 지원은 2027년 5월까지이며, 현재 장기 안정 릴리즈는 3.5로 2030년 4월까지 지원됩니다. 3.5에는 이미 포스트‑퀀텀 알고리즘이 포함되어 있습니다. 최신 코드를 원한다면 4.0을, 안정적인 장기 목표를 원한다면 3.5를 선택하십시오. 숫자가 높다고 무조건 선택하는 것은 매 사이클마다 보는 실수입니다.

포스트‑퀀텀 암호학이 연구 과제에서 마이그레이션 과제로 옮겨가고 있으며, OpenSSL은 이미 ML‑KEM, ML‑DSA, SLH‑DSA 및 하이브리드 포스트‑퀀텀 키 교환을 지원하고 있습니다. 양자 컴퓨팅이 아직 멀었다고 생각하는 비즈니스 리더들이 오늘 간과하고 있는 위험은 무엇입니까?

가장 흔한 실수는 “양자 컴퓨터가 언제 실용화될까”라는 질문에 집중하는 것입니다. 이는 잘못된 변수입니다. 올바른 질문은 “데이터가 얼마나 오랫동안 비밀을 유지해야 하는가”와 “마이그레이션에 얼마나 시간이 걸리는가”입니다. 두 번째를 첫 번째에서 빼면 실제 마감 기한이 나오며, 많은 조직에서는 이미 그 기한이 과거입니다.

암호화된 트래픽은 오늘 캡처해 무기한 저장할 수 있습니다. 만약 해당 정보가 20년 동안 민감성을 유지해야 한다면(환자 기록, 인사 파일, 지적 재산, 외교 자료, 재무 상황 등) 공격자는 지금 당장 양자 컴퓨터가 필요하지 않습니다. 언젠가 필요하게 될 것이고, 그 사이에 저렴한 저장소가 필요합니다. 이는 추측성 공격이 아니라 실제적인 위험입니다.

두 번째 간과되는 점은 마이그레이션이 하나의 프로젝트가 아니라는 것입니다. 키 교환은 비교적 쉬운 부분이며, 이미 많이 진행되고 있습니다. OpenSSL 3.5가 하이브리드 포스트‑퀀텀 키 교환을 TLS 기본값으로 만들었기 때문에, 많은 조직이 아직 결정하지 않은 상태에서 이미 포스트‑퀀텀 키 합의를 사용하고 있습니다. 서명과 인증서 계층은 더 복잡합니다. 여기에는 인증 기관, 하드웨어 신뢰 루트, 펌웨어 서명 키, 하드웨어 보안 모듈, 15년 이상 현장에서 사용될 디바이스 등이 포함되며, 이들은 RSA가 영원히 안전할 것이라는 가정하에 설계되었습니다.

세 번째는 예산에 반영되지 않는 제약입니다. 포스트‑퀀텀 서명은 크기가 큽니다. ML‑DSA‑65 서명은 ECDSA P‑256 서명보다 약 50배 크고, SLH‑DSA는 더 큽니다. 이는 핸드셰이크 크기, 제약 디바이스, 필드 제한이 있는 프로토콜, 위성·IoT 링크 등에 문제를 일으킵니다. 이러한 문제는 표준을 읽는 것이 아니라 실제 테스트를 통해 발견됩니다.

포스트‑퀀텀 마이그레이션의 과제 중 하나는 조직이 애플리케이션, 인프라, 디바이스, 서드‑파티 의존성 전반에 걸쳐 암호가 어디에 사용되는지 파악하지 못한다는 점입니다. 다음 대규모 알고리즘 전환이 비상 사태가 되지 않도록 기업은 어떻게 암호 인벤토리와 암호 민첩성을 접근해야 할까요?

불편한 진실부터 시작하십시오: 공급업체에게 설문지를 보내는 것으로는 암호 인벤토리를 구축할 수 없습니다. 답변은 마케팅 문구, 솔직한 불확실성, 그리고 몇 릴리즈 전의 답변이 뒤섞여 돌아옵니다. 저는 최근 하드웨어 공급업체 문서를 읽으며 이 격차를 직접 경험했으며, 문서에 적힌 내용과 실제 제품이 하는 일 사이의 차이가 구매자가 예상하는 것보다 훨씬 크다는 것을 알게 되었습니다.

직접 살펴봐야 합니다. 세 가지 레이어가 있으며 각각 다른 기술이 필요합니다. 직접 작성한 코드: 정적 분석, 의존성 스캔, 수년 전 하드코딩한 알고리즘 식별자 검색. 연결한 코드: 소프트웨어 부품 명세서(SBOM)를 확장해 암호 부품 명세서(CBOM)로 만들면 실제로 유용합니다. 구매하거나 연결한 것: 네트워크 관찰을 통해 와이어에서 실제 협상되는 내용을 확인해야 합니다. 이는 종종 누구도 예상하지 못한 실제 상황을 보여줍니다.

민첩성에 대해서는 원칙은 간단하지만 실천은 어렵습니다: 알고리즘은 코드 변경이 아니라 구성 옵션이어야 합니다. 암호를 바꾸려면 개발자, 빌드, 테스트, 릴리즈가 필요하다면 민첩성이 없는 것입니다. 이는 하나의 프로젝트에 불과합니다. 암호 작업을 여러분이 제어하는 인터페이스 뒤에 집중시켜, 400곳이 아닌 한 곳만 바꾸면 되게 하십시오.

그리고 거의 모든 사람이 건너뛰는 부분: 실제로 실행해 보세요. 민첩성을 사용해 본 적이 없다면 이는 주장일 뿐, 능력이 아닙니다. 조용한 주말에 비생산 환경에서 알고리즘을 끄고 무엇이 깨지는지 확인하십시오. 무언가가 깨질 것입니다. 강제 전환 상황보다 미리 발견하는 것이 좋습니다.

유용한 강제 요인은 인증서 수명입니다. 업계는 점점 짧은 수명의 인증서로 이동하고 있으며, 이는 수동 관리가 불가능해 자동화가 필수가 됨을 의미합니다. 인증서 발급·갱신을 제대로 자동화한다면 미래 알고리즘 전환에 필요한 대부분의 인프라를 이미 구축한 셈입니다.

AI는 사이버 방어와 공격자 모두에게 새로운 능력을 제공하고 있습니다. AI가 실제로 보안 방정식을 바꾸는 부분은 어디이며, 조직이 기술에 과도하게 집중하면서 기본적인 약점을 간과하고 있는 영역은 무엇이라고 보십니까?

AI는 한 가지를 확실히 바꾸었습니다. 그리고 저는 직접 경험했기에 이를 확신합니다.

올해 OpenSSL에 보고된 다수의 취약점은 AI 기반 분석으로 발견되었습니다. 1월에 12개의 이슈를 해결한 릴리즈를 배포했는데, 이는 한 연구 그룹이 자동화 분석을 통해 찾은 것이 전부였으며, 그들은 패치를 함께 제공했습니다. 6월에는 AI 시스템과 협업한 연구자가 발견한 PKCS#7 검증의 고심각도 use‑after‑free 버그를 수정했습니다. 이는 수년간 전문가가 검토한 성숙한 C 코드에서 메모리 안전성과 파싱 버그를 찾는 능력이 크게 향상된 사례입니다. 다른 암호 라이브러리에서도 동일한 패턴을 보았습니다. 올해 Bouncy Castle CVE들을 분석해 보면 자동 코드 분석의 흔적이 명확히 드러납니다.

명백한 함의는 이것이 양방향이라는 점입니다. 같은 기술이 원하는 사람에게 제공되며, 방어자는 독점적인 접근 권한이 없습니다.

덜 명백하지만 강조하고 싶은 점은 유지보수자에게 가해지는 부담입니다. 설득력 있는 취약점 보고서를 거의 무료로 생성할 수 있지만, 이를 검토하는 데는 인간 전문가의 실제 시간이 필요합니다. 오픈소스 보안 팀은 보통 규모가 작고 자원도 제한적인데, 품질이 다양한 보고서가 급증하고 있습니다. 좋은 보고서는 재현 방법과 패치를 제공하지만, 나쁜 보고서는 유지보수자를 향한 서비스 거부 공격에 가깝습니다. 조직이 오픈소스 코드에 AI를 적용한다면, 반대편의 검토 역량에 투자해야 합니다.

관심이 잘못된 곳은 다음과 같습니다: AI가 시스템을 패치해 주지는 않습니다. 자산을 인벤토리하거나, 자격 증명을 교체하거나, 지원이 종료된 하드웨어를 퇴역시키거나, 다음 달에 만료되는 인증서를 책임지는 사람을 지정해 주지도 않습니다. 알려진 취약점이 남아 있는 소프트웨어에 AI 보안 도구만 구매한다면 순서가 뒤바뀐 것입니다. 눈에 띄지 않는 작업이 실제 위험이 되는 부분입니다.

많은 조직이 도구에 막대한 투자를 하지만, 구성 실수, 구식 시스템, 약한 프로세스, 혹은 사고 대비 부족으로 여전히 취약합니다. 가장 큰 보안 실수는 무엇이며, 공격이 실제 발생하기 전에 리더십 팀이 갖추어야 할 것은 무엇입니까?

가장 큰 실수는 보안을 구매 활동으로 착각하는 것입니다. 도구를 구입하고, 예산을 맞추고, 대시보드는 초록색이며, 조직이 기본적인 보안 작업을 수행할 수 있는지 아무도 묻지 않습니다.

두 번째는 자신이 운영하는 것을 모르는 것입니다. 존재하지 않는 소프트웨어를 패치할 수 없으며, 대부분 조직은 사고가 발생했을 때 비로소 실제 자산 구성을 파악합니다. 이것이 부품 명세서 작업이 중요한 이유이며, 이는 규정 준수를 위한 문서가 아니라, 중요한 보안 권고가 발표될 때 새벽 2시에 찾아볼 수 있는 실제 도구입니다.

세 번째는 기본값입니다. 시스템을 설치하고 바로 사용하지만, 설정을 다시 검토하지 않습니다. 5년 후 그 기본값은 위험 요소가 되고, 초기 결정을 내린 사람은 이미 떠났습니다.

네 번째는 키와 인증서 관리가 개인에게 맡겨진다는 점입니다. 자체적으로 스프레드시트에 추적하던 만료 인증서가 갑자기 문제가 되는 경우가 많습니다.

사고 발생 전에 리더십은 네 가지를 갖추어야 합니다. 첫째, 비즈니스를 중단할 권한을 가진 지정된 의사결정자를 사전에 서면으로 지정해 두어야 합니다. 둘째, 외부 포렌식 및 전문 컨설팅과 이미 계약을 체결해 두어야 합니다. 이는 조달에 몇 주가 걸리기 때문에 사고 시 몇 시간 안에 활용할 수 있게 합니다. 셋째, 침해당한 시스템에 의존하지 않는 커뮤니케이션 채널을 확보해야 합니다. 넷째, 실제로 엔드‑투‑엔드 테스트된 복구 능력을 보유해야 합니다. 단순히 백업 작업이 성공했는지만 확인한 백업 체계는 충분하지 않습니다.

그 후에 연습을 해야 합니다. 연간 한 번 임원 수준의 테이블톱 연습을 하면 새로운 도구보다 실제 격차를 더 많이 발견할 수 있습니다.

심각한 사이버 공격이 발생하면 임원들은 기술, 법률, 운영, 커뮤니케이션 결정을 엄청난 압박 속에서 내려야 합니다. 효과적으로 대응하는 조직과 상황을 악화시키는 조직을 구분 짓는 핵심 요소는 무엇입니까?

잘 대응하는 조직은 사고 전에 중요한 결정을 미리 내려두었기 때문에, 사고 중에는 실행에 집중하고 논의에 시간을 쓰지 않습니다. 이것이 대부분의 차이점입니다.

준비 외에도 몇 가지 일관된 차이점이 있습니다.

그들은 기술 조사와 임원·커뮤니케이션 트랙을 명확히 구분하고, 두 트랙 사이에 정의된 인터페이스를 둡니다. 같은 사람이 침해를 차단하고 고객 통지를 작성한다면 두 작업 모두 형편없이 진행됩니다.

그들은 복구 전에 증거를 보존합니다. 침해된 머신을 즉시 재구축하려는 충동은 강력하지만, 이는 범위 파악에 필요한 정보를 파괴합니다. “그들이 또 무엇을 건드렸는가”에 답하지 못한다면 사고가 끝났다고 설득하기 어렵습니다.

그들은 초기 정보가 잠정적임을 인정하고 그에 맞게 소통합니다. 제가 관찰한 대부분의 평판 손실은 침해 자체보다 조기에 확신에 찬 발표를 철회해야 했던 경우에서 비롯되었습니다. “우리가 현재 알고 있는 내용, 아직 모르는 내용, 언제 업데이트할지”를 말하는 것이 약점이 아니라, 되돌릴 필요가 없는 유일한 입장입니다.

그리고 결정적으로, 엔지니어가 경영진에게 나쁜 소식을 전달할 수 있는 환경을 만듭니다. 가장 흔히 보이는 실패 패턴은 법적 노출이 명백함에도 불구하고 실제 상황을 기록한 사람을 내세우고 싶어 하지 않는 조직입니다. 그 결과 침해는 침묵 속에 악화됩니다. 엔지니어가 사고가 아닌 자신의 책임을 관리한다면, 도구만으로는 해결되지 않는 거버넌스 문제가 존재합니다.

OpenSSL은 기술 생태계 전반에 걸쳐 사용되는 중요한 오픈소스 인프라이며, OpenSSL Corporation은 상업 커뮤니티에 서비스를 제공하고 독립적으로 운영되는 OpenSSL Foundation과 함께 활동합니다. 보안 및 호환성에 관한 결정이 인터넷의 큰 부분에 영향을 미칠 때, 기업, 개발자, 규제기관, 그리고 광범위한 오픈소스 커뮤니티의 요구를 어떻게 균형 있게 다루십니까?

솔직히 말하면, 모든 사람을 매 결정마다 만족시키려는 방식으로 균형을 잡지는 않습니다. 우리는 공개된 정책을 가지고 일관되게 적용함으로써, 사람들이 결과에 불만이 있더라도 계획을 세울 수 있게 합니다.

예측 가능성은 사용자에게 우리가 빚진 약속입니다. 우리는 4월과 10월에 기능 릴리즈를 제공하고, 어느 릴리즈가 장기 안정 버전인지, 지원 종료 시점을 사전에 공지합니다. 주요 제거 사항은 릴리즈 전에 충분히 알리며, 4.0의 ENGINE 제거도 몇 달 전 공개하고 Corporation과 Foundation이 모두 동의했습니다. 4월에 놀란 사람은 사전에 주의를 기울이지 않은 것이며, 우리는 가능한 한 쉽게 주의를 환기시켰습니다.

구조적인 답변은 바로 이 분리 자체입니다. Foundation은 오픈소스 라이브러리와 그 커뮤니티를 지원하고, Corporation은 상업적 요구(지원 계약, FIPS 검증, 특정 일정 등)를 가진 조직을 지원하며, 전체 프로젝트를 재정적으로 지속 가능하게 합니다. 두 조직을 구분함으로써 어느 쪽의 요구도 조용히 다른 쪽을 위해 해결되지 않습니다. 기업 요구와 커뮤니티 요구가 실제로 충돌할 경우, 그 충돌은 명확한 임무를 가진 두 조직 사이에서 일어나며, 한 사람의 머리 속에서 일어나지 않습니다.

또 다른 부분은 제대로 된 청취입니다. 이는 가정이 아닌 실제 메커니즘을 필요로 합니다. 이것이 우리가 컨퍼런스를 운영하고, 이번 10월에 프라하에서 열며, 커뮤니티 인프라를 유지하는 이유입니다. 유지보수자가 사용자 요구를 추측하기는 쉽지만, 실제로 그들과 같은 방에 있는 것이 훨씬 유용합니다.

다음 10년을 바라볼 때, 조직이 아직 과소평가하고 있는 보안 또는 암호 전환은 무엇이며, SSL, OpenSSL, 그리고 지난 30년간 인터넷 보안의 진화에서 얻은 교훈을 리더들이 어떻게 적용해야 할까요?

제가 가장 과소평가된 전환이라고 생각하는 것은 포스트‑퀀텀 암호 자체가 아니라, 머신 아이덴티티와 그 아래의 인증서 계층 구조입니다.

포스트‑퀀텀 키 교환은 기본값으로 대부분 해결될 것이며, 이미 많은 부분이 구현되었습니다. 하지만 기본값으로 해결되지 않는 것은 신뢰 인프라입니다: 하드웨어에 내장된 루트 인증서, 펌웨어 서명 키, 수십 년 남은 서비스 수명을 가진 HSM, 2040년까지도 운용될 산업·의료 시스템 등은 라이브러리 버전만 교체해도 업데이트할 수 없습니다. 경우에 따라 전혀 업데이트가 불가능합니다. 이러한 교체 문제의 규모는 현재 어느 조직의 자본 계획에도 반영되지 않고 있습니다.

그와 함께 규제 전환도 진행 중입니다. 유럽의 사이버 복원력 법안(Cyber Resilience Act)과 유사한 프레임워크는 자신이 직접 작성하지 않은 구성 요소가 포함된 소프트웨어를 배포할 때 의무를 변경합니다. 대부분 조직은 오픈소스 의존성이 어떤 의미를 갖는지, 이를 유지보수하는 사람들에게 어떤 책임이 부과되는지를 아직 파악하지 못했습니다.

30년간의 교훈 세 가지:

1. 전환은 발표된 기간보다 10년 더 오래 걸린다. SSLv3는 2015년에 폐기 선언되었고, 2016년에 기본값으로 비활성화되었으며, 최종 코드는 2026년 4월에 제거되었습니다. 이는 11년이 걸린 사례이며, 모든 조직은 언론 발표가 아니라 실제 구현 기간을 기준으로 포스트‑퀀텀 마이그레이션을 계획해야 합니다.
2. 기본값은 규모에서 유일하게 작동하는 보안 제어이다. 모든 관리자가 올바른 결정을 내려야 하는 방안은 실행되지 않습니다. 하이브리드 포스트‑퀀텀 키 교환이 빠르게 배포된 이유는 기본값으로 켜져 있어 별도의 결정이 필요 없었기 때문입니다. 문서를 읽지 않을 사람들을 위해 설계하십시오. 이는 거의 모든 사람이 해당됩니다.
3. 당신이 생각하는 것보다 적은 사람에게 의존하고 있다. 전 세계 거의 모든 조직은 소수의 개인이 유지보수하는 암호 코드에 의존합니다. 이는 브리즈번의 우리 두 사람이었을 때도 사실이었으며, 이해관계가 수십 배 커져도 구조는 크게 변하지 않았습니다. 앞으로 수십 년을 계획하든, 그 일부는 절대 연락하지 않았고 자금을 지원하지도 않은 유지보수자에게 의존하고 있습니다. 이는 필요해지기 전에 알아두어야 할 중요한 사실입니다.

훌륭한 인터뷰에 감사드립니다. 더 알고 싶으신 독자는 OpenSSL을 방문하십시오.