열쇠와 자물쇠 — 공개키는 왜 공개해도 안전한가

주소창의 작은 자물쇠

브라우저 주소창에 작은 자물쇠 그림이 떠 있습니다. 은행에 들어갈 때도, 메일을 열 때도, 물건값을 치를 때도 그 그림은 거기 있습니다. 그런데 이 그림의 뜻을 제대로 아는 사람은 많지 않습니다. 온라인 설문에 답한 1,880명 가운데 89%가 이 그림의 뜻을 잘못 알고 있었습니다 (DOI: 10.1109/spw54247.2022.9833869).

같은 설문에서 사이트를 믿어도 되는지 판단해 보라고 하자, 이 그림을 언급한 사람은 23~44%에 그쳤습니다. 그런데 그림을 눈여겨본 이 소수는, 가상의 쇼핑 상황에서 그림이 없으면 구매를 그만두겠다고 답했습니다 (DOI: 10.1109/spw54247.2022.9833869).

연구진의 결론은 이렇습니다. 자물쇠 그림은 연결의 보안을 보증하는데, 많은 사람은 그것을 그 사이트 전체가 안전하고 믿을 만하다는 표시로 읽습니다 (DOI: 10.1109/spw54247.2022.9833869). 연결의 보안은 내 브라우저와 그 사이트 사이를 오가는 내용을, 중간에서 누가 엿듣거나 바꾸거나 가짜로 꾸며 끼워 넣지 못하게 하는 것입니다 (DOI: 10.17487/rfc8446, 표준 문서). 자물쇠는 길이 안전하다는 표시이고, 길 끝의 가게가 정직하다는 표시는 아닙니다. 많은 사람이 하루에도 몇 번씩 그림 뒤의 장치를 쓰면서, 그 장치가 무엇을 약속하는지는 배울 기회가 없었습니다.

이 글은 세 물음을 따라갑니다. 잠그는 도구를 누구에게나 나눠 주고도 어떻게 안전한가. 그 안전은 무엇에 기대는가. 실제로는 어디서 무너지는가. 수식은 쓰지 않고, 큰 수 두 개를 곱하는 산수까지만 씁니다.

열쇠를 먼저 보내야 했던 문제

상자에 편지를 넣고 자물쇠를 채워 보낸다고 해 보겠습니다. 받는 사람이 상자를 열려면 같은 열쇠가 있어야 하니, 편지보다 열쇠가 먼저 가야 합니다. 대칭키 암호는 잠그는 열쇠와 여는 열쇠가 같은 암호입니다. 이 방식은 보내는 사람과 받는 사람이 같은 비밀 열쇠를 나눠 갖고 있어야 돌아갑니다 (DOI: 10.1017/cbo9780511780448.011, 단행본 장).

암호를 걸고 푸는 일 자체는 아주 오래됐습니다. 그런데 잠그는 열쇠를 아예 공개해 버리는 방식은 1970년대 후반에야 문헌에 나왔습니다 (DOI: 10.1017/cbo9780511780448.011, 단행본 장).

대칭키 암호에서는 열쇠를 미리 나눠 가져야 하니, 열쇠를 건네는 길도 안전해야 합니다. 1976년에 나온 한 논문이 바로 이 부담을 겨눴습니다. 그 논문은 두 가지를 해내는 새 암호가 필요하다고 봤습니다. 열쇠를 안전하게 건네는 통로가 필요한 일을 최소로 줄이는 것, 그리고 손으로 쓴 서명에 해당하는 것을 만드는 것입니다. 논문은 아직 풀리지 않은 이 문제들을 풀 길을 제안했습니다 (DOI: 10.1109/tit.1976.1055638).

답은 잠그는 도구와 여는 도구를 서로 다른 물건으로 만드는 것이었습니다. 공개키(public key)는 누구나 가져다 쓰라고 내놓는 열린 자물쇠입니다. 개인키(private key)는 주인만 갖고 어디로도 보내지 않는 열쇠입니다. 키 쌍(key pair)은 함께 만들어져 서로에게만 맞는 공개키와 개인키 한 벌입니다.

