要改Google签名？这些你足够了解吗！

大家好，我是小编阿文。欢迎您关注我们，经常分享有关Android出海，iOS出海，App市场政策实时更新，互金市场投放策略，最新互金新闻资讯等文章，期待与您共航世界之海。

老项目keystore签名信息包含国内背景信息要改？签名信息更换要改？签名过期要改？签名被盗要改？考虑升级签名要改？

不管你是何种原因要改，Google应用签名密钥，Google上传签名密钥这俩概念你真的懂了吗？

让我们一起详细探讨下什么是Google应用签名密钥，什么是Google上传签名密钥！

Google应用签名密钥

我们先来聊聊Google应用签名密钥。作为Android开发者，我们都知道App上传应用市场一定要有正式的应用签名，也就是大家熟知的keystore或者jks文件。对于Android项目而言，应用签名是至关重要且要一定保管好的。这都归咎于它在应用发布、下载和安装过程中的重要地位。应用签名作用如下：

校验应用的完整性：签名可以确保应用在发布、下载和安装过程中没有被篡改，保证用户下载到的应用是原始版本。
确认应用来源：签名是开发者与应用之间的可信任关联，表明应用是由特定开发者发布的。
防止应用被恶意替换：如果应用使用一个特定的密钥签名，那么其他使用不同密钥签名的文件将无法安装或覆盖该应用，从而防止恶意第三方替换或覆盖已安装的应用。

如果您操作过Google Play App上架流程（Android出海实战：Google Play 上架教程），你会发现我们在第一次发布App的时候会有一个步骤：上传应用密钥（应用签名）。Google给我们提供了2种方式：Google自动生成应用签名密钥以及开发者自行提供应用签名密钥，步骤截图及解释如下：

选择Google 生成应用签名，点击确认按钮即可。在这里也是强烈建议大家使用Google生成应用签名密钥，至少我们一直是这么做的。不过，如果您要使用自行提供的应用签名密钥，可以选择使用其他密钥 -> 选择从java密钥库导出并上传密钥。

当然，我们也不能直接上传keystore或者jks文件，为了安全考虑，Google提供了加密公钥来对我们的密钥文件加密，而Google需要的是加密后的zip文件。步骤截图和详细解释如下：

按照上图我们下载加密公钥（每个应用是不一样的，所以我们必须下载自己Play后台的公钥文件）和PEPK工具，执行下面的命令后输入相关密钥库密码以及密钥密码就会输出output.zip 文件，最后执行第四步上传该文件即可。

java -jar pepk.jar --keystore=your keystroe --alias=your keystroe alias --output=output.zip --include-cert --rsa-aes-encryption --encryption-key-path=encryption_public_key.pem

注意：如果出现否java.security.NoSuchAlgorithmException: Cannot find any provider supporting RSA/NONE/OAEPWithSHA1AndMGF1Padding 这个错误，可以检查下使用的JDK 是否是OpenJDK，因为这条命令需要用OpenJDK的Java jar去执行。

聊到这里，大家对Google应用签名密钥可能都不是很陌生。那么Google上传签名密钥又是什么呢？

Google上传签名密钥

我们先来看下面这张图：

在Play后台设置 -> 应用签名一列，有一项上传密钥证书。见名知意，它是Google用于确认我们上传的App更新是您本人提供的，而不是被他人恶意纂改过的。我们第一次上传应用后Google 默认会将应用的签名文件设置为上传密钥。聊到这里，我想大家应该明白了，更改Google签名，我们大概率要改的是这个上传密钥证书，而非Google应用签名证书（当然，这不包括自行提供的应用签名密钥的用户）。下面我们来简单说下这两种密钥都如何更改。先看大部分Google用户关心的上传密钥证书更改。

Google上传签名密钥更改

Google大大事无巨细，已经详细提供了更改方法，见下图：

首先，我们打开google 后台进入应用程序->设置->应用签名->请求重置上传密钥并选择重置上传密钥的原因。如上图。
生产新的签名密钥库，并使用密钥库通过命令生成.pem文件。命令如步骤3下：
上传.pem 文件并申请，上传后会有三天左右的审核期，在此期间用新的签名的应用上传会提示xxxx.xx.xx xx:xx (具体时间)后签名文件生效的一个提示
```
$ keytool -export -rfc -keystore upload-keystore.jks -alias upload -file upload_certificate.pem
```

至此，在审核过后，Google上传签名密钥更改就成功了。等下次再提包时，我们在使用新的上传密钥就OK了。

