Android IKEv2: 사용자 인증서와 CA는 서로 다른 역할을 한다

Android의 IKEv2 화면에서 사용자 인증서와 CA 인증서를 동시에 요구하면 같은 것을 두 번 요구하는 것처럼 보인다. 그렇지 않다. IKEv2는 한 번의 교환 안에서 양쪽을 양방향으로 인증하며, 기기는 방향마다 다른 역할을 맡는다. 자기가 누구인지 증명하는 일과 어느 게이트웨이를 믿을지 정하는 일이다. 사용자 인증서는 첫 질문에, 신뢰하는 CA는 두 번째 질문에 답하며 둘 중 어느 것도 다른 쪽을 대신하지 못한다.

한 번의 교환에 담긴 두 방향의 인증

IKEv2는 두 단계로 제어 채널을 만든다. 첫 단계는 알고리즘과 키를 협상하고, 두 번째인 IKE_AUTH는 각 측의 AUTH 페이로드를 그 신원과 함께 나른다. 이 페이로드는 교환 전체에 대한 서명이나 MAC이며, 수신자가 이미 신뢰하는 대상과 대조해 검증된다.

게이트웨이는 자기 인증서로 자신을 증명하고, 기기는 신뢰하는 루트까지 인증서 사슬을 검증한 뒤 인증서의 신원이 도달하려던 게이트웨이와 맞는지 확인한다. 기기는 자기 자격 증명으로 자신을 증명하고, 게이트웨이는 그것을 클라이언트 인증서를 발급한 CA와 대조한다.

두 필드 뒤에 있는 원리가 이것이다. 사용자 인증서는 기기가 자기 자신에 대해 하는 진술이고, CA 필드는 누구를 믿을지에 대한 진술이다. 하나만 있는 프로필은 상호 인증을 끝낼 수 없고, 다시 시도해도 달라지지 않는다. 실패 양상도 다르다. 사용자 키가 없으면 서명 자체를 만들 수 없고, 신뢰 앵커가 없으면 게이트웨이 인증서를 받아들일 수 없다.

Android 프로필 빌더가 요구하는 것

Android의 IKEv2 프로필 빌더는 인증 방식을 하나의 인증서 모드가 아니라 각각 따로 노출한다. 디지털 서명 방식은 사용자 인증서, 개인 키, 서버 루트 CA를 받는다. 다른 방식은 사용자 이름과 비밀번호, 또는 미리 공유한 키를 받는다.

그 서명을 주의 깊게 읽어야 한다. 위의 원리가 그대로 드러나기 때문이다. 사용자 이름과 비밀번호 방식에는 개인 키 필드가 없고, PSK 방식에는 게이트웨이 신뢰 앵커 필드가 없다. 증명하는 내용이 다르기 때문이다. 인증서 필드에 비밀번호를 붙여 넣으면 IKE_AUTH에서 실패하는 프로필이 만들어지고, 그 메시지는 둘 중 어느 것도 언급하지 않는다.

디지털 서명 방식에 문서화된 개인 키 유형은 RSA다. IPsec이나 인증서라고 적힌 메뉴가 ECDSA 지원을 뜻하지 않으며, 그 가정 위에 만든 프로필은 네트워크에 닿기도 전에 플랫폼 API에서 실패한다.

공개 사용자 인증서만으로 충분하지 않은 이유

AUTH 페이로드는 클라이언트 개인 키로 교환에 대해 만든 서명이다. 공개 인증서는 게이트웨이가 서명을 확인하게 해 주지만, 서명을 만들려면 키가 필요한 기기에는 아무것도 해 주지 않는다. .crt만 가져오고 키를 두고 오는 것이 이 실패의 가장 흔한 형태다.

Android의 키 기반 구조가 이를 보여 준다. 클라이언트 신원을 고르는 일은 KeyChain을 거치며, 여기에는 해당 개인 키에 대한 접근이 필요하다. 인증서 항목만으로는 부족하다. 등록 패키지나 기기 관리 흐름이 두 가지를 함께 설치하는 것이 정상적인 방법이고, 파일을 손으로 복사하는 일은 대개 그렇지 않다.

따라서 프로필의 두 항목은 인증서 묶음과 그 사본이 아니다. 하나는 플랫폼이 서명에 쓸 수 있어야 하는 키 쌍이고, 다른 하나는 비교 대상인 신뢰 앵커다. 두 가지 별개의 사실로 확인해야 한다. 이 프로필이 서명할 수 있는가, 그리고 누구를 믿어야 하는지 아는가.

신뢰 앵커는 앱의 것이지 기기의 것이 아니다

사용자 저장소에 루트를 설치해도 모든 Android 앱이 그것을 신뢰하지는 않는다. Android 7부터는 앱이 네트워크 보안 설정을 통해 스스로 선택해야 하며, 그 이전에는 사용자가 설치한 CA가 훨씬 넓게 받아들여졌다. 신뢰 설정은 앱마다 다를 수 있고, 자체 신뢰 자료를 관리하는 VPN 클라이언트는 사용자 저장소를 아예 보지 않을 수도 있다. 그래서 같은 CA 파일이 어떤 클라이언트에서는 동작하고 다른 곳에서는 무시된 것처럼 보인다.

여기서 두 가지 소유 모델이 나온다. 시스템이 관리하는 프로필은 기기의 인증서 설치나 관리자 등록을 사용하고 의도한 CA를 참조한다. 앱이 관리하는 VPN은 자체 신뢰 자료와 자체 문서화된 가져오기를 유지하며, 이는 Android 설정 화면과 완전히 별개일 수 있다. 끊어진 사슬을 고치는 곳도 거기다.

무엇을 가져오기 전에 어느 모델인지 정하고, 그다음 활성 프로필의 신뢰 선택을 확인한다. 운영자 지침과 클라이언트 메뉴가 다르면 그 설치에서는 클라이언트의 문서화된 동작이 우선하지만, CA는 검증 가능한 경로로 운영자에게서 와야 한다. 파일 이름은 누가 발급했는지의 증거가 아니다.

모드를 먼저, 파일은 그다음

인증서 모드에는 클라이언트 키 쌍, 게이트웨이 쪽의 발급 CA, 게이트웨이 인증서용 신뢰 앵커, 그리고 그 인증서가 담아야 할 신원에 대한 기대가 필요하다. 사용자 이름과 비밀번호는 키 쌍을 자격 증명으로 바꾸지만 게이트웨이 신뢰 요건은 그대로 둔다. PSK는 둘 다 공유 비밀로 바꾸고 신뢰 모델을 단순화하는 대신 바꿔 버린다.

무엇을 고르든 정상 검증은 켜 두어야 한다. 검증하지 않기 옵션은 CA 필드가 존재하는 이유인 확인을 없앨 뿐, 빠진 신뢰 앵커를 고치지 않는다. 연결이 그것 없이도 된다고 아무 서버 인증서나 받아들이는 것도 마찬가지다.

그다음 올바른 곳에서 확인한다. 자료를 가져오고 한 번 연결한 뒤, 연결 세부 정보에서 게이트웨이 신원이 기대한 것인지와 프로필이 의도한 방식을 보고하는지 확인한다. 잘못된 방식으로 성공한 연결은 아직 이해하지 못한 설정이며, 운영자가 정책을 강화하면 실패한다.