현관 앞에 열린 자물쇠를 한 바구니 담아 두고 가져가라고 써 붙였다고 해 보겠습니다. 나에게 편지를 보내려는 사람은 자물쇠 하나를 집어 상자를 잠급니다. 잠그는 일은 누구나 하고, 여는 일은 열쇠를 가진 나만 합니다. 바구니의 자물쇠가 공개키이고, 나만 가진 열쇠가 개인키입니다.

1978년에 이 생각을 실제로 돌아가게 만든 방식이 나왔습니다. 그 방식의 핵심 성질은 이렇습니다. 암호를 거는 키, 곧 공개키를 공개해도 그 짝인 암호를 푸는 키, 곧 개인키는 드러나지 않습니다 (DOI: 10.1145/359340.359342). 그래서 열쇠를 들고 갈 사람이 필요 없습니다. 보내는 사람은 받을 사람이 공개한 키로 잠그고, 짝이 되는 키를 아는 받을 사람만 풉니다 (DOI: 10.1145/359340.359342).

잠그는 도구와 여는 도구를 가르면, 열쇠를 미리 건네지 않고도 비밀을 주고받을 수 있습니다.

자물쇠를 뜯어 봐도 열쇠가 나오지 않는 이유

61 곱하기 53은 종이 한 장이면 나옵니다. 3,233입니다. 거꾸로 3,233이라는 값만 받아 들고 어떤 두 수를 곱한 것인지 찾으려면, 작은 수부터 하나씩 나눠 보는 것이 가장 단순한 방법입니다. 네 자리에서는 금방 끝납니다. 그러나 수가 아주 커지면 이 되짚기는 걷잡을 수 없이 어려워집니다.

일방향 계산(one-way function)은 한쪽으로는 누구나 금방 하는데 거꾸로 되돌리는 쪽은 터무니없이 힘든 계산입니다. 두 수를 곱하는 쪽이 쉬운 방향이고, 곱만 보고 두 수를 되찾는 쪽이 어려운 방향입니다. 오늘날의 암호는 이런 계산 위에 서 있습니다 (DOI: 10.1126/science.1074376).

공개키와 개인키는 이 두 방향에 나뉘어 놓입니다. 1978년 방식에서 주인은 큰 수 두 개를 골라 비밀로 간직하고, 그 두 수로 푸는 키를 만듭니다. 공개되는 키에는 두 수 자체가 아니라 두 수를 곱한 값이 들어갑니다 (DOI: 10.1145/359340.359342). 곱에서 원래의 두 수를 되찾아 내면 열쇠도 다시 만들 수 있지만, 그 되찾기가 바로 어려운 방향입니다. 자물쇠를 손에 쥐고 뜯어봐도 열쇠를 깎지 못하는 이유가 여기 있습니다.

곱을 원래의 두 수로 되돌려 나누는 일을 「인수로 가른다」고 합니다. 그 방식을 낸 논문은 자기 안전을 이렇게 적었습니다. 이 체계의 안전은 공개된 그 곱을 인수로 가르기 어렵다는 데 일부 기댄다 (DOI: 10.1145/359340.359342).

저자들은 「일부」라고 썼습니다. 다른 것에도 기댄다는 뜻인데, 그 나머지가 무엇인지는 초록에 적혀 있지 않습니다. 그리고 곱을 인수로 가르기 어렵다는 것 자체도 증명된 사실은 아닙니다. 흔히 쓰이는 일방향 계산은 증명되지 않은 추측에 기대거나, 이미 알려진 약점을 갖고 있습니다 (DOI: 10.1126/science.1074376).

이 자물쇠는 여는 값이 아직 아무도 치를 수 없을 만큼 비싸게 만들어졌을 뿐이고, 열 수 없다고 증명된 것은 아닙니다. 그 값이 싸지면 잠금도 함께 약해집니다.

같은 장치를 거꾸로 쓰면 서명이 됩니다

종이 계약서 끝에는 손으로 쓴 서명이 들어갑니다. 1976년의 제안이 만들고 싶어 한 두 번째 것이 바로 이 서명에 해당하는 것이었습니다 (DOI: 10.1109/tit.1976.1055638).

