IPsec 사전 공유 키: 입력한 문자열 뒤의 바이트

두 관리자가 화면의 시크릿을 비교하고 일치한다는 데 동의하지만 터널은 여전히 인증에 실패합니다. 그들이 비교한 문자열은 어느 쪽 끝에서도 키 유도에 입력하는 값이 아닙니다. 보이는 문자와 프로토콜이 해시하는 바이트 사이에는 필드 유형, 텍스트 인코딩, 편집기, 클립보드가 있으며 네 가지 중 어느 것이든 겉모습을 바꾸지 않고 입력을 바꿀 수 있습니다. 바이트를 비교하면 불일치는 보통 몇 초 안에 드러납니다.

게이트웨이가 문자열로 하는 일

사전 공유 키는 네트워크로 전송되어 비교되지 않습니다. 각 끝은 로컬 사본을 IKE 교환의 키 유도에 입력하고, 그 결과로 생긴 인증 페이로드가 검증되거나 되지 않습니다. 이 설계는 두 사본이 시각적으로 비슷한 것이 아니라 바이트 단위로 동일해야 함을 의미하며, 실패가 잘못된 비밀번호 메시지가 아니라 인증 단계에서 보고된다는 것도 의미합니다.

따라서 유용한 질문은 «이것들이 같아 보이는가»가 아니라 «각 구현이 해시하는 정확한 바이트 순서는 무엇인가»입니다.

추가 바이트는 어디에서 오는가

끝의 줄바꿈이 고전적인 원인이며, 대부분의 편집기가 파일을 저장할 때 보이지 않게 하나를 추가하기 때문에 눈앞에 숨어 있습니다. 채팅 창에서 붙여넣은 앞이나 뒤의 공백도 같은 일을 하고, 워드 프로세서가 곧은 따옴표를 스마트 따옴표로 바꾼 경우도 마찬가지입니다. 그중 어느 것도 사람이 하는 시각적 비교를 바꾸지 않습니다.

글리프가 아니라 바이트를 보여 주는 도구로 비교하십시오. printf '%s' "$PSK" | xxd | tail -2 는 값의 끝을 십육진수로 인쇄하며, 여기서 잘못 들어간 0a 또는 20 가 분명히 보입니다. 양쪽 끝에서 실행하고 두 덤프를 나란히 비교하십시오. 나중에 셸 기록에 남길 운영 시크릿이 아니라 생성된 테스트 자료에서 하십시오.

인코딩은 암호화가 아니다

구성 내보내기는 종종 시크릿을 기본 인코딩으로 운반하며, 때로는 예순 또는 일흔여섯 문자마다 줄바꿈이 있고 때로는 패딩이 있습니다. 한쪽 끝이 디코딩된 바이트를 기대하는데 인코딩된 텍스트를 붙여넣으면 다른 비밀번호를 보낸 것이 아니라 인쇄 가능한 문자로 만든 훨씬 긴 비밀번호를 보낸 것입니다. Base64는 어떠한 기밀성도 제공하지 않으므로 인코딩된 시크릿을 두 번째 의견을 위해 포럼에 붙여넣어서는 안 됩니다.

Apple의 IPSec 사전은 L2TP 및 Cisco IPsec 페이로드의 공유 시크릿 인증 방법에 대한 데이터로 SharedSecret 를 문서화한, 유형이 중요하다는 유용한 예입니다. 그것은 특정 페이로드의 특정 속성이며, 우연히 시크릿을 요구하는 다른 프로토콜에 재사용할 수 있는 일반 텍스트 필드가 아닙니다.

주장된 한도는 하나의 조합에 속한다

한 Apple 클라이언트의 서른두 문자 상한에 대한 오래된 보고서는 하나의 클라이언트 버전, 프로토콜, 프로필 형태에 대한 실제 보고서입니다. 모든 Apple 플랫폼, 모든 공급자, 모든 프로토콜에 대한 보편적 한도가 아닙니다. 버전, 페이로드 유형, 게이트웨이 요구 사항을 함께 확인한 다음 스레드에서 추론하는 대신 승인된 구성에서 테스트하십시오. 다음 사람이 같은 스레드를 그것이 받을 자격보다 더 큰 확신으로 인용할 것이므로 테스트한 조합을 변경 기록에 쓰십시오.

한도가 정말 적용된다면 답은 그에 맞는 지원되는 자격 증명 설계이지 강력한 시크릿을 줄인 버전이 아닙니다. 추정된 한도를 충족하려고 운영 키를 잘라내면 그 강도가 영구적으로 줄어들고 문서가 더 이상 보안과 일치하지 않는 시스템이 만들어집니다.

강도가 아니라 표현을 고치십시오

표현을 확인한 뒤 인증이 실패하면 인증 단계의 유효 정책으로 어떤 방법이 협상되는지, 어떤 피어 ID가 예상되는지, 게이트웨이가 생각하는 연결과 일치하는지를 읽으십시오. 점점 약해지는 추측은 진단이 아니라 지원 티켓이 첨부된 느린 하향 조정입니다.

필요한 자격 증명이 조직의 표준을 충족할 수 없다면 충족할 수 있는 설계로 바꾸십시오. 충분한 엔트로피를 가진 공유 시크릿을 한 번 생성하고 관리되는 필드에 저장하며 절대 공개하지 않는 것은 완벽하게 좋은 답이며, 그것을 더 짧게 만든 버전은 그렇지 않습니다.