Android 연구 노트 - APK 서명

【안드로이드 지식 노트】

---------[APK 서명]---------
목적: 패키지 본문의 정확성과 신뢰성을 보장하고 패키지 내용이 수정되는 것을 방지합니다.
이유: 서명은 다음과 같습니다. 패키지 본문에 내장된 서명 고유하고 고정된 문자열 문자열이 일치하는 경우에만 APK가 수정되지 않은 것으로 간주됩니다.

1. 기본 개념:
- 디지털 요약: 어떤 길이의 데이터도 해시 알고리즘을 통해 고정 길이의 이진 데이터로 얻을 수 있습니다. 이 데이터를 "요약"이라고 합니다. -
    특징:
        1. 고유성: 데이터 충돌이 없습니다. 너무 크면 서로 다른 두 데이터가 동일한 해시 값을 생성할 수 있음) 서로 다른 데이터의 다이제스트가 다름 2.
        고정 길이: 서로 다른 해시 알고리즘의 길이는 다르지만 동일한 해시 알고리즘으로 계산된 결과의 길이는 일관성이 있어야 함
            - MD5: 128비트 길이
            - SHA1: 160비트 길이
        3. 비가역성: 다이제스트를 기반으로 원본 데이터를 역복원할 수 없음
        
    - 서명: 다이제스트를 기반으로 암호화를 추가하는 것이며, 그런 다음 apk 설치 시 암호화합니다. 최종 다이제스트를 확인하고, 확인에 통과해야 설치를 계속할 수 있습니다.
        - 서명 프로세스: APK 데이터 ——> (다이제스트 계산) 1000101001 ——> (개인 키 암호화: 서명) 01001001 ——> ( 서명 작성) 서명이 있는 APK 데이터
        - 검증 과정: 암호화된 APK 데이터 ┬——> APK 데이터 ——> (요약 알고리즘 계산 ​​요약) 1000101001 ┬——> 다이제스트가 공개 키 복호화 결과와 일치하여 설치 가능 └—— > 서명
                       데이터 01001001 ——>( 공개키 복호화 서명) 1000101001 ┘
        - 위험점 : 공개키와 개인키가 모두 변조된 경우 수신자는 변조된 패키지 본문을 통과할 수 있다.예:
            ├─ 정상:
            │ ├─ 패키지 본문 AAA의 다이제스트는 A이고 서명은 -A입니다. 수신자는 공개 키 +를 통해 패키지 본문을 해독하고 다이제스트 A를 얻습니다. 패키지 본문 내용을 계산한 후 다이제스트도 A입니다. 설치가 허용됩니다. │ └─ 패키지 바디 AAA가
            BBB로 변경되었으며, 개인키가 없으면 서명을 생성할 수 없으므로 -A를 사용하고, 수신자는 패키지 바디 다이제스트 B와 일치하지 않는 공개키를 통해 다이제스트 A를 획득합니다. └─
            서명과 공개 키가 동시에 변조됨:
                └─ 패키지 본문 AAA가 BBB로 변경되고, 자신의 개인 키로 변조 -1 다이제스트를 암호화 -1B하고 동시에 변조 공개 키를 +1로 사용하여 수신자는 변조된 공개 키 +1을 통해 패키지 본문 다이제스트와 일치하고 설치가 허용되는 다이제스트 B를 얻습니다. - 디지털 인증서
                
: 서명 확인 프로세스에서 볼 수 있습니다. APK 패키지 본문의 수신자는 공개 키와 확인에 사용되는 다이제스트 알고리즘을 알아야 하며 디지털 인증서는 이 정보의 신뢰성을 보장하는 데 사용됩니다
    . - 인증 기관: CA라고 하는 신원 인증 기관(Certificate Authority)
    - 포함되는 정보:
        ├─ 인증기관
        ├─ 인증기관 서명
        ├─ 인증서에 바인딩된 서버 도메인 이름
        ├─ 인증서 버전, 유효기간
        ├─ 서명에 사용되는 암호화 알고리즘(RSA 등 비대칭 알고리즘)
        └─ 공개키 등 -
    정식 APP 서명 과정에서 인증서에 서명과 다이제스트 알고리즘이 들어가게 되며(패키지 본체에서는 크랙되기 쉽습니다.) APK 설치 시 인증서에서 다이제스트 알고리즘과 서명을 가져옵니다.
    - 정식 설치 시 인증서의 적법성을 먼저 확인한 후 서명을 확인합니다. 인증서는 공개 키나 서명이 변조되지 않았으므로 완전히 신뢰할 수 있음을 보장합니다. 2. 암호화 및 복호화 process: - 암호화되지 않은 메시지
    