이번에는 열쇠와 자물쇠를 쥐는 순서를 바꿉니다. 주인이 자기 열쇠로 글에 표식을 붙입니다. 누구든 바구니의 자물쇠를 대 보아, 그 표식이 짝 열쇠에서 나왔는지 확인합니다. 이때 감춰지는 것은 없고, 누가 붙였는지가 드러납니다. 디지털 서명(digital signature)은 개인키를 쥔 사람만 만들 수 있고 그 짝인 공개키만 있으면 누구나 확인할 수 있는 표식입니다. 1978년 방식은 이 쓰임을 처음부터 함께 적었습니다. 비밀로 간직한 푸는 키, 곧 개인키로 글에 서명하면, 공개된 짝 키로 누구나 그 서명을 확인할 수 있습니다 (DOI: 10.1145/359340.359342).

미국 표준기관이 낸 디지털 서명 표준은 그 쓰임을 셋으로 적습니다. 첫째, 데이터가 허락 없이 바뀌었는지 잡아냅니다. 둘째, 서명한 사람이 누구인지 확인합니다. 셋째, 받은 사람이 그 서명을 「정말 그 사람이 서명했다」는 증거로 제3자에게 내밀 수 있게 합니다 (DOI: 10.6028/nist.fips.186-4, 표준 문서).

세 번째 쓰임에는 이름이 있습니다. 부인방지(non-repudiation)는 서명한 사람이 나중에 그 서명을 쉽게 부인할 수 없는 성질입니다. 표준이 쓴 낱말은 「쉽게」이고, 이 낱말은 부인이 어렵다는 데서 멈춥니다. 같은 자리를 1978년 논문은 더 세게 적었습니다. 서명은 위조될 수 없고, 서명한 사람은 나중에 그 서명을 부인할 수 없다는 것입니다 (DOI: 10.1145/359340.359342). 그런데 그 단정도, 안전이 곱을 인수로 가르기 어렵다는 데 「일부」 기댄다는 같은 논문의 조건 위에 서 있습니다.

서명도 자물쇠와 같은 계산 위에 서 있습니다. 흉내 내는 값이 아직 너무 비싼 만큼만 안전합니다.

그 자물쇠가 정말 그 사람 것인가

바구니에 누가 자기 자물쇠를 슬쩍 섞어 넣었다고 해 보겠습니다. 겉보기는 똑같습니다. 그 자물쇠로 잠근 상자는 섞어 넣은 사람에게 열립니다. 그는 편지를 읽고, 진짜 주인의 자물쇠로 다시 잠가 보냅니다. 양쪽 모두 눈치채지 못합니다.

중간자 공격(man-in-the-middle attack, MITM)은 가운데 낀 누군가가 양쪽 모두에게 상대방인 척하는 공격입니다. 자물쇠를 섞어 넣은 사람이 바로 이 가운데 낀 사람입니다. 중간자 공격은 컴퓨터 보안에서 가장 잘 알려진 공격 가운데 하나입니다. 이 공격은 양 끝 사이를 흐르는 데이터 자체를 노리고, 그 데이터의 비밀과 온전함, 곧 남이 못 보고 중간에 바뀌지 않았다는 점을 노립니다 (DOI: 10.1109/comst.2016.2548426, 서베이).

공개키가 덜어 준 것은 열쇠를 미리 건네는 부담입니다. 상대가 정말 그 사람인지 확인하는 부담은 그대로 남아 자리를 옮겼습니다. 자물쇠만 봐서는 누구 것인지 알 수 없으니, 자물쇠에 이름표를 달고 믿을 만한 제3자가 그 이름표에 서명합니다.

인증서(certificate)는 이 공개키가 이 사람의 것이라고 제3자가 서명해 준 문서입니다. 인증기관(certificate authority, CA)은 인증서에 자기 개인키로 서명해 그 공개키의 주인을 보증해 주는 곳입니다. 이름표의 서명이 진짜인지는 다시 그 인증기관의 공개키로 확인합니다.

이름표는 발급으로 끝나지 않습니다. 열쇠를 잃어버렸거나 도둑맞았다면 그 이름표가 계속 살아 있어서는 안 됩니다. 폐기(revocation)는 발급된 인증서를 만료 전에 무효로 돌리는 일입니다.

