CN117041954A - Android系统的升级方法、装置、设备以及存储介质 - Google Patents

Android系统的升级方法、装置、设备以及存储介质 Download PDF

Info

Publication number
CN117041954A
CN117041954A CN202310571864.8A CN202310571864A CN117041954A CN 117041954 A CN117041954 A CN 117041954A CN 202310571864 A CN202310571864 A CN 202310571864A CN 117041954 A CN117041954 A CN 117041954A
Authority
CN
China
Prior art keywords
key
software package
ota software
ota
release
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310571864.8A
Other languages
English (en)
Inventor
刘显珂
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Leshi Zhixin Electronic Technology Tianjin Co Ltd
Original Assignee
Leshi Zhixin Electronic Technology Tianjin Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Leshi Zhixin Electronic Technology Tianjin Co Ltd filed Critical Leshi Zhixin Electronic Technology Tianjin Co Ltd
Priority to CN202310571864.8A priority Critical patent/CN117041954A/zh
Publication of CN117041954A publication Critical patent/CN117041954A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0433—Key management protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/106—Packet or message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data
    • H04W8/245—Transfer of terminal data from a network towards a terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Stored Programmes (AREA)

Abstract

本公开的实施例提供了一种Android系统的升级方法、装置、设备以及存储介质，应用于系统软件升级技术领域。该方法包括将第一OTA软件包发送到采用保存旧release‑key公钥的用户设备，以便对用户设备进行更新，更新后用户设备recovery子系统中的旧recovery公钥更新为新release‑key公钥；第一OTA软件包整包使用旧release‑key私钥签名，其中的recovery子系统中的公钥替换为新release‑key公钥；将第二OTA软件包发送到采用第一OTA软件包更新后的recovery中包括新release‑key公钥的用户设备，以便对用户设备进行更新。以此方式，可以达到在密钥发生泄漏的情况下，快速实现对用户设备Android系统的升级，以降低安全隐患，减少运营收入的损失的效果。

Description

