SafetyNet의 하드웨어 증명 기능은 그대로 유지됩니다.

2020년 5월, Google은 조용히 Android 모딩 커뮤니티를 놀라게 했습니다. SafetyNet 응답을 위한 하드웨어 지원 증명 도입 일부 장치에서는. Google 서버가 무결성을 확인하기 위해 'BASIC' 평가 보고서를 완전히 중단하지 않았기 때문입니다. 원격 장치의 소프트웨어 환경에서 하드웨어 기반 키 증명의 출현은 더 이상 것처럼 보였습니다. 실험. 그러나 당시 구글은 "...기기의 적격성 기준을 평가하고 조정합니다...,"는 광범위한 출시 가능성을 나타냅니다. 음, Google이 마침내 정확히 그 일을 하고 있습니다.

에 따르면 최근 게시물 'SafetyNet API 클라이언트'용 Google 그룹에서 SafetyNet Attestation API 응답의 'evaluationType' 필드가 이제 공식적으로 지원되는 기능이 되었습니다. 개발자의 경우 이는 Google Play 서비스를 활용하여 기기의 TEE(신뢰할 수 있는 실행 환경)를 사용하여 생성된 수정되지 않은 키 저장소 인증서를 보낼 수 있음을 의미합니다. 또는 장치의 소프트웨어 환경이 어떤 방식으로든 변조되었는지 확인하려고 할 때마다 SafetyNet 서버에 전용 하드웨어 보안 모듈(HSM)을 설치합니다. 그러나 이 기능은 이미 "ctsProfileMatch" 매개변수를 사용하고 최고 수준의 기기 무결성 보장이 필요한 앱만을 위한 것이므로 이 기능을 과도하게 사용해서는 안 됩니다. 공식 문서에서 제안.

몇 주 전에 사람들이 Google Play 서비스가 기본 증명이 인증되지 않은 경우에도 많은 경우 CTS 프로필 검증을 위해 하드웨어 증명을 선호합니다. 선택된. 아직 그럴 수도 있으니 참고하세요

악용 가능 하드웨어 증명 루틴의 기회주의적 특성을 확인하고 이러한 시나리오에서 기본 증명을 통과합니다. 이것이 영구적인 수정은 아니지만(그리고 그것이 입증되기 전에는 아무 것도 없었음) Google이 기본 평가를 완전히 포기하기로 결정할 때까지 사람들이 SafetyNet을 우회할 수 있도록 허용해야 합니다. 그럼에도 불구하고 Google이 애초에 이러한 조치를 취하는 것은 우리 열성팬과 개발자 커뮤니티에 부끄러운 일입니다.

Google이 계속해서 하드웨어 기반 증명을 시행한다면 이는 고급 사용자가 마스킹을 사용하여 루트 액세스와 함께 Google Pay 및 기타 SafetyNet 기반 앱을 실행할 수 있습니다. 기법. 상황은 아직 진행 중이기 때문에 겉으로 보이는 것보다 상황이 더 복잡할 수도 있습니다. 이 문제에 대해 새로운 진전이 있으면 독자들에게 계속해서 알려드리겠습니다.

XDA 회원님께 감사드립니다 Some_Random_사용자 이름 팁을 위해!