이 틀에는 약한 곳도 생겼습니다. 브라우저가 믿는 인증기관의 수는 불어났고, 브라우저가 믿으면 사용자도 사실상 따라 믿게 됩니다. 그런데 인증서를 발급할 때 하는 기본적인 확인은 오히려 줄었습니다 (DOI: 10.1109/sp.2013.41, 2013년 정리). 브라우저가 믿는 인증기관은 대개 어느 사이트의 이름표에든 서명할 수 있어서, 믿는 곳이 늘수록 한 곳의 허술함이 전체의 틈이 됩니다. 보안 웹 연결과 그 인증서 신뢰 틀을 겨눈 공격은 여럿 제기되고, 실제로 실행되고, 진화해 왔습니다. 이 틀을 보강하려는 제안들도 나와 서로 견주어 평가됐습니다 (DOI: 10.1109/sp.2013.41).

누구의 자물쇠인지 확인하는 일은 이름표와 그 이름표에 서명하는 곳으로 옮겨 갔고, 공격도 그 틀을 겨눠 왔습니다.

수학 바깥에서 무너진 자리들

첫 번째 무너짐은 열쇠가 새는 것입니다. 키 유출(key compromise)은 어디로도 보내지 않기로 한 개인키가 주인 아닌 사람 손에 들어가는 일입니다. 열쇠를 가진 사람에게 자물쇠의 튼튼함은 상관이 없습니다. 수학은 틀린 데가 없는데 상자가 열립니다.

열쇠는 생각보다 자주 샙니다. 개발자들은 누구나 볼 수 있는 공개 저장소에 코드를 올려 함께 고칩니다. 이때 개인키 파일이나, 서비스에 접속할 때 쓰는 비밀 값(API 키)을 코드에 넣은 채 올리는 일이 흔합니다 (DOI: 10.14722/ndss.2019.23418). 개인키 파일과 11개 서비스의 API 키를 찾아보니, 둘을 합쳐 10만 곳이 넘는 저장소에서 이런 비밀이 새고 있었습니다. 새 비밀도 날마다 수천 개씩 새어 나오고 있었습니다 (DOI: 10.14722/ndss.2019.23418). 올라오는 코드를 여섯 달 가까이 실시간으로 훑고, 오픈소스 저장소의 13%를 담은 공개 자료를 함께 뒤진 결과입니다. 저자들은 이런 유출이 만연해 있고 풀린 문제와는 거리가 멀다고 결론짓습니다.

서명도 마찬가지입니다. 프로그램을 만든 회사는 자기 프로그램에 디지털 서명을 붙이고, 이것을 코드 서명이라고 부릅니다. 서명된 악성코드는 유효한 서명이 있는 프로그램만 설치하고 실행하는 보호 장치를 통과할 수 있습니다. 백신도 서명된 프로그램은 검사를 건너뛰는 일이 잦습니다 (DOI: 10.1145/3133956.3133958). 연구진은 코드 서명 체계의 약점을 세 유형으로 나눴고, 위협의 예로 둘을 듭니다. 하나는 멀쩡한 인증서에 딸린 개인키를 훔쳐 악성코드에 서명하는 경우입니다. 다른 하나는 소프트웨어를 만들지 않아 서명용 인증서가 없는 실제 회사를 사칭하는 경우입니다. 연구진은 이 생태계를 고칠 구체적인 단계도 함께 제안합니다.

열쇠는 쓰는 동안 컴퓨터 메모리에 올라가 있습니다. 대부분의 컴퓨터가 쓰는 주메모리는 전원이 끊긴 뒤에도 몇 초 동안 내용을 간직합니다. 널리 퍼진 짐작과 반대였고, 상온에서도, 기판에서 뽑아낸 뒤에도 그랬습니다 (DOI: 10.1145/1506409.1506429, 2009년 실험). 그 사이에 메모리 내용을 통째로 떠 내면, 그 안에서 열쇠를 찾아낼 수 있습니다 (DOI: 10.1145/1506409.1506429). 그래서 기계를 손에 넣은 사람 앞에서는, 운영체제가 열쇠를 지켜 주는 데 한계가 있습니다. 연구진은 저장장치 전체를 잠가 두는 디스크 암호화 제품 여럿이 특별한 장비 없이 뚫릴 수 있음을 실제로 보였습니다. 위험을 줄이는 방법 몇 가지를 논의하면서도, 이 위험을 없앨 간단한 해결책은 아는 한 없다고 적었습니다.

