Android에서 VPN 인증서를 가져오고 키를 검증하는 방법

Android에서 VPN 클라이언트 인증서를 가져오는 데는 몇 분이 걸립니다. 올바른 위치에 들어갔는지 확인하는 데는 더 오래 걸리며, 설치 대화상자가 성공이라고 말한 뒤 대부분의 사람이 생략하는 부분이 바로 그것입니다. 성공 메시지는 파일이 분석되었다는 뜻일 뿐입니다. 개인 키를 어느 공급자가 보관하는지, 다운로드 폴더에 아직 사본이 남아 있는지는 알려주지 않습니다.

1단계: P12를 머신에서 내보내기 전에 읽기

파일 자체에서 시작하십시오. 그 안의 주체, 발급자, 만료일을 말할 수 없다면 나중에 검증할 수 없는 것을 가져오는 셈입니다.

PKCS#12 번들은 보통 클라이언트 인증서, 그 개인 키, 발급자 체인을 담습니다. openssl pkcs12 -in client.p12 -info -noout은(는) 키 자료를 쏟아내지 않고 MAC과 암호화 알고리즘을 출력하므로 번들이 비밀번호로 보호되어 있는지, 어떤 암호를 쓰는지 알 수 있습니다. 이어서 keytool -list -v -keystore client.p12 -storetype PKCS12을(를) 실행하면 별칭, SHA-256 지문, 휴대폰과 비교할 유효 기간을 얻습니다.

비밀번호는 파일과 다른 경로로 보내고, 파일은 사본을 남기지 않는 관리된 배포 흐름 안에서 넘기십시오. 아카이브와 같은 채팅 메시지에 비밀번호를 붙여 넣으면 두 개의 통제가 하나가 됩니다.

2단계: VPN 앱이 실제로 읽는 슬롯에 설치하기

기본 Android 11부터 14까지 경로는 설정, 보안, 암호화 및 사용자 인증 정보, 인증서 설치, 이어서 VPN과 앱 사용자 인증서로 이어집니다. 문구와 중첩은 릴리스와 제조사 스킨에 따라 달라지므로 외운 메뉴 위치가 아니라 사용자 인증 정보 유형 라벨을 따라가십시오. 작업 프로필에서는 인증 정보가 프로필 경계를 넘지 않으므로 업무 쪽 안쪽에서 설치하십시오.

클라이언트 ID를 CA 인증서 슬롯에 넣지 마십시오. 그 슬롯은 사용자 신뢰 저장소에 공급되며, Android 7부터 앱은 네트워크 보안 구성이 허용하지 않는 한 사용자가 추가한 CA를 무시하므로 거기에 둔 클라이언트 인증서는 VPN 키 선택기에 절대 나타나지 않습니다.

일부 VPN 클라이언트는 시스템 저장소를 전혀 건드리지 않고 P12를 자체 앱 디렉터리로 가져옵니다. 합법적인 설계이지만 이후 모든 단계가 달라집니다. 키는 이제 앱 샌드박스 아래에 살고, 그 앱이 자체 저장소를 다루는 만큼만 강하므로 KeyChain이 개입한다고 가정하기 전에 클라이언트 문서를 확인하십시오.

3단계: 어느 공급자가 키를 보관하는지 증명하기

가져오기는 분석을 확인할 뿐 하드웨어 보호를 확인하지 않습니다. Android 12부터 KeyInfo.getSecurityLevel()은(는) 키가 신뢰 실행 환경에 있는지, StrongBox에 있는지, 소프트웨어에 있는지 보고하며 오래된 isInsideSecureHardware() 호출을 대체합니다. VPN 클라이언트가 그 값을 표시하지 않으면 1단계의 지문이 대안입니다. 가져오는 과정에서 다시 인코딩된 인증서는 바이트 단위로 일치하지 않지만 공개 키와 주체는 여전히 일치합니다.

내보낼 수 없다는 것이 쓸 수 없다는 뜻은 아닙니다. 기기를 떠날 수 없는 키도 사용자가 해당 별칭 선택을 허용한 앱이면 사용할 수 있으며, 그래서 별칭 프롬프트는 형식이 아니라 실제 통제입니다. Android Keystore 문서는 그런 설계 결정을 한다면 한 번 읽어 볼 가치가 있습니다.

그다음 만든 사본을 따져 보십시오. 노트북의 P12, 티켓 첨부의 사본, 지난달 백업의 사본은 발급자가 폐기할 때까지 모두 유효한 신원입니다. 휴대폰 인스턴스의 하드웨어 보호는 그것들에는 아무것도 해 주지 않습니다.

4단계: 화면 잠금 요구 사항의 주인이 누구인지 찾기

여기서는 기기 잠금 해제 PIN, 개인 키 암호 문구, VPN 계정 비밀번호라는 세 가지 비밀이 뒤섞입니다. 하나에 대한 프롬프트는 다른 것을 재설정하라는 요청이 아니며, 잘못된 것을 재설정하는 것이 잘 작동하던 프로필에서 스스로를 잠그는 방식입니다.

기기 관리자나 관리 프로필 정책이 잠금을 요구하면 그 요구는 인증서가 아니라 그 정책에 속합니다. adb shell dumpsys device_policy은(는) 활성 관리자와 그들이 강제하는 비밀번호 품질을 나열하며, PIN 규칙이 바뀐 이유가 MDM 에이전트인지 가장 빠르게 확인하는 방법입니다. 인증서를 제거해도 정책은 완화되지 않으며, 정책을 제거하는 것은 설정 조정이 아니라 관리 결정입니다.

사용성 절충도 예상하십시오. 키가 사용자 승인을 요구하면 첫 잠금 해제 전에는 터널이 올라올 수 없으므로 예약된 동기화와 원격 깨우기가 설계상 실패합니다. 배포 전에 결정하십시오, 나중이 아니라.

locksettings.db을(를) 편집하거나 잊어버린 패턴의 옛 우회 방법을 다시 실행하는 지름길을 피하십시오. 그 루틴은 특정 빌드용으로 작성되었고, 프레임워크가 더 이상 기대하지 않는 상태로 인증 정보 저장소를 남길 수 있으며, 처음에 잠금을 요구한 정책을 결코 바꾸지 않습니다.

5단계: 신원을 폐기하고 거부를 검증하기

폐기에는 세 부분이 있고 첫 번째만 로컬입니다. VPN 프로필을 제거하고, 설정, 보안, 암호화 및 사용자 인증 정보, 사용자 인증 정보에서 사용자 인증서를 삭제한 다음 발급자에게 인증서 일련번호를 폐기하도록 요청하십시오. 로컬 삭제만으로는 누군가 P12를 보관했다면 서버가 여전히 받아들이는 인증 정보가 남습니다.

가정하지 말고 결과를 검증하십시오. 폐기한 프로필로 연결을 시도하고 서버가 거부하는지 확인하십시오. 그래도 터널이 올라오면 잘못된 일련번호를 폐기했거나 클라이언트가 조용히 다른 설치된 신원으로 넘어간 것입니다.

실패한 가져오기를 되돌리는 경우, 디스크에 남겨 둔 복호화된 키 파일을 재사용하지 말고 원래 암호화된 번들에서 다시 가져와 지문을 다시 확인하십시오.