흐름

        ├─ 정상: A ——> (메시지 전달: XXX) B가 메시지 XXX를 수신
        └─ 제3자가 있음: A ——> (메시지 전달: XXX) C가 메시지 CCC를 가로채기) B가 수신 메시지 CCC
- 대칭 암호화:
        ├─ 일반: A ——>(메시지 전달: +XXX) C는 메시지 +XXX를 가로채지만 키+가 없어 복호화할 수 없음 ——>(메시지 전달: +XXX) B는 메시지를 수신
        하고 암호화됨——>(메시지 전송: +CCC) B는 메시지 +CCC를 수신하고 키 +를 사용하여 CCC를 가져옵니다. - 비대칭
암호화:
    ├─ 일반:
    │ ├─ A ——>(메시지 전송: +XXX) C 차단된 메시지 +XXX이지만 개인 키가 없음 -, 해독할 수 없음 --> (메시지 전달: +XXX) B 수신된 메시지 +XXX, 키 사용 - 해독하고 XXX를 가져옴 │ └─ B --> (전달 메시지:
    -YYY ) C는 -YYY 메시지를 가로채지만 공개 키가 없어 +를 해독할 수 없습니다. --> (메시지 전달: -YYY) B는 -YYY 메시지를 수신하고 + 키를 사용하여 메시지를 해독합니다. YYY └─ 공개 키를 가로챕니다
    (개인 키는 일반적으로 공개되지 않으며 상황은 기본적으로 동일합니다)
        ├─ A ——>(메시지 전송: +XXX) C가 +XXX 메시지를 가로채았으나 개인키가 없어 복호화할 수 없음 ——>(메시지 전송: +XXX) B가 +XXX 메시지를 수신함 키 - XXX
        | 로 해독하고 키 + 해독을 사용하여 YYY를 얻습니다.
        
    특징: 비대칭 알고리즘은 안전하지만 http 통신에서는 모든 클라이언트가 공개 키를 사용하여 서버의 개인 키로 암호화된 메시지를 해독하고 볼 수 있습니다. 내용은 수정되지 않더라도 여전히 안전하지 않습니다.
- HTTPS 암호화 방식:
    └─ 일반:
        ├─ A ——>(메시지 전달: *1XXX+*1) C가 메시지를 가로채서 공개 키 없이는 복호화할 수 없습니다. *1——>(메시지 전달: *1XXX+*1 ) B는 메시지 *1XXX+*1을 수신하고 - 키를 사용하여 +*1을 해독하여 임의 키*1를 얻은 다음 키*1을 사용하여 해독한 다음 XXX를 얻기 위해 해독함 └─ B ——> (메시지 전달: *
        1YYY) C가 메시지를 가로채고 키*1 없이 해독할 수 없음——> (전송 메시지: *1XXX) A가 메시지 *1XXX를 수신하고 다음으로 해독함 key*1 및 YYY 가져오기
    설명: HTTPS 체계는 클라이언트가 키(*1)를 무작위로 생성하고 공개 키를 사용하여 키 +*1을 암호화한 다음 *1을 사용하여 메시지를 암호화하고 +*1을 전달하는 것입니다. 서버는 먼저 개인 키를 사용하여 +*1을 복호화하여 암호화 키를 얻은 다음 비밀 키를 사용합니다
    . 메시지가 전달되는 시간(키는 매번 무작위이기 때문에)과 서버의 개인키를 통해서만 키를 얻을 수 있으므로 이 두 가지 조건을 달성하기가 매우 어려우므로 이 프로세스가 더 안전합니다.

3. JAR 서명(기존 메커니즘) 및 V2 서명(새 메커니즘)

おすすめ

転載: blog.csdn.net/qq_37421018/article/details/120698598