암호를 코드로 옮기는 개발자들은 대개 이미 만들어진 암호 도구 묶음을 가져다 씁니다. 도구를 단순하게 만들면 도움이 되지만, 그것만으로는 모자랍니다 (DOI: 10.1109/sp.2017.52). 단순한 도구는 고를 것을 줄여, 안전하지 않은 설정을 덜 고르게 했습니다. 그러나 문서가 부실하고, 예제가 없고, 키를 안전하게 보관하는 기능이 빠지면, 단순한 도구를 받은 참가자도 헤맸습니다. 제대로 돌아가는 코드를 짜는 데서도, 안전한 코드를 짜는 데서도 그랬습니다. 깃허브에서 모은 파이썬 개발자 256명에게 다섯 가지 도구 묶음 가운데 하나를 주고, 흔한 암호 작업을 시킨 통제 실험의 결과입니다.

문서와 예제가 메워 준 것은 돌아가는 쪽뿐이었습니다. 충실한 문서와 쉬운 예제는 복잡한 도구의 불리함을 기능 면에서는 메워 주는 것으로 보였지만, 안전 면에서는 그렇지 못했습니다. 도구 묶음을 가리지 않고, 기능적으로 맞게 짠 과제의 약 20%에서 참가자들은 자기 코드가 안전하다고 믿었지만 안전하지 않았습니다. 저자들이 특히 우려스럽다고 적은 대목입니다. 코드가 돌아가는 것과 안전한 것은 다른 일이고, 짠 사람도 그 차이를 알아채지 못했습니다. 저자들의 처방은 두 가지입니다. 단순하고 편한 사용법을 갖추는 것, 그리고 어쩌면 그보다 더 중요하게, 흔한 작업을 폭넓게 지원하고 안전하고 쓰기 쉬운 예제를 담은 문서를 갖추는 것입니다 (DOI: 10.1109/sp.2017.52).

마지막은 화면 앞의 사람입니다. 브라우저는 사이트의 신원을 확인하지 못하면, 인증서가 유효하지 않다는 경고를 띄웁니다. 이런 경고는 해가 없는 상황에서 뜨는 일이 많지만, 중간자 공격의 신호일 수도 있습니다 (DOI: 10.1184/r1/6621806). 경고를 더 잘 만들어도 위험한 쪽을 고르는 사람이 너무 많았습니다. 새로 설계한 경고 두 가지는 널리 쓰이는 브라우저 세 곳의 경고보다 유의하게 나았지만, 모든 경고 조건에서 너무 많은 참가자가 위험한 행동을 했습니다 (DOI: 10.1184/r1/6621806). 400명이 넘는 사용자 설문을 바탕으로 새 경고를 설계하고, 참가자 100명의 실험실 실험으로 견준 결과입니다. 연구진은 경고를 고칠 수는 있지만, 안전하지 않은 연결은 아예 막고 해가 없는 상황의 경고는 없애 경고 자체를 줄이는 쪽이 더 나을 수 있다고 봅니다.

여기 모은 무너짐은 열쇠를 두는 곳, 서명과 이름표를 믿는 방식, 코드를 짜는 사람, 경고 앞의 사람에게서 났습니다. 수학이 틀려서 무너진 자리는 이 목록에 없습니다. 다만 이 목록은 고른 사례이고, 사고를 세어 본 결과는 아닙니다. 수학 쪽에도 앞에서 본 대로 증명되지 않은 추측과 이미 알려진 약점이 있습니다 (DOI: 10.1126/science.1074376). 그리고 곱을 되짚는 값을 싸게 만들 수 있는 기계로 양자컴퓨터가 꼽힙니다.

값이 싸지는 날, 그리고 오늘

양자컴퓨터는 아주 작은 입자의 물리 법칙을 계산에 쓰는 새로운 종류의 컴퓨터입니다. 큰 규모의 양자컴퓨터가 만들어진다면, 곱을 인수로 가르는 문제와 그와 같은 계열의 문제를 풀 수 있게 됩니다. 수가 커져도 계산량이 걷잡을 수 없이 불어나지 않는 방식으로 풉니다 (DOI: 10.14722/ndss.2020.24203). 앞에서 본 어려운 방향이 쉬워진다는 뜻입니다. 그러면 지금 쓰이는 모든 공개키 방식은 양자컴퓨터 이후의 환경에서 안전하지 않다고 여겨지게 됩니다 (DOI: 10.14722/ndss.2020.24203). 그런 컴퓨터는 아직 가능성이고, 그 가능성이 보안 연구자들의 걱정거리가 되어 있습니다.