Android系统的升级方法、装置、设备以及存储介质
技术领域
本公开涉及计算机技术领域，尤其涉及系统软件升级技术领域，具体涉及一种Android系统的升级方法、装置、设备以及存储介质。
背景技术
在空中下载技术(Over-the-Air Technology，OTA)签名中，安卓系统(Android)使用私钥对更新包进行签名，然后将公钥内置到设备中，如“recovery子系统/res/keys”文件。Android系统会在接收到OTA更新包后，使用内置的公钥来验证更新包的数字签名是否与之匹配，从而确认更新包的真实性和完整性。如果验证通过，设备就会开始安装更新包。
此外，Android系统更新包中的应用也用签名来保护，而且针对不同的sharedUserId，使用不同的证书来签名，包括platform、media、shared等，加上用于OTA整包签名用的证书release-key，这些密钥称为密钥集和，简称密钥集。其中platform、media、shared等类型的应用(Apk)密钥就会影响到跨平台应用的应用更新，策略上为了方便这些类型的应用跨平台发布，不同平台上使用的这些密钥是相同的，如platform、media、shared。
但是，当出现一些主动(如内部人员泄漏)或被动(如被黑)的情况下，签名所用的密钥集的个别或者全部都可能暴露。一旦发生这样的事情，第三方就可以重新制作软件包。而第三方的软件包，可能会删除预制的应用，引入恶意的应用，带来安全的隐患，造成运营收入的损失。
发明内容
本公开提供了一种Android系统的升级方法、装置、设备以及存储介质。
根据本公开的第一方面，提供了一种Android系统的升级方法。该方法包括：
将第一OTA软件包发送到recovery保存旧release-key公钥的用户设备，以便对用户设备进行更新，更新后用户设备recovery子系统中的旧release-key公钥更新为新release-key公钥；所述第一OTA软件包整包使用旧release-key私钥签名，其中的recovery子系统中的公钥替换为新release-key公钥；
将第二OTA软件包发送到采用所述第一OTA软件包更新后的recovery包括新release-key公钥的用户设备，以便对用户设备进行更新，所述第二OTA软件包整包使用新release-key私钥来签名。
如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述第一OTA软件包内部包括应用文件，所述第一OTA软件包的生成包括：
解压第三OTA软件包，所述第三OTA软件包整包签名为旧release-key私钥；
根据预设sharedUserId属性密钥对关系，对所述第三OTA软件包内部的应用文件的sharedUserId属性进行重签名；
修改recovery子系统中的/res/key，更新为新release-key公钥；
重新压缩所述第三OTA软件包，生成第一OTA软件包，所述第一OTA软件包整包使用旧release-key私钥签名。
如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述根据预设sharedUserId属性密钥对关系，对所述第三OTA软件包内部的应用文件的sharedUserId属性进行重签名包括：
判断所述第三OTA软件包内部的应用文件的sharedUserId属性是否为system；
若所述第三OTA软件包内部的应用文件的sharedUserId属性为system，则使用新的platform密钥进行重签名。
如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述根据预设sharedUserId属性密钥对关系，对所述第三OTA软件包内部的应用文件的sharedUserId属性进行重签名还包括：
若所述第三OTA软件包内部的应用文件的sharedUserId属性不为system，则判断所述第三OTA软件包内部的应用文件的sharedUserId属性是否为media；
若所述第三OTA软件包内部的应用文件的sharedUserId属性为media，则使用新的media密钥进行重签名。
如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述根据预设sharedUserId属性密钥对关系，对所述第三OTA软件包内部的应用文件的sharedUserId属性进行重签名还包括：
若所述第三OTA软件包内部的应用文件的sharedUserId属性不为media，则判断所述第三OTA软件包内部的应用文件的sharedUserId属性是否为shared；
若所述第三OTA软件包内部的应用文件的sharedUserId属性为shared，则使用新的shared密钥进行重签名。
根据本公开的第二方面，提供了一种Android系统的升级装置。该装置包括：
第一发送模块，用于将第一OTA软件包发送到recovery保存旧release-key公钥的用户设备，以便对用户设备进行更新，更新后用户设备recovery子系统中的旧release-key公钥更新为新release-key公钥；所述第一OTA软件包整包使用旧release-key私钥签名，其中的recovery子系统中的公钥替换为新release-key公钥；
第二发送模块，用于将第二OTA软件包发送到采用所述第一OTA软件包更新后的recovery包括新release-key公钥的用户设备，以便对用户设备进行更新，所述第二OTA软件包整包使用新release-key私钥来签名。
根据本公开的第三方面，提供了一种电子设备。该电子设备包括：存储器和处理器，所述存储器上存储有计算机程序，所述处理器执行所述程序时实现如以上所述的方法。
根据本公开的第四方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如以上所述的方法。
本申请实施例提供的一种Android系统的升级方法、装置、设备以及存储介质，能够通过服务器将第一OTA软件包发送到recovery保存旧release-key公钥的用户设备，以便对用户设备进行更新，更新后用户设备recovery子系统中的旧release-key公钥更新为新release-key公钥，第一OTA软件包整包使用旧release-key私钥签名，其中的recovery子系统中的公钥替换为新release-key公钥，以实现基于第一OTA软件包中的旧release-key公钥，第一OTA软件包可以被用户设备中的旧recovery子系统验证通过，并基于第一OTA软件包中的新release-key公钥，对用户设备中的旧recovery子系统进行更新，进而再将第二OTA软件包发送到采用第一OTA软件包更新后的采用新release-key公钥的用户设备，完成对用户设备进行更新，从而达到在密钥发生泄漏的情况下，快速实现对用户设备Android系统的升级，以降低安全隐患，减少运营收入的损失的效果。
应当理解，发明内容部分中所描述的内容并非旨在限定本公开的实施例的关键或重要特征，亦非用于限制本公开的范围。本公开的其它特征将通过以下的描述变得容易理解。
附图说明
结合附图并参考以下详细说明，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。附图用于更好地理解本方案，不构成对本公开的限定在附图中，相同或相似的附图标记表示相同或相似的元素，其中：
图1示出了能够在其中实现本公开的实施例的示例性运行环境的示意图；
图2示出了图1中所示的服务器和用户设备之间的交互方法的示意图；
图3示出了根据本公开的实施例的Android系统的升级方法的流程图；
图4示出了根据本公开的实施例的Android系统的升级的示意图；
图5示出了根据本公开的实施例的生成第一OTA软件包的示意图；
图6示出了根据本公开的实施例的Android系统的升级装置的框图；
图7示出了能够实施本公开的实施例的示例性电子设备的方框图。
具体实施方式
为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的全部其他实施例，都属于本公开保护的范围。
另外，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
本公开中，可以实现基于第一OTA软件包中的旧release-key公钥，第一OTA软件包可以被用户设备中的旧recovery子系统验证通过，并基于第一OTA软件包中的新release-key公钥，对用户设备中的旧recovery子系统进行更新，进而再将第二OTA软件包发送到采用第一OTA软件包更新后的采用新release-key公钥的用户设备，完成对用户设备进行更新，从而达到在密钥发生泄漏的情况下，快速实现对用户设备Android系统的升级，以降低安全隐患，减少运营收入的损失的效果。
图1示出了能够在其中实现本公开的实施例的示例性运行环境100的示意图。在运行环境100中包括服务器102和用户设备104。
图2示出了图1中所示的服务器102和用户设备104之间的交互方法200的示意图。
在框201，服务器102将第一OTA软件包发送到采用旧release-key公钥的用户设备，以便对用户设备104进行更新，更新后用户设备104recovery子系统中的旧release-key公钥更新为新release-key公钥；第一OTA软件包整包使用旧release-key私钥签名，其中的recovery子系统中的公钥替换为新release-key公钥。
在框202，服务器102将第二OTA软件包发送到采用第一OTA软件包更新后的recovery包括新release-key公钥的用户设备104，以便对用户设备104进行更新，第二OTA软件包整包使用新release-key私钥来签名。
本申请实施例提供的一种Android系统的升级装置，如服务器102，能够通过将第一OTA软件包发送到recovery保存旧release-key公钥的用户设备104，以便对用户设备104进行更新，更新后用户设备104中的recovery子系统中的旧release-key公钥更新为新release-key公钥，第一OTA软件包整包签名使用旧release-key私钥签名，其中的recovery子系统中的公钥替换为新release-key公钥，以实现基于第一OTA软件包中的旧release-key公钥，第一OTA软件包可以被用户设备104中的旧recovery子系统验证通过，并基于第一OTA软件包中的新release-key公钥，对用户设备104中的旧recovery子系统进行更新，进而再将第二OTA软件包发送到采用第一OTA软件包更新后的采用新release-key公钥的用户设备104，完成对用户设备104进行更新，从而达到在密钥发生泄漏的情况下，快速实现对用户设备Android系统的升级，以降低安全隐患，减少运营收入的损失的效果。
图3示出了根据本公开实施例的Android系统的升级方法300的流程图。方法300可以由图1中的服务器102执行。
在框310，将第一OTA软件包发送到recovery保存旧release-key公钥的用户设备，以便对用户设备进行更新，更新后用户设备recovery子系统中的旧release-key公钥更新为新release-key公钥；第一OTA软件包整包使用旧release-key私钥签名，其中的recovery子系统中的公钥替换为新release-key公钥。
在一些实施例中，第一OTA软件包可以是结合了强制升级和推荐升级的OTA案件包，即一个由服务器重制作出来的过渡版本的OTA软件包(签名过渡包)，其整包签名为旧release-key私钥，其中recovery子系统包括新release-key公钥，以便在服务器上通过脚本一次完成。
其中，强制升级包括系统启动完，停留在升级提示界面，只能选择升级，而不能使用其他功能，体验差，除非有重大安全问题，不用该策略。推荐升级包括系统启动完，提示用户有新的软件版本，用户可以选择升级，或者忽略，继续使用当前版本。
具体地，第一OTA软件包整包签名的密钥对，即release-key密钥对。其中，私钥，即旧release-key私钥用于软件包整包签名，公钥，即新release-key公钥保存到recovery子系统中，用于升级时校验后续软件包的签名是否为release-key的私钥。
在一些实施例中，基于第一OTA软件包使用旧release-key私钥来签名，第一OTA软件包可以被用户设备中的旧recovery子系统验证通过；基于第一OTA软件包中的新release-key公钥，可以对用户设备中的旧release-key公钥的recovery子系统进行更新。
在一些实施例中，基于第一OTA软件包，在对Android系统进行升级时可以不用强制升级，发新的软件包版本时，测试部分确认功能没有问题后，执行一次软件包重制作构建过程，然后发布新的OTA软件包版本，用户只需要升级一次即可。
在框320，将第二OTA软件包发送到采用第一OTA软件包更新后的recovery包括新release-key公钥的用户设备，以便对用户设备进行更新，第二OTA软件包整包使用新release-key私钥来签名。
在一些实施例中，第二OTA软件包可以是包括新密钥集，即新release-key密钥对的新版OTA软件包(正常功能包)，其中，私钥用于OTA软件包整包签名，用于与第一OTA软件包中的旧release-key公钥进行校验，公钥保存到第二OTA软件包的recovery子系统中，升级后用于校验后续的新release-key签名的OTA软件包。
在一些实施例中，对于发版管理，当多个用户设备接收到第一OTA软件包后，在多个用户设备中会出现旧的OTA软件包版本和新的OTA软件包版本共存一段时间的情况，当升级率，即选择升级的用户的数量与总用户数量的比例达到预设的升级率阈值后，可以再强制剩余的少量用户升级即可，可以极大的简化软件更新的发布管理。
正式发布软件时，使用release-key密钥对，其中OTA软件包整包用release-key私钥签名，OTA软件包中的recovery子系统保存release-key公钥，后续recovery执行OTA软件包时，使用该公钥校验整包的签名，两者符合则通过，否则报错。
根据本公开的实施例，实现了以下技术效果：
通过服务器将第一OTA软件包发送到recovery保存旧release-key公钥的用户设备，以便对用户设备进行更新，更新后用户设备recovery子系统中的旧release-key公钥更新为新release-key公钥，第一OTA软件包整包使用旧release-key私钥签名，其中的recovery子系统中的公钥替换为新release-key公钥，以实现基于第一OTA软件包中的旧release-key公钥，第一OTA软件包可以被用户设备中的旧release-key公钥的recovery子系统验证通过，并基于第一OTA软件包中的新release-key公钥，对用户设备中的旧recovery子系统进行更新，进而再将第二OTA软件包发送到采用第一OTA软件包更新后的采用新release-key公钥的用户设备，完成对用户设备进行更新，从而达到在密钥发生泄漏的情况下，快速实现对用户设备Android系统的升级，以降低安全隐患，减少运营收入的损失的效果。
在一些实施例中，在Android系统的升级的过程中，可以既包括OTA软件包整包的升级，还包括OTA软件包内部Apk文件的升级。
图4示出了根据本公开的实施例的Android系统的升级的示意图。如图4所示，实线表示旧release-key，虚线表示新release-key；实线箭头表示强制升级；矩形表示整包，小圆表示recovery的release-key公钥，recovery属于整包；矩形外壳实线表示当前的OTA软件包的整包签名为旧release-key的签名，矩形外壳虚线表示当前的OTA软件包的整包签名为新release-key的签名；小圆外壳实线表示recovery支持后续的OTA软件包为旧release-key的签名；小圆外壳虚线表示recovery支持后续的OTA软件包为新release-key的签名；矩形内部填充实心表示Apk文件采用的旧证书的签名；矩形内部填充交叉线表示Apk文件采用的新证书的签名。
图4中所示的3，即旧的OTA软件包版本，其OTA软件包的整包签名为旧release-key的签名，Apk文件采用的旧证书的签名，recovery支持后续的OTA软件包为旧release-key的签名。图4中所示的4A，即过渡的OTA软件包版本，其OTA软件包的整包签名为旧release-key的签名，Apk采用的新证书的签名，recovery支持后续的OTA软件包为新release-key的签名。图4中所示的5，即新的OTA软件包版本，其OTA软件包的整包签名为新release-key的签名，Apk采用的新证书的签名，recovery支持后续的OTA软件包为新release-key的签名。其中，3至4A以及4A至5的升级，均为推进升级。
在Android系统的升级的过程中，3和4A中的Apk功能不同，签名也不同，但是都可以运行，只是存在新证书签名的Apk文件只能在4A上自升级成功，在3上则会失败。基于3至4A的升级使用推荐升级而不是强制升级，这样会出现某些用户设备上升至4A和某些用户设备还是3的并存局面。基于发版管理，这个局面会随着升级的用户设备越来越多，但3低到一定的比例，如20％，升级策略可以调整为强制升级，加快升级过程。4A的整包签名基于旧release-key私钥，所以可以被3的recovery支持，4A的recovery的release-key公钥已经是新release-key公钥，后续的5整包使用新release-key私钥签名即可。另外，Apk文件签名的证书已经切换为新的证书。
在一些实施例中，上述第一OTA软件包内部可以包括一个应用文件，上述第一OTA软件包的生成包括：
解压第三OTA软件包，第三OTA软件包整包签名为旧release-key私钥；
根据预设sharedUserId属性密钥对关系，对第三OTA软件包内部的应用文件的sharedUserId属性进行重签名；
修改recovery子系统中的/res/keys，更新为新release-key公钥；
重新压缩第三OTA软件包，生成第一OTA软件包，第一OTA软件包整包使用旧release-key私钥签名。
在一些实施例中，第三OTA软件包可以是为进行更新前的旧版本的OTA软件包。
在一些实施例中，预设sharedUserId属性密钥对关系可以是根据实际需求设置的。例如，可以设置预设sharedUserId属性密钥对关系为{“system:platform”，“media:media”，“shared:shared”}。
在一些实施例中，上述根据预设sharedUserId属性密钥对关系，对第三OTA软件包内部的应用文件的sharedUserId属性进行重签名包括：
判断第三OTA软件包内部的应用文件的sharedUserId属性是否为system；
若第三OTA软件包内部的应用文件的sharedUserId属性为system，则使用新的platform密钥进行重签名。
在一些实施例中，上述根据预设sharedUserId属性密钥对关系，对第三OTA软件包内部的应用文件的sharedUserId属性进行重签名还包括：
若第三OTA软件包内部的应用文件的sharedUserId属性不为system，则判断第三OTA软件包内部的应用文件的sharedUserId属性是否为media；
若第三OTA软件包内部的应用文件的sharedUserId属性为media，则使用新的media密钥进行重签名。
在一些实施例中，上述根据预设sharedUserId属性密钥对关系，对第三OTA软件包内部的应用文件的sharedUserId属性进行重签名还包括：
若第三OTA软件包内部的应用文件的sharedUserId属性不为media，则判断第三OTA软件包内部的应用文件的sharedUserId属性是否为shared；
若第三OTA软件包内部的应用文件的sharedUserId属性为shared，则使用新的shared密钥进行重签名。
在一些实施例中，可以对已经测试通过的OTA.zip，即第三OTA软件包解压，使用工具，如查看、创建、更新ZIP格式文档附件的软件(Android Asset Packaging Tool，aapt)解析第三OTA软件包中的Apk文件的sharedUserId，按照预设sharedUserId属性密钥对关系来重签名。随后替换recovery子系统中/res/keys的release-key公钥为新release-key公钥，使之后续支持新的release-key私钥签名的软件包。然后对第三OTA软件包进行整体目录压缩，压缩后的第三OTA软件，即第一OTA软件包使用旧的release-key私钥，该包可以被旧的软件包中recovery子系统验证通过。第一OTA软件包升级后，所有Apk文件中sharedUserId为system、media或shared的Apk文件均替换新的签名，且后续支持新的release-key私钥签名的OTA软件包。
在一些实施例中，上述第一OTA软件包内部可以包括多个应用文件，上述第一OTA软件包的生成包括：
解压第三OTA软件包；
遍历多个应用文件，根据预设sharedUserId属性密钥对关系，对第三OTA软件包内部的应用文件的sharedUserId属性进行重签名，直至第一OTA软件包内部的应用文件的sharedUserId属性均完成重签名；
修改recovery子系统中的res/key，更新为新release-key公钥；
重新压缩第三OTA软件包，生成第一OTA软件包。
图5示出了根据本公开的实施例的生成第一OTA软件包的示意图。如图5所示，生成第一OTA软件包，即OTA软件包重制作的步骤包括：步骤1至步骤13。
步骤1：对第三OTA软件包进行解压。
步骤2：判断第三OTA软件包中是否还有Apk文件。
步骤3：若第三OTA软件包中有Apk文件，则读入Apk文件。
步骤4：判断第三OTA软件包中Apk文件sharedUserId属性是否为system。
步骤5：若第三OTA软件包中Apk文件sharedUserId属性为system，则使用新的platform密钥重签，并返回步骤2，即跳转到下一个Apk文件。
步骤6：若第三OTA软件包中Apk文件sharedUserId属性不为system，则判断第三OTA软件包中Apk文件sharedUserId属性是否为media。
步骤7：若第三OTA软件包中Apk文件sharedUserId属性为media，则使用新的media密钥重签，并返回步骤2，即跳转到下一个Apk文件。
步骤8：若第三OTA软件包中Apk文件sharedUserId属性不为media，则判断第三OTA软件包中Apk文件sharedUserId属性是否为shared。
步骤9：若第三OTA软件包中Apk文件sharedUserId属性为shared，则使用新的media密钥重签，并返回步骤2，即跳转到下一个Apk文件。
步骤10：若第三OTA软件包中Apk文件sharedUserId属性不为shared，返回步骤2，即跳转到下一个Apk文件。
步骤11：若第三OTA软件包中没有Apk文件，则修改recovery子系统中的/res/key支持新的release-key公钥，后续可以升级新的release-key私钥签名的OTA软件包。
步骤12：重新压缩第三OTA软件包为第一OTA软件包，即OTA-new.zip。
步骤13：使用旧的release-key私钥对整包进行重新签名，使当前OTA软件包可以被旧的recovery支持。
根据本公开的实施例，通过上述在Android系统的升级的过程中，对OTA软件包整包和OTA软件包内部Apk文件进行升级，可以进一步实现对用户设备Android系统的升级，以降低安全隐患，减少运营收入的损失的效果。
在一些实施例中，第二OTA软件包也替换sharedUserId为system、media、shared等类型的apk文件的签名，其密钥对分别是platform(.pk8,*.x509.pem)、media(.pk8,*.x509.pem)、shared(.pk8,*.x509.pem)，至此完整的更换密钥集，包括release-key、platform、media、shared四个密钥。其中，pk8为私钥，pem为公钥。
在一些实施例中，上述第一OTA软件包的生成还可以包括：
基于源码，生成第一OTA软件包。
在一些实施例中，在对OTA软件包进行重制作的过程，还可以基于源码来构建。
根据本公开的实施例，可以提供另一种OTA软件包重制作的方式，可以进一步实现对用户设备Android系统的升级，以降低安全隐患，减少运营收入的损失的效果。
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本公开并不受所描述的动作顺序的限制，因为依据本公开，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于可选实施例，所涉及的动作和模块并不一定是本公开所必须的。
以上是关于方法实施例的介绍，以下通过装置实施例，对本公开所述方案进行进一步说明。
图6示出了根据本公开的实施例的Android系统的升级装置600的框图。装置600可以被包括在图1的服务器102中或者被实现为服务器102。如图6所示，装置600包括：
第一发送模块610，用于将第一OTA软件包发送到recovery保存旧release-key公钥的用户设备，以便对用户设备进行更新，更新后用户设备recovery子系统中的旧release-key公钥更新为新release-key公钥；第一OTA软件包整包使用旧release-key私钥签名，其中的recovery子系统中的公钥替换为新release-key公钥；
第一发送模块620，用于将第二OTA软件包发送到采用第一OTA软件包更新后的recovery包括新release-key公钥的用户设备，以便对用户设备进行更新，第二OTA软件包整包使用新release-key私钥来签名。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，所述描述的模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
本公开的技术方案中，所涉及的用户个人信息的获取，存储和应用等，均符合相关法律法规的规定，且不违背公序良俗。
根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。
图7示出了可以用来实施本公开的实施例的电子设备700的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
电子设备700包括计算单元701，其可以根据存储在ROM702中的计算机程序或者从存储单元708加载到RAM703中的计算机程序，来执行各种适当的动作和处理。在RAM703中，还可存储电子设备700操作所需的各种程序和数据。计算单元701、ROM702以及RAM703通过总线704彼此相连。I/O接口705也连接至总线704。
电子设备700中的多个部件连接至I/O接口705，包括：输入单元706，例如键盘、鼠标等；输出单元707，例如各种类型的显示器、扬声器等；存储单元708，例如磁盘、光盘等；以及通信单元709，例如网卡、调制解调器、无线通信收发机等。通信单元709允许电子设备700通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
计算单元701可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元701的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元701执行上文所描述的各个方法和处理，例如方法300。
例如，在一些实施例中，方法300可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元708。
在一些实施例中，计算机程序的部分或者全部可以经由ROM702和/或通信单元709而被载入和/或安装到电子设备700上。当计算机程序加载到RAM703并由计算单元701执行时，可以执行上文描述的方法300的一个或多个步骤。备选地，在其他实施例中，计算单元701可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行方法300。
本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。
计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以为分布式系统的服务器，或者是结合了区块链的服务器。
应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。
上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (8)

