Android V1 및 V2 서명 원칙에 대한 간략한 분석

시스템과 애플리케이션의 보안을 보장하기 위해 Android는 APK를 설치할 때 패키지의 무결성을 확인해야 합니다. 동시에 오버레이 설치 시나리오의 경우 패키지의 무결성도 확인해야 합니다. 이전 항목과 새 항목이 모두 일치합니다. 이 기사에서는 Android의 서명 및 확인 원칙을 간략하게 살펴보고 이를 여러 부분으로 분석합니다.

서명은 다음과 같습니다. 다이제스트 및 비대칭 키 암호화. 다이제스트는 콘텐츠의 지문 정보와 같습니다. 콘텐츠가 변조되면 다이제스트가 변경되면 서명이 변경됩니다. 무효가 됩니다. Android APK 서명의 경우에도 마찬가지입니다. APK 서명이 콘텐츠와 일치하지 않으면 Android 시스템은 APK 콘텐츠가 변조되었다고 간주하여 시스템 보안을 보장하기 위해 설치를 거부합니다. 현재 Android에는 V1, V2(N), V3(P)의 세 가지 서명이 있습니다. 이 기사에서는 처음 두 가지 유형인 V1과 V2만 살펴보고 V3의 라운드 비밀은 고려하지 않습니다. 먼저 V1 서명만 있는 APK 패키지의 스타일을 살펴보세요.

그런 다음 V2 서명만 있는 APK 패키지의 스타일을 살펴보세요.

V1 및 V2 서명이 모두 있는 경우:

예 V2 서명만 있는 경우 APK 패키지의 내용은 거의 변경되지 않고 META_INF에 새 파일이 없다는 것을 알 수 있습니다. v2 서명 체계에서는 APK 서명이 zip의 중앙 디렉터리 섹션 앞과 바로 뒤에 삽입됩니다. APK 서명 블록 내에서 서명 및 서명자 신원 정보는 APK 서명 체계 v2 블록에 저장되므로 아래와 같이 전체 APK 파일을 수정할 수 없습니다.

V1 서명은 META-INF 세 파일은 서명과 정보의 무결성을 보장합니다.

V1 서명은 어떻게 정보의 무결성을 보장합니까? V1 서명은 주로 세 부분으로 구성됩니다. 좁은 의미에서 서명과 공개 키에 대해 이야기하면 .rsa 파일에서만 V1 서명의 세 파일은 실제로 메커니즘 집합이므로 하나만 사용하여 설명할 수는 없습니다. .

APK의 리소스 파일을 교체하면 리소스 요약이 변경되어야 합니다. MANIFEST.MF의 정보를 수정하지 않으면 설치 중에 V1 검증이 실패하여 설치할 수 없습니다. , 파일이 변조된 경우 동시에 MANIFEST.MF의 다이제스트 값도 수정되므로 MANIFEST.MF 검증을 우회할 수 있습니다.

개인적으로 CERT.SF는 약간 중복성, 즉 파일 무결성에 대한 2차 보증과 같은 느낌을 줍니다. MANIFEST.MF를 우회하는 것처럼 .SF 검사도 쉽게 우회할 수 있습니다.

CERT.RSA와 CERT.SF는 서로 일치해야 하며 이름의 접두사가 동일해야 합니다. 이것이 지루한 기준인지 모르겠습니다.

CERT.RSA 파일의 내용을 살펴보세요.

CERT.RSA 파일은 공개 키와 암호화 알고리즘을 기반으로 인증서 공개 키, 만료 날짜, 발급자, 암호화 알고리즘 및 기타 정보를 저장합니다. CERT.SF 요약 정보의 엄격한 형식은 다음과 같습니다.

CERT.RSA에서 공유할 때 자주 사용되는 인증서의 지문 정보를 얻을 수 있습니다. WeChat 및 타사 SDK 신청 사실 공개키 서명 ​​+ 개발자 정보입니다:

CERT.RSA 파일을 제외하고 나머지 두 서명 파일은 키스토어와 관련이 없습니다. 서명 후 생성된 MANIFEST.MF와 CERT.SF는 동일하며 CERT.RSA 서명 파일만 다릅니다. 즉, 처음 두 개는 주로 각 파일의 무결성을 보장하고 CERT.RSA는 APK 전체의 소스와 무결성을 보장합니다. 그러나 META_INF에 있는 파일은 검증 범위에 포함되지 않는다는 점도 단점입니다. V1의. V2 서명은 정보의 무결성을 어떻게 보장합니까?