그 자리를 메우는 작업은 이미 움직이고 있습니다. 2020년 기준으로 미국 표준기관은 양자컴퓨터에 견디는 암호를 표준으로 정하는 절차를 시작한 상태였습니다 (DOI: 10.14722/ndss.2020.24203). 후보 서명 방식들을 실제 네트워크 조건에서 잰 2020년의 한 성능 연구는, 적어도 두 가지가 지금 쓰는 서명 방식에 비해 추가 부담이 거의 없이 채택할 만하다고 결론지었습니다 (DOI: 10.14722/ndss.2020.24203).

그리고 이 장치는 지금 작동하고 있습니다. 1978년의 방식은 공개키 암호 가운데 가장 널리 쓰이는 방식의 하나입니다 (DOI: 10.1109/access.2021.3129224). SSL은 브라우저와 사이트 사이의 연결을 암호로 지키는 규약이고, 주소창의 자물쇠 그림이 가리키는 연결의 보안을 맡습니다. 지금 쓰이는 후속 규약은 TLS라고 부릅니다. 2012년에 SSL은 안전한 인터넷 통신의 사실상 표준이었고, 끼어드는 공격자에 맞선 안전을 공개키 인증서를 올바르게 확인하는 데 기댔습니다 (DOI: 10.1145/2382196.2382204).

이 장치는 오늘도 널리 쓰이고 있고, 그 안전은 아직 아무도 치를 수 없는 계산 값에 기대고 있으며, 그 값이 계속 비쌀 것이라는 점은 증명되지 않았습니다. 널리 쓰인다는 것과 증명되지 않았다는 것은 함께 참입니다.

은행 사이트를 여는 몇 초

이제 주소창에 은행 주소를 치고 들어가는 몇 초를 따라가 보겠습니다.

브라우저가 은행 서버와 연결을 맺기 시작하면, 은행은 인증서를 내밉니다. 그 안에는 은행이 바구니에 내놓은 자물쇠, 곧 은행의 공개키가 있습니다. 이 자물쇠가 이 은행의 것이라는 이름표도 있고, 그 이름표에 인증기관이 한 서명도 있습니다. 브라우저는 그 서명을 인증기관의 공개키로 확인합니다.

끼어드는 공격자에 맞선 이 연결의 안전은 바로 이 순간 내민 인증서를 올바르게 확인하는 데 달려 있습니다 (DOI: 10.1145/2382196.2382204). 확인이 빠지거나 틀리면, 바구니에 섞여 든 남의 자물쇠를 은행 것으로 받아들이게 됩니다. 확인하지 못하면 경고가 뜹니다 (DOI: 10.1184/r1/6621806). 앞의 실험실 실험에서는 새로 설계한 경고를 받은 조건까지 포함해, 모든 조건에서 너무 많은 참가자가 위험한 쪽을 골랐습니다. 그리고 이런 경고는 해가 없는 상황에서도 자주 뜹니다.

주소창의 자물쇠 그림은 이 연결이 보안 연결이라는 표시입니다 (DOI: 10.1109/spw54247.2022.9833869). 이 연결을 맺고 지키는 규약인 TLS는, 처음에 본 엿듣기와 바꾸기와 가짜 끼워 넣기, 곧 도청과 변조와 위조를 막도록 설계돼 있습니다 (DOI: 10.17487/rfc8446, 표준 문서). 신뢰를 판단할 때 자물쇠를 눈여겨보던 그 소수의 응답자들은, 자물쇠를 누르면 열리는 보조 화면에서 연결의 보안을 더 자세히 읽은 뒤 안심했습니다. 연구진은 연결의 보안을 정확하고 분명하게 전하는 일은 작은 그림보다 그런 보조 화면에서 더 효과적일 것이라고 봅니다 (DOI: 10.1109/spw54247.2022.9833869).

이 몇 초 동안 확인되지 않는 것이 셋 있습니다. 은행의 개인키가 지금도 은행에만 있는지, 이름표에 서명한 인증기관이 발급할 때 제대로 확인했는지, 자물쇠에서 열쇠를 되짚는 값이 여전히 비싼지입니다. 자물쇠 그림이 표시하는 연결의 보안은 이 셋 위에 서 있습니다. 열쇠가 새면 수학이 멀쩡해도 상자가 열립니다. 도둑맞은 열쇠의 이름표는, 누군가 도둑맞은 것을 알아차려야 폐기할 수 있습니다. 2013년 정리대로 인증서를 발급할 때 하는 확인은 줄어 왔고, 되짚는 값이 계속 비쌀 것이라는 점은 증명되지 않았습니다. 그리고 그 사이트가 정직한 곳인지는 그림이 처음부터 말하지 않습니다 (DOI: 10.1109/spw54247.2022.9833869).

그래서 물음 하나가 남습니다. 이름표를 발급한 곳은 누가 지키는가. 이 물음의 답은 하나가 아닙니다. 인증서 신뢰 틀을 보강하려는 제안이 여럿 나와 있습니다 (DOI: 10.1109/sp.2013.41). 모든 발급을 누구나 볼 수 있는 기록에 적게 하는 길은 「주소창의 자물쇠는 무엇을 보증하나」가 다루고, 이 시리즈의 다음 편 「블록체인이란 무엇인가」는 여럿이 함께 지키는 기록이라는 또 다른 생각을 다룹니다.

어디를 더 볼까

이름표를 발급한 곳을 지키는 한 가지 방법은 주소창의 자물쇠는 무엇을 보증하나 — '믿을 기관'을 고르는 대신, 모든 발급을 공개 장부에 적기로 한 웹이 다룹니다. 모든 발급을 누구나 볼 수 있는 기록에 적게 한 결정입니다.

되짚는 값이 싸지는 쪽이 궁금하다면 양자컴퓨터가 오면 암호는 정말 다 깨지나 — '전부'와 '나중'이라는 두 개의 오해로 갑니다. 이 글이 「그 값이 싸지면 잠금도 함께 약해진다」고만 적고 지나간 자리를 그 편이 맡습니다.

비밀을 건네지 않고 비밀을 안다는 사실만 보이는 장치는 영지식 증명 — 정보를 공개하지 않고 참임을 증명하는 법에 있습니다.

이 글은 두 사람 사이의 확인만 봤습니다. 여럿이 하나의 기록에 동의하는 문제는 신뢰 없이 합의하기 — 서로 못 믿는 참여자들이 하나의 장부에 동의하는 법이 다룹니다.

근거 논문

• ""It builds trust with the customers" - Exploring User Perceptions of the Padlock Icon in Browser UI" (2022) — DOI: 10.1109/spw54247.2022.9833869 — 1,880명 온라인 설문. 89%가 자물쇠의 뜻을 오해. 신뢰도 판단 때 자물쇠를 언급한 사람은 23~44%인데 그들은 자물쇠가 없으면 가상의 구매를 그만두겠다고 답했다. 아이콘은 연결 보안을 보증하나 사이트 전반의 신뢰로 읽힌다. 자세한 2차 화면이 더 효과적일 것.
• "Boolean Functions for Cryptography and Error-Correcting Codes" (2010, 단행본 장) — DOI: 10.1017/cbo9780511780448.011 — 암호화 키가 비밀이면 대칭 암호(송수신자의 비밀키 공유에 의존), 공개면 공개키 암호. 공개키 암호는 1970년대 후반 문헌에 등장.
• "New directions in cryptography" (1976) — DOI: 10.1109/tit.1976.1055638 — 안전한 키 배달 통로의 필요를 최소화하고 손으로 쓴 서명에 해당하는 것을 공급하는 새 암호 체계를 제안.
• "A method for obtaining digital signatures and public-key cryptosystems" (1978) — DOI: 10.1145/359340.359342 — 암호화 키를 공개해도 복호화 키가 드러나지 않는다. 배달 불필요, 서명과 공개키 검증, 위조·부인 불가를 주장. 안전은 공개된 곱의 인수분해 어려움에 "일부" 기댄다.
• "Physical One-Way Functions" (2002) — DOI: 10.1126/science.1074376 — 현대 암호는 일방향 함수 위에 서지만, 흔히 쓰는 것들은 증명되지 않은 추측에 기대거나 알려진 약점이 있다. 대안으로 물리적 일방향 함수.
• "Digital signature standard (DSS)" (2013, 표준 문서) — DOI: 10.6028/nist.fips.186-4 — 서명의 쓰임(무단 변경 탐지·서명자 신원 확인·제3자 증거)과 부인방지. 서명자가 나중에 "쉽게" 부인할 수 없다.
• "A Survey of Man In The Middle Attacks" (2016, 서베이) — DOI: 10.1109/comst.2016.2548426 — 중간자 공격은 가장 잘 알려진 공격의 하나로, 끝점 사이를 흐르는 데이터의 비밀성과 무결성을 겨냥. 분류와 방지 장치 정리.
• "SoK: SSL and HTTPS: Revisiting Past Challenges and Evaluating Certificate Trust Model Enhancements" (2013) — DOI: 10.1109/sp.2013.41 — 브라우저가 신뢰하는 인증기관 수는 늘고 발급 시 기본 주의 의무는 떨어졌다. 인증서 신뢰 모형 개선안 비교 평가.
• "How Bad Can It Git? Characterizing Secret Leakage in Public GitHub Repositories" (2019) — DOI: 10.14722/ndss.2019.23418 — 약 6개월 실시간 스캔 + 저장소 13% 스냅샷. 10만 개가 넘는 저장소가 영향, 매일 수천 개의 새 비밀이 유출. 만연하고 풀리지 않은 문제.
• "Certified Malware" (2017) — DOI: 10.1145/3133956.3133958 — 서명된 악성코드가 보호 장치와 백신을 통과한다. 코드 서명 체계의 약점 세 유형(개인키 절도·회사 사칭 등). 개선 단계 제안.
• "Lest we remember" (2009) — DOI: 10.1145/1506409.1506429 — 주메모리는 전원이 끊겨도 몇 초간 내용을 유지. 물리 접근 공격자로부터 키를 지키는 능력을 제한하고, 여러 디스크 암호화 제품이 뚫렸다. 없앨 간단한 해결책은 없다.
• "Comparing the Usability of Cryptographic APIs" (2017) — DOI: 10.1109/sp.2017.52 — 개발자 256명·5개 라이브러리 통제 실험. 단순함은 이득이나 충분하지 않고, 문서의 벌충은 보안 결과로 이어지지 않았다. 맞게 짠 과제의 약 20%에서 안전하다고 오신. 처방은 단순한 인터페이스 + 흔한 작업의 폭넓은 지원 + 안전하고 쓰기 쉬운 예제가 담긴 문서.
• "Crying Wolf: An Empirical Study of SSL Warning Effectiveness" (2018) — DOI: 10.1184/r1/6621806 — 400명 설문 + 100명 실험. 새 경고가 유의하게 나았으나 모든 조건에서 너무 많은 참가자가 위험하게 행동. 경고 자체를 줄이는 쪽을 제안.
• "Post-Quantum Authentication in TLS 1.3: A Performance Study" (2020) — DOI: 10.14722/ndss.2020.24203 — 대규모 양자컴퓨터가 나오면 현행 공개키 알고리즘 전부가 안전하지 않게 여겨진다. NIST 표준화 절차 시작. 후보 서명 중 적어도 둘은 추가 부담 거의 없이 채택 가능.
• "Systematic and Critical Review of RSA Based Public Key Cryptographic Schemes: Past and Present Status" (2021) — DOI: 10.1109/access.2021.3129224 — RSA는 공개키 암호 중 가장 널리 쓰이고 적용되는 알고리즘의 하나("one of the most"). 11개 범주로 분류한 체계적 리뷰.
• "The most dangerous code in the world" (2012) — DOI: 10.1145/2382196.2382204 — SSL은 안전한 인터넷 통신의 사실상 표준이고, 활성 공격자에 대한 안전은 연결 수립 때 제시된 공개키 인증서를 올바르게 검증하는 데 달려 있다.
• "The Transport Layer Security (TLS) Protocol Version 1.3" (2018, 표준 문서) — DOI: 10.17487/rfc8446 — 도청·변조·위조를 막도록 설계된 통신을 하게 해 주는 프로토콜 규격.