Google应用签名密钥更改

一般来说我们不需要更新应用签名密钥。以下是请求升级应用签名密钥的几种原因：您需要加密强度更高的密钥或者您的应用签名密钥被盗（只适用于使用自行上传的签名场景）

我们打开google 后台进入应用程序->设置->应用签名->请求升级密钥，选择自己上传的新密钥即可，如下图

后续步骤和上文使用自行提供的应用签名密钥相同，不在过多讲述。不过有一些注意事项，在这里提醒下大家

只有使用 app bundle 的应用支持密钥升级。
只会对于 Android N（API 级别 24）及更高版本上的设备生效，并且每个应用的应用签名密钥每年只能升级一次
如果您成功请求升级此密钥，您的新密钥将用于为所有安装和应用更新签名。在搭载 Android T（API 级别 33）及更高版本的设备上，Android 平台将强制要求使用升级后的密钥
在搭载 Android N（API 级别 24）到 Android S（API 级别 32）的设备上，除非用户关闭了 Google Play 保护机制，否则该机制会检查应用更新是否已使用您升级后的密钥签名。

番外篇

为了大家对这部分知识了解更全面，我们在多赘述一下如何创建签名文件及Android V1 V2 V3 V4 四种签名方案及签名流程介绍。

创建签名文件的方式（我们通过Android Studio）

1) 在菜单栏中，依次点击 Build > Generate Signed Bundle/APK。在 Generate Signed Bundle or APK 对话框中，选择 Android App Bundle 或 APK，然后点击 Next。

2) 在 Key store path 字段下，点击 Create new。

3) 填写签名信息（这部分信息很重要，一定要经过领导的确认才能填写）

密钥库信息
    Key store path：选择创建密钥库的位置
    Password：密钥库密码

· 密钥信息
    Alias：为您的密钥输入一个标识名（别名）
    Password：密钥密码。建议与密钥库密码相同（4.2 版本开始，Android Studio 现在将在 JDK 11 上运行。此变更会导致与签名密钥相关的底层行为发生变更，如果不一致会出现Different store and Key passwords not supported for PKCS12 Key stores）。
    Validity (years)：以年为单位设置密钥的有效时长。密钥的有效期应至少为 25 年。

· Certificate：为证书输入一些关于您本人的信息。此信息不会显示在应用中，但会作为 APK 的一部分包含在您的证书中。
    First and Last Name：名字和姓氏
    Organizational Unit：组织单位名称
    Organization：组织名称
    City or Locality：城市或区域名称
    State or Province：省/市/自治区名称
    Countyr Code：国家地区代码（双字母）

Android V1 V2 V3 V4 四种签名方案及签名流程介绍

签名方案介绍：

v1签名方案
    使用场景：
        适用于所有Android系统版本，包括旧版系统。
    优点：
        兼容性好：由于是基于JAR的签名，V1签名方案在所有Android系统版本上都具有很好的兼容性。
        签名文件较小：V1签名产生的签名文件较小，不会明显增加应用的大小。
    缺点：
        安全性较低：V1签名只对整个JAR文件进行签名，无法对单个文件进行精确校验。如果应用的某个文件被篡改，V1签名无法检测到。
        可信度较低：V1签名只要求应用的发布者拥有一个有效的证书，无法验证证书的信任链，因此无法确保应用的来源的可信度。

v2签名方案
    使用场景：
        适用于Android 7.0（API级别24）及更高版本。
    优点：
        减少APK大小：V2签名可以将APK的内容进行划分，只对部分内容进行签名，从而减少APK的大小。
        提高验证速度：由于V2签名对APK内容进行了划分，可以并行验证每个部分，从而提高验证的速度。
        增强安全性：V2签名使用基于SHA256的哈希算法和ECDSA进行签名，提供了更好的保护。
    缺点： 
        对旧版Android系统兼容性有限：在Android 7.0之前的版本中，不支持V2签名。

v3签名方案
    使用场景：
        适用于Android 9.0（API级别28）及更高版本。
    优点：
        更高的安全性：V3签名采用了更强大的签名算法（基于RSA或ECDSA）和更长的密钥长度，以提供更高的安全性。
        支持APK密钥轮替：V3签名方案的一个关键特性是支持APK密钥的轮替。这意味着在应用的更新过程中，开发者可以更改其签名密钥。这对于安全管理、密钥过期或需要提高安全性的情况非常有用。
    缺点：
        对旧版Android系统兼容性有限：在Android 9.0之前的版本中，不支持V3签名。
        