1.一种Android系统的升级方法，其特征在于，包括：
将第一OTA软件包发送到recovery保存旧release-key公钥的用户设备，以便对用户设备进行更新，更新后用户设备recovery子系统中的旧release-key公钥更新为新release-key公钥；所述第一OTA软件包整包使用旧release-key私钥签名，其中的recovery子系统中的公钥替换为新release-key公钥；
将第二OTA软件包发送到采用所述第一OTA软件包更新后的recovery包括新release-key公钥的用户设备，以便对用户设备进行更新，所述第二OTA软件包整包使用新release-key私钥来签名。
2.根据权利要求1所述的方法，其特征在于，所述第一OTA软件包内部包括应用文件，所述第一OTA软件包的生成包括：
解压第三OTA软件包，所述第三OTA软件包整包签名为旧release-key私钥；
根据预设sharedUserId属性密钥对关系，对所述第三OTA软件包内部的应用文件的sharedUserId属性进行重签名；
修改recovery子系统中的/res/key，更新为新release-key公钥；
重新压缩所述第三OTA软件包，生成第一OTA软件包，所述第一OTA软件包整包使用旧release-key私钥签名。
3.根据权利要求2所述的方法，其特征在于，所述根据预设sharedUserId属性密钥对关系，对所述第三OTA软件包内部的应用文件的sharedUserId属性进行重签名包括：
判断所述第三OTA软件包内部的应用文件的sharedUserId属性是否为system；
若所述第三OTA软件包内部的应用文件的sharedUserId属性为system，则使用新的platform密钥进行重签名。
4.根据权利要求3所述的方法，其特征在于，所述根据预设sharedUserId属性密钥对关系，对所述第三OTA软件包内部的应用文件的sharedUserId属性进行重签名还包括：
若所述第三OTA软件包内部的应用文件的sharedUserId属性不为system，则判断所述第三OTA软件包内部的应用文件的sharedUserId属性是否为media；
若所述第三OTA软件包内部的应用文件的sharedUserId属性为media，则使用新的media密钥进行重签名。
5.根据权利要求4所述的方法，其特征在于，所述根据预设sharedUserId属性密钥对关系，对所述第三OTA软件包内部的应用文件的sharedUserId属性进行重签名还包括：
若所述第三OTA软件包内部的应用文件的sharedUserId属性不为media，则判断所述第三OTA软件包内部的应用文件的sharedUserId属性是否为shared；
若所述第三OTA软件包内部的应用文件的sharedUserId属性为shared，则使用新的shared密钥进行重签名。
6.一种Android系统的升级装置，其特征在于，包括：
第一发送模块，用于将第一OTA软件包发送到recovery保存旧release-key公钥的用户设备，以便对用户设备进行更新，更新后用户设备recovery子系统中的旧release-key公钥更新为新release-key公钥；所述第一OTA软件包整包使用旧release-key私钥签名，其中的recovery子系统中的公钥替换为新release-key公钥；
第二发送模块，用于将第二OTA软件包发送到采用所述第一OTA软件包更新后的recovery包括新release-key公钥的用户设备，以便对用户设备进行更新，所述第二OTA软件包整包使用新release-key私钥来签名。
7.一种电子设备，其特征在于，包括：
至少一个处理器；以及
与所述至少一个处理器通信连接的存储器；
所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-5中任一权利要求所述的方法。
8.一种存储有计算机指令的非瞬时计算机可读存储介质，其特征在于，所述计算机指令用于使所述计算机执行根据权利要求1-5中任一权利要求所述的方法。
CN202310571864.8A 2023-05-19 2023-05-19 Android系统的升级方法、装置、设备以及存储介质 Pending CN117041954A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310571864.8A CN117041954A (zh) 2023-05-19 2023-05-19 Android系统的升级方法、装置、设备以及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310571864.8A CN117041954A (zh) 2023-05-19 2023-05-19 Android系统的升级方法、装置、设备以及存储介质