앞서 언급한 것처럼 V1 서명에 포함된 파일의 무결성은 쉽게 우회할 수 있습니다. 단일 파일의 무결성 검사가 그다지 중요하지 않다는 것을 알 수 있습니다. 설치 중에는 보다 간단한 방법을 사용하는 것이 좋습니다. V2 서명은 단일 파일을 검증하는 것이 아니라 APK를 검증하고 APK를 1M 블록으로 나누고 각 블록에 대한 값 다이제스트를 계산한 후 모든 다이제스트를 다이제스트한 후 서명에 사용합니다.

즉, V2 요약 서명은 두 가지 수준으로 나누어집니다. 첫 번째 수준은 APK 파일의 1, 3, 4부를 요약하는 것입니다. 수집을 선택한 다음 비밀 키를 사용하여 서명합니다. 설치되면 블록 다이제스트를 병렬로 처리할 수 있어 검증 속도가 향상됩니다.

APK가 먼저 다이제스트된 다음 서명됩니다. 먼저 다이제스트의 정의를 살펴보겠습니다. 메시지 다이제스트: 다이제스트는 메시지 데이터에 대해 단방향 해시를 수행하여 고정 길이 해시 값을 생성합니다. 값은 메시지 다이제스트입니다. 일반적으로 듣는 MD5 및 SHA1의 경우 둘 다 다이제스트 알고리즘 유형입니다. 이론적으로 다이제스트에 충돌이 발생하지만 제한된 길이 내에서 충돌률이 낮으면 다이제스트를 사용하여 메시지의 무결성을 보장할 수 있습니다. 메시지가 변조되는 한 다이제스트는 확실히 발생합니다. 변화. 그러나 메시지와 요약이 동시에 수정되면 알 수 없습니다.

디지털 서명(공개 키 디지털 서명)이란 무엇입니까? 비대칭 암호화 기술을 사용하여 개인 키를 통해 다이제스트를 암호화하여 문자열을 생성합니다. 이 문자열 + 공개 키 인증서는 디지털 서명으로 간주될 수 있습니다. RSA와 같은 메시지의 암호화 알고리즘은 일반적으로 사용되는 비대칭 암호화 알고리즘입니다. 개인 키가 없는 경우 비대칭 암호화 알고리즘은 다른 사람이 서명을 위조할 수 없도록 보장할 수 있습니다. 따라서 디지털 서명은 보낸 사람 정보의 신뢰성을 효과적으로 증명하는 역할도 합니다. 그러나 Android의 키 저장소 인증서는 자체 서명되고 제3자 기관의 인증을 받지 않기 때문에 사용자는 자체 키 저장소를 생성할 수 있습니다. Android 서명 체계는 APK가 다시 서명되지 않는다는 것을 보장할 수 없습니다.

이제 요약과 서명의 개념을 알았으니, 안드로이드 서명 파일이 어떻게 나오는지 살펴볼까요? 원본 APK 패키지에 어떻게 영향을 미치나요? SDK에서 apksign을 통해 APK에 서명하는 명령은 다음과 같습니다.

주로 android/platform/tools/apksig 폴더에 구현되어 있습니다. 본체는 ApkSigner.java의 서명 기능입니다. 함수는 상대적으로 깁니다. 여러 단계로 분석합니다.

먼저 ApkUtils.findZipSections 단계를 살펴보겠습니다. 이 함수는 주로 APK 파일을 구문 분석하고 ZIP 형식에 대한 몇 가지 간단한 정보를 얻은 후

ZipSections 중앙 디렉터리 정보, 중앙 디렉터리 끝 정보 등과 같은 ZIP 파일 형식에 대한 일부 정보가 포함되어 있습니다. zip 파일 형식과의 비교는 다음과 같습니다.

ZipSections를 얻은 후 , APK ZIP 패키지를 추가로 구문 분석하고 계속하면

V2 서명이 먼저 확인되는 것을 볼 수 있습니다. 처음 서명할 때 이 비정상적인 논리 분기를 직접 가져오며, 반복적으로 서명할 경우 이전 V2 서명을 얻을 수 있습니다. 여기서 V2 서명을 얻는 목적은 V2 서명을 제외하고 데이터 블록을 얻는 것으로 의심됩니다. V2 서명 이외의 서명 자체는 서명에 포함될 수 없기 때문에 나중에 중앙 디렉터리 영역을 구문 분석하여 서명용 DefaultApkSignerEngine을 빌드합니다.

먼저 중앙 디렉터리 영역을 구문 분석하고 AndroidManifest 파일을 얻습니다. minSdkVersion을 얻고(서명 알고리즘에 영향을 줌) DefaultApkSignerEngine을 빌드하면 V1 V2 서명이 기본적으로 켜져 있습니다.

다섯 번째 및 여섯 번째 단계의 주요 작업은 보다 효율적인 서명 처리를 위해 필요한 디렉토리 및 기타 작업 정렬을 포함하여 apk 사전 처리입니다. 완료되면 서명이 시작됩니다. 이 과정에서 가장 먼저 해야 할 일은 V1 서명입니다(활성적으로 닫히지 않으면 기본적으로 존재함).

7, 8, 9단계는 처리 논리로 간주할 수 있습니다. META-INFO 폴더에 일부 서명 파일 생성, 중앙 디렉터리 업데이트, 중앙 디렉터리 끝 업데이트 등을 포함하여 주로 V1SchemeSigner에서 처리되는 V1 서명의 프로세스는 복잡하지 않으므로 다루지 않겠습니다. 자세한 내용은 다음과 같습니다.

다음은 중복 서명 문제에 대해 특별히 언급한 것입니다. V1으로 서명된 APK가 다시 V1로 서명되면 문제가 없습니다. : 재서명시 이전 서명파일은 제외됩니다.

디렉터리에 있는 파일, META-INF 폴더, sf, rsa로 끝나는 파일 등은 V1 서명으로 처리되지 않는 것을 볼 수 있으므로 여기서는 다중 서명에 대해 걱정할 필요가 없습니다. 다음 단계는 V2 서명을 처리하는 것입니다.

V2SchemeSigner는 V2 서명을 처리하며 V1이 서명한 APK에 대해 블록 요약을 직접 수행한 다음 서명을 수집합니다. V2 서명은 이전 V1 서명 이후의 정보를 변경하지 않습니다. 서명 후에는 중앙 디렉터리에서 처리됩니다. 디렉터리 앞에 V2 서명 블록을 추가하고 중앙 디렉터리 끝 정보를 업데이트합니다. V2 서명 후에는 중앙 디렉터리의 오프셋이 다시 변경되기 때문입니다.

프로세스 서명 확인은 덮어쓰기를 제외하고 서명의 역순으로 간주될 수 있습니다. 설치 시 공개 키와 인증서 정보가 일치하는지 확인해야 할 수도 있습니다. 그렇지 않으면 덮어쓰기 설치가 실패합니다.

서명 확인 항목은 PackageManagerService 설치에 있습니다. 7.0 이상의 휴대폰에서는 먼저 V2 서명을 감지하고 7.0 미만의 휴대폰에서는 V1 서명을 확인합니다. V2 서명 확인 메커니즘은 없습니다. V1만 확인되므로 앱의 miniSdkVersion<24(N)인 경우 서명 방법에 V1 서명이 포함되어야 합니다.

확인 프로세스는 서명의 반대입니다. 서명 과정을 이해한다는 것은 이 글에서 자세한 설명을 요구하는 것이 아니라, 관심이 있으신 분은 직접 분석해 보시기 바랍니다. APK 자체의 무결성 확인 외에 오버레이 설치에 대해서도 언급하겠습니다. 인증서가 일관성이 있는지(동일한 키 저장소 서명) 경우에만 덮어쓰기가 가능합니다. 새로운 설치와 비교할 때 오버레이 설치에는 몇 가지 추가 확인이 필요합니다.

여기서는 인증서 부분만 고려합니다.

Android V1 및 V2의 서명 원리에 대한 간략한 분석

p>

참고용으로만 수정 가능