v3.1签名方案
    使用场景：
        适用于Android 13及更高版本。
    优点：
        支持SDK版本定位功能：允许轮替定位到平台的更高版本。
        向后兼容性：在旧版Android设备上，会忽略轮替signer，而使用V3分块中的原始signer。
    缺点： 
        对旧版Android系统兼容性有限：在Android 13之前的版本中，不支持V3.1签名。

v4签名方案
    使用场景：
        适用于Android 11及更高版本，主要用于支持ADB增量APK安装。
    优点：
        支持增量更新：允许开发者只推送APK中发生更改的部分，减少网络带宽使用，加速应用更新过程。
        安全性高：继承了v2和v3签名的安全性特点。
    缺点： 
        技术复杂性：相比其他签名方式，V4签名在技术上更为复杂。
        工具支持：部分旧的构建工具和IDE可能不完全支持V4签名。
        性能影响：在某些情况下，V4签名可能会稍微增加应用安装或更新的时间。

签名流程介绍

v1签名方案签名流程：

·  使用 SHA1/SHA256 对apk的所有文件计算摘要 保存在\*.MF文件
·  使用 SHA1/SHA256对\*.MF文件以及MF中每个Name对应的值进行计算摘要并保存在\*.SF文件
·  使用私钥对*.SF文件签名打包签名、公钥以及证书生成\*.RSA文件
·  将上面三个文件放入META-INF目录打包到应用中

验证流程:

·  校验SF文件的签名：计算\*.SF文件的摘要，然后用\*.RSA文件中公钥解密\*.RSA中签名得到的摘要，如果两者一致则进入下一步；
·  校验\*.MF文件的完整性：计算MANIFEST.MF文件的摘要，与\*.SF主属性中的摘要进行对比，如一致则逐一校验\*.MF文件各个条目的完整性；
·  校验APK中每个文件的完整性：逐一计算APK中每个文件（META-INF目录除外）的摘要，与\*.MF中的记录进行对比，如全部一致，刚校验通过；
·  校验签名的一致性：如果是升级安装，还需校验证书签名是否与已安装APP一致，如果应用中存在相同包名但签名不一样的APP，则安装失败；

v2 v3 v4 签名方案签名流程

APK实际上是一个ZIP格式的压缩包，ZIP结构主要包括了3个部分数据区、中央目录区、中央目录结尾区

· 数据区：存放真正数据的地方。
· 中央目录区：存放关于数据区的元数据的地方。
· 中央目录结尾区：存放关于中央目录区的元数据的地方

签名流程

· 对这数据区、中央目录区和中央目录结尾区，这3块块区域进行切分，切分成一个个大小为1M的小块
· 计算每个小块的消息摘要，将所有小块的消息摘要拼接在一起，整体计算消息摘要并用私钥进行签名
· 将签名、公钥、证书、算法、签名者信息等相关内容作为一个新的区域（APK 签名分块），插入到ZIP结构中，位于“ZIP 中央目录区“之前

验签过程：

· 找到APK 签名分块并验证以下内容：
    a. APK 签名分块的两个大小字段包含相同的值。
    b. ZIP 中央目录结尾紧跟在ZIP 中央目录记录后面。
    c. ZIP 中央目录结尾之后没有任何数据。
· 找到APK 签名分块中的第一个APK 签名方案 v2 分块。如果 v2 分块存在，则继续执行第 3 步。否则，回退至使用 v1 方案验证 APK。
· 对APK 签名方案 v2 分块中的每个 signer 执行以下操作：
    a. 从 signatures 中选择安全系数最高的受支持 signature algorithm ID。安全系数排序取决于各个实现/平台版本。
    b. 使用 public key 并对照signed data 验证 signatures 中对应的 signature。（现在可以安全地解析 signed data 了。）
    c. 验证 digests 和 signatures 中的签名算法 ID 列表（有序列表）是否相同。（这是为了防止删除/添加签名。）
    d. 使用签名算法所用的同一种摘要算法计算 APK 内容的摘要。
    e. 验证计算出的摘要是否与 digests 中对应的 digest 相同。
    f. 验证 certificates 中第一个 certificate 的 SubjectPublicKeyInfo 是否与 public key 相同。
· 如果找到了至少一个 signer，并且对于每个找到的 signer，第 3 步都取得了成功，APK 验证将会成功。