Publications (1)

Publication Number Publication Date
CN117041954A true CN117041954A (zh) 2023-11-10

Family

ID=88634223

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310571864.8A Pending CN117041954A (zh) 2023-05-19 2023-05-19 Android系统的升级方法、装置、设备以及存储介质

Country Status (1)

Country Link
CN (1) CN117041954A (zh)

Similar Documents

Publication Publication Date Title
US8799662B2 (en) Method and apparatus for validating the integrity of installer files prior to installation
CN108960830B (zh) 智能合约的部署方法、装置、设备及存储介质
US10296728B2 (en) Method and system for providing cloud-based application security service
CN109240731B (zh) 一种TBox的安全升级方法和系统
CN104636666A (zh) 一种用于移动终端进行安全地信息处理的方法和安全装置
CN112269970A (zh) 一种脚本加密方法、装置、服务器及存储介质
CN109063489A (zh) 一种启动方法及装置
CN115795513A (zh) 文件加密和文件解密方法、装置以及设备
WO2022078366A1 (zh) 应用保护方法、装置、设备及介质
US8874927B2 (en) Application execution system and method of terminal
CN111045722B (zh) 智能合约打包方法、装置、系统、计算机设备及存储介质
CN102880478B (zh) 软件更新方法
US11269540B2 (en) Method, apparatus, and computer program product for managing application system
CN114553429A (zh) 基于变色龙哈希的区块链跨链交易方法及装置、存储介质
WO2024040916A1 (zh) Sdk的修复方法、装置、终端、设备、系统及介质
CN111400771A (zh) 目标分区的校验方法及装置、存储介质、计算机设备
CN117041954A (zh) Android系统的升级方法、装置、设备以及存储介质
CN114371863A (zh) 数据处理方法、装置、电子设备及计算机可读存储介质
CN113312073B (zh) 一种安装包文件处理方法和相关装置
CN111125709B (zh) 一种服务器安全漏洞修复方法与装置
CN113609215A (zh) 数据处理方法、装置、设备与计算机可读存储介质
CN101207492A (zh) 避免下载错误文件的文件下载方法及装置
CN105577451A (zh) 云电视系统的升级方法及装置
CN113326055B (zh) 一种设备更新方法及相关装置
JP2019152947A (ja) システム管理装置、システム管理方法、およびプログラム

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination