CN104683303A - App管理方法 - Google Patents

Abstract

本发明公开了一种APP管理方法；其中的APP管理方法包括：智能设备获取需要安装的APP包，计算APP包的文件特征值，并获取所述APP包的标识信息以及APP包的用于防篡改的数字签名；智能设备将所述文件特征值、标识信息以及数字签名传输给软件智能管理系统服务器端，以由软件智能管理系统服务器端利用其存储的所述APP包的用于防篡改的私钥对所述APP包进行有效性校验；智能设备利用所述APP包的用于防篡改的公钥、文件特征值、标识信息以及所述数字签名对APP包进行完整性校验；所述智能设备在所述完整性校验通过，且接收到软件智能管理系统服务器端返回的有效性校验通过信息的情况下，针对所述APP包执行安装操作。

Description

APP管理方法

技术领域

本发明涉及APP管理技术，具体涉及一种APP管理方法。

背景技术

如果根据操作系统对智能设备进行分类，则现有的智能设备主要会被分成四类，即iOS（iphone Operation System）类（即苹果系类）、Andriod类（即安卓系类）、Windows类以及较小的智能平台类。

无论智能设备属于哪种类型，智能设备中安装的应用都会存在被篡改的现象，例如，基于安卓操作系统的应用会被反编译后，添加恶意代码或者添加播放广告功能，使应用被篡改，之后，被篡改的应用被投放到市场中。

发明人在实现本发明过程中发现，现有的对应用进行篡改的行为对应用开发者以及应用使用者均会产生了一定的影响；另外，如果需要将局域网中的某一智能设备中的应用分享给其他智能设备，则往往需要用户对两台智能设备进行操作，手动下载应用，存在操作繁琐以及由于人为错误而不能准确下载的问题；还有，局域网内不同智能设备间进行App数据分享时，需要先在不同的智能设备上均打开应用，之后，进行应用配对，再之后，进行数据传输，用户操作较繁琐。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的APP管理方法和相应的APP管理装置。

依据本发明的一个方面，提供了一种APP管理方法，所述方法包括：智能设备获取需要安装的APP包，计算所述APP包的文件特征值，并获取所述APP包的标识信息以及所述APP包的用于防篡改的数字签名；所述智能设备将所述文件特征值、标识信息以及数字签名传输给软件智能管理系统服务器端，以由所述软件智能管理系统服务器端利用其存储的所述APP包的用于防篡改的私钥对所述APP包进行有效性校验；所述智能设备利用所述APP包的用于防篡改的公钥、文件特征值、标识信息以及所述数字签名对所述APP包进行完整性校验；所述智能设备在所述完整性校验通过，且接收到软件智能管理系统服务器端返回的有效性校验通过信息的情况下，针对所述APP包执行安装操作。

根据本发明的另一方面，提供了一种APP管理装置，其中，所述装置包括：APP识别模块，适于获取需要安装的APP包，计算所述APP包的文件特征值，并获取APP包的标识信息以及APP包的用于防篡改的数字签名；发送模块，适于将所述文件特征值、标识信息以及数字签名传输给软件智能管理系统服务器端，以由所述软件智能管理系统服务器端利用其存储的所述APP包的用于防篡改的私钥对所述APP包进行有效性校验；完整性校验模块，适于利用所述APP包的用于防篡改的公钥、文件特征值、标识信息以及所述数字签名对所述APP包进行完整性校验；APP主动推送模块，用于在所述完整性校验通过，且接收到软件智能管理系统服务器端返回的有效性校验通过信息的情况下，针对所述APP包执行安装操作。

本发明的APP管理方法和装置通过在APP安装前，智能设备请求网络侧对该APP进行有效性验证，并在本地对该APP进行完整性验证，且智能设备在有效性验证和完整性验证均通过的情况下，才进行APP的安装，有效避免了智能设备安装的APP为被篡改后的APP的现象；从而本发明保护了应用开发者的利益，并提高了用户的APP体验。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。说明书附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本发明实施例一的APP管理方法流程图；

图2示出了根据本发明实施例二的APP管理方法的阶段示意图；

图3示出了根据本发明实施例二的APP开发阶段的重新打包过程示意图；

图4示出了根据本发明实施例二的APP开发阶段的重新打包以及APP安装阶段的APP安装过程示意图；

图5示出了根据本发明实施例二的APP安装阶段的完整性校验示意图；

图6示出了根据本发明实施例二的APP包分享示意图；

图7示出了根据本发明实施例二的APP数据分享示意图；

图8示出了根据本发明实施例二的UPnP协议修改示意图；

图9示出了根据本发明实施例三的APP管理装置示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

实施例一、APP管理方法。下面结合图1对本实施例的方法进行说明。

S100、智能设备获取需要安装的APP包，智能设备计算该APP包的文件特征值，并获取该APP包的标识信息以及该APP包的用于防篡改的数字签名。

具体的，在本实施例的方法适用于局域网的情况下，该智能设备通常为局域网内的服务器端，如将家庭中的局域网内的智能数字电视设置为服务器端。上述服务器端可以支持UPnP（通用即插即用）协议，即服务器端可以利用UPnP协议与局域网内的客户端进行信息交互，且该服务器端可以称为UPnP服务器端，而该客户端可以称为UPnP客户端。

智能设备获取需要安装的APP包的方式可以为：作为服务器端的智能设备接收局域网中的其他智能设备传输来的APP包；一个具体的例子，在局域网中的客户端之间需要分享APP包的情况下，客户端（即源客户端）会向服务器端发送APP包分享请求以及APP包，使服务器端从APP包源分享设备（即源客户端）处获取到需要安装至APP包目标分享设备（即目标客户端）的APP包；且该APP包分享请求中可以包含有APP包目标分享设备的信息等信息。

智能设备获取需要安装的APP包的方式也可以为：作为服务器端的智能设备从互联网中的服务器处请求下载APP包；一个具体的例子，在局域网中的客户端之间需要分享APP包的情况下，客户端（即源客户端）会向服务器端发送APP包分享请求，且该APP包分享请求中可以包含有APP包目标分享设备的信息以及该APP包的用于防篡改的数字签名（或者其他可以唯一标识APP包的信息，如APP包的文件名或者APP包名称）等信息，服务器端可以根据该APP包分享请求确定APP包目标分享设备（即目标客户端），且服务器端可以通过与APP包目标分享设备进行信息交互来确定APP包目标分享设备中是否安装有该数字签名对应的APP，在确定出APP包目标分享设备中没有安装该APP的情况下，服务器端向互联网中的相应服务器发送APP下载请求；另一个具体的例子，在局域网中的客户端之间需要分享APP数据的情况下，客户端（即源客户端）会向服务器端发送APP数据分享请求，且该APP数据分享请求中可以包含有APP包目标分享设备的信息以及该APP包的用于防篡改的数字签名（或者其他可以唯一标识APP包的信息，如APP包的文件名或者APP包名称）等信息，服务器端可以根据该APP数据分享请求确定APP数据目标分享设备（即目标客户端），且服务器端可以通过与APP数据目标分享设备进行信息交互来确定APP数据目标分享设备中是否安装有该数字签名对应的APP，在确定出APP数据目标分享设备中没有安装该APP的情况下，服务器端向互联网中的相应服务器发送APP下载请求，以从相应服务器处获取对应的APP。上述APP下载请求中可以承载有APP包的文件名、版本信息以及操作系统类型信息等信息。

本实施例的服务器端中可以存储有局域网中所有客户端中的所有APP的用于防篡改的数字签名，如存储有APP的数字签名与APP包标识信息的对应关系，以便于服务器端可以根据接收到的数字签名识别出相应的APP。

智能设备在获取到APP包之后，应根据该APP包中的APP原始文件计算该APP包的文件特征值，并获取该APP包的标识信息以及该APP包的用于防篡改的数字签名。上述APP包的标识信息可以为APP包名称、APP包的版本信息以及APP包对应的操作系统类别信息等。上述APP包的版本信息以及操作系统类别信息可以从APP包中获取，也可以根据APP包的后缀以及文件属性信息获取（如根据APP包的后缀确定操作系统类别信息，根据文件属性中的版本确定文件属性信息）。同样，上述数字签名可以从APP包中获取，也可以从APP包的文件名中获取（即APP包的文件名包括APP包名称以及数字签名，也就是说，数字签名是APP包的文件名的一部分）。

上述数字签名通常是由软件智能管理系统服务器端预先设置的。一个具体的例子，在APP开发完成后，APP开发人员将APP包上传给软件智能管理系统服务器端，软件智能管理系统服务器端针对该APP包产生用于防篡改的私钥，并针对该APP包中的APP原始文件计算文件特征值，然后，软件智能管理系统服务器端利用该私钥、文件特征值、APP包名称、APP包的版本信息以及该APP包对应的操作系统类别信息进行相应的运算，从而生成该APP包的数字签名。

本实施例中的软件智能管理系统服务器可以利用Hmac技术生成APP包的数字签名，具体的，软件智能管理系统服务器端在接收到APP开发人员上传的APP包后，针对该APP包生成Hmac私钥，并针对该APP包中的APP原始文件计算文件特征值，然后，利用该Hmac私钥、文件特征值、APP包名称、APP包的版本信息以及该APP包对应的操作系统类别信息进行Hmac运算（如利用sha-1散列算法进行运算），从而针对该APP生成数字签名。

在软件智能管理系统服务器端可以对APP开发人员上传的APP包进行重新打包的情况下，软件智能管理系统服务器端可以将其生成的数字签名和APP原始文件一起打包，形成APP包；一个具体的例子，软件智能管理系统服务器端将数字签名设置于防篡改校验文件中，并将该防篡改校验文件以及APP原始文件一起进行打包，形成APP包。

在软件智能管理系统服务器端不能够对APP开发人员上传的APP包进行重新打包的情况下，软件智能管理系统服务器端可以对APP开发人员上传的APP包的文件名进行重命名，使将其生成的数字签名设置于APP包的文件名中；一个具体的例子，软件智能管理系统服务器端将APP包的文件名设置为“APP包名称+下划线+数字签名+后缀”的形式。在本实施例中，不能够对APP包进行重新打包的原因可以为APP原始文件本身的结构以及APP包的原打包方式不能够被软件智能管理系统服务器端重构。

需要特别说明的是，在APP开发人员上传的APP包能够被重新打包的情况下，软件智能管理系统服务器端也完全可以将其计算出的数字签名设置于APP包的文件名中。另外，软件智能管理系统服务器端和局域网中的服务器端应采用相同的计算方式来计算该APP包的文件特征值。

S110、智能设备将文件特征值、标识信息以及数字签名传输给软件智能管理系统服务器端，以由该软件智能管理系统服务器端利用其存储的该APP包的用于防篡改的私钥对该APP包进行有效性校验。

具体的，局域网中的服务器端在接收到需要安装的APP包后，应触发软件智能管理系统服务器端对该APP包进行有效性校验，如服务器端将其计算出的文件特征值、APP包的标识信息以及数字签名等信息承载于有效性校验请求中，并向软件智能管理系统服务器端发送该有效性校验请求。

软件智能管理系统服务器端对该APP包进行有效性校验的过程可以具体为：软件智能管理系统服务器端在接收到有效性校验请求后，根据该有效性校验请求中承载的标识信息在其存储的信息中查找，以获取该APP包对应的私钥（如Hmac私钥），之后，软件智能管理系统服务器端利用该Hmac私钥、有效性校验请求中承载的文件特征值、APP包名称、APP包的版本信息以及该APP包对应的操作系统类别信息进行Hmac运算，从而生成防篡改校验值，如果该防篡改校验值与服务器端传输来的有效性校验请求中承载的数字签名相同，则本次有效性校验通过，否则，本次有效性校验失败；软件智能管理系统服务器端应向局域网中的服务器端返回有效性校验的结果信息，如软件智能管理系统服务器端将结果信息承载于有效性校验响应中返回给服务器端。

S120、智能设备利用该APP包的用于防篡改的公钥、上述计算出的文件特征值、标识信息以及数字签名对该APP包进行完整性校验。

具体的，局域网中的服务器端可以从软件智能管理系统服务器端处获取上述公钥（如Hmac公钥），并利用Hmac公钥对其计算出的文件特征值、APP包名称、APP包的版本信息以及该APP包对应的操作系统类别信息进行Hmac运算（如利用sha-1散列算法进行运算），从而生成防篡改校验值，如果该防篡改校验值与上述S100中服务器端获取到的数字签名相同，则本次完整性校验通过，否则，本次完整性校验失败。

S130、智能设备在完整性校验通过，且接收到软件智能管理系统服务器端返回的有效性校验通过信息的情况下，针对该APP包执行安装操作。

具体的，局域网中的服务器端在确定出该APP包的完整性校验和有效性校验均通过的情况下，执行将该APP包安装于相应的客户端（即目标客户端）中的操作；局域网中的服务器端在确定出该APP包的完整性校验或有效性校验没有通过的情况下，不再执行将APP包安装于相应的客户端中的操作。

在两次校验（即上述远程校验和本地校验）均通过的情况下，服务器端可以自主的执行自动将该APP包安装在相应的客户端中的操作；一个具体的例子，在服务器端接收到APP包分享请求且两次校验均通过的情况下，服务器端立即开始执行自动将该APP包安装在APP包目标分享设备中的操作；另一个具体的例子，在服务器端接收到APP数据分享请求且两次校验均通过的情况下，服务器端立即开始执行自动将该APP包安装在APP数据目标分享设备中的操作。

在两次校验均通过的情况下，服务器端可以在提示用户后，根据用户输入的信息来决定是否执行自动将该APP包自动安装在相应的客户端中的操作；一个具体的例子，服务器端向APP包目标分享设备/APP数据目标分享设备发送是否安装APP包的提示信息，以使APP包目标分享设备/APP数据目标分享设备向用户显示相应的信息，APP包目标分享设备/APP数据目标分享设备在接收到用户输入的表征“安装”或者“不安装”的信息后，将该信息传输给服务器端，服务器端在根据APP包目标分享设备/APP数据目标分享设备返回的信息判断出用户确定需要安装该APP后，立即执行自动将该APP包安装在APP包目标分享设备/APP数据目标分享设备中的操作。

在服务器端接收到来自客户端的APP数据分享请求的情况下，服务器端在将该APP包安装在APP数据目标分享设备中之后，还应触发APP数据目标分享设备中的该APP处于运行状态，从而需要进行APP数据分享的客户端（即发送APP数据分享请求的客户端，源客户端）在接收到服务器端传输来的数据发送准许响应后，向服务器端发送需要分享的APP数据，之后，服务器端将其接收到的APP数据传输给APP数据目标分享设备。

在服务器端接收到APP数据分享请求的情况下，如果APP数据目标分享设备中已经安装了该APP，则服务器端可以不再执行上述APP安装操作，而可以直接触发APP数据目标分享设备中的该APP处于运行状态，并向需要进行APP数据分享的客户端（即发送APP数据分享请求的客户端）发送数据发送准许响应，以使源客户端向服务器端发送需要分享的APP数据，之后，服务器端将其接收到的APP数据传输给APP数据目标分享设备。

需要说明的是，源客户端向服务器端发送的需要分享的APP数据可以是利用其自身存储的相应的数字签名进行了加密处理的APP数据，这样，目标客户端在接收到服务器端传输来的APP数据时，可以利用其自身存储的相应的数字签名对接收到的APP数据进行有效性校验，在有效性校验成功的情况下，再进行后续处理（如存储显示等）；在有效性校验不成功的情况下，可以丢弃其接收到的APP数据。

在使用UPnP协议实现本实施例的方法的情况下，可以对UPnP协议中的“描述”、“事件”以及“表达”进行改进，具体可以参见下述实施例的描述。

由上述实施例的描述可知，本实施例使用了非对称加密方法实现了APP包的防篡改，杜绝了App包被反编译而盗版的现象；本实施例基于UpnP协议简化不同智能设备间分享App包以及APP包数据的操作；本实施例为局域网提供了可以实现APP包分享以及APP数据分享的协议。

实施例二、APP管理方法。下面结合附图2-8对本实施例进行进一步的详细描述。

在本实施例中，APP管理方法可以包括如图2所示的三个阶段。

图2中的第一阶段为APP开发阶段，第二阶段为APP安装阶段，第三阶段为APP分享阶段，其中，在某些应用场合中，APP分享阶段会涉及到APP安装阶段，也可以理解为，APP安装阶段可能会成为APP分享阶段中的一部分。下面对这三个阶段分别进行说明。（答复：APP分享一定是在APP安装的基础上才能实现，因此，APP是属于附加技术特征的）

1、APP开发阶段。

在APP开发完成后，应对APP进行打包处理，如开发人员将APP包上传至软件智能管理系统服务器端，由软件智能管理系统服务器端中的文件防篡改签名生成模块对该APP进行打包处理，以在APP包的内部嵌入防篡改校验文件（也可以称为防篡改识别文件）。该防篡改校验文件的文件格式可以为XML（可扩展标记语言）格式。该防篡改识别文件的文件内容可以包括：APP基本信息、APP对应的智能设备的种类（即APP对应的智能设备的操作系统类型）以及利用非对称加密方法生成的用于防篡改的数字签名（也可以称为防篡改密钥）等。

XML格式的防篡改校验文件的一个具体例子为：

在防篡改校验文件中，cryptographic为用于防篡改的数字签名，即，1921681011518281205752012101812057235182812051782651828120517826为软件智能管理系统服务器端针对该APP包生成的64位的数字签名。

如果软件智能管理系统服务器端接收到的APP包不能被重新打包，则软件智能管理系统服务器端中的文件防篡改签名生成模块会对该APP包进行重新命名，具体的命名的规则可以具体为：App包的原名称+下划线+数字签名+后缀；如APP包的原文件名为“植物大战僵尸.APK”，重新命名后的APP包的文件名为：“植物大战僵尸_03E5C437BA8A40BAF107B208258B59B6.APK”。

软件智能管理系统服务器端中的文件防篡改签名生成模块对APP包进行重新打包的过程如图3以及图4的上部流程所示。

在图3和图4的上部流程中，软件智能管理系统服务器端先针对该APP包生成Hmac密钥（即Hmac私钥）；然后，利用该APP包中的APP原始文件（用于产生APP包的文件特征值）、APP包名称（图3中未示出）、APP包的版本信息以及APP包对应的操作系统类别信息（即图3中的智能设备信息）计算该APP包的Hmac校验值（即用于防篡改的数字签名）；然后，利用APP包名称（图3中未示出）、APP包的版本信息以及APP包对应的操作系统类别信息（即图3中的智能设备信息）以及Hmac校验值生成防篡改校验文件（即用于防篡改的校验文件）；然后，将该防篡改校验文件和APP原始文件一起进行重新打包，生成新的APP包。

2、APP安装阶段。

APP安装过程如图4的下部流程所示。图4中，开始在局域网中的目标客户端安装APP时，智能设备（即局域网中的服务器端）会根据APP包中的APP原始文件的内容计算出该APP包的文件特征值，再将该文件特征值、APP包的名称、智能设备的操作系统类型信息以及数字签名发送到软件智能管理系统服务器端，由该软件智能管理系统服务器端进行APP有效性校验（远程校验）；同时，智能设备在本地使用其计算出的APP包的文件特征值进行防篡改校验（即完整性校验）。在远程校验和本地校验均成功通过之后，智能设备才会执行安装该APP的操作，否则，智能设备会放弃执行该APP的安装操作。

在APP安装阶段，可以由图2所示的防篡改签名校验模块来执行上述远程校验和本地校验。防篡改签名校验模块执行本地校验的具体过程如图5所示。防篡改签名校验模块利用APP包中的APP原始文件计算出APP包的文件特征值，再利用APP名称（图5中未示出）、APP版本信息、目标客户端的操作系统类型信息以及智能设备从软件智能管理系统服务器端获取处的Hmac公钥进行计算，以获得Hmac防篡改校验值，之后，防篡改签名校验模块将该Hmac防篡改校验值与APP包/APP包文件名中的数字签名进行比较，以判断两者是否一致，如果一致，则防篡改签名校验模块输出通过验证的信息，以允许安装该APP包；如果不一致，则防篡改签名校验模块输出未通过验证的信息，以拒绝安装该APP包。

3、APP分享阶段。

APP分享阶段可以包括APP包分享以及APP数据分享。APP包分享即源客户端希望目标客户端中安装APP。APP数据分享即源客户端希望目标客户端中存储有某一APP的数据。

A、APP包分享过程，该过程如附图6所示。

图6中，源客户端使用UPnP协议获取局域网内的智能设备列表，并从该列表中选择需要分享APP包的智能设备（即目标客户端）；源客户端针对需要分享的APP包计算文件特征值，源客户端将需要分享的APP包的用于防篡改的数字签名以及目标客户端的标识信息传输给局域网中的服务器端，该服务器端利用其APP识别模块（如图2所示）根据接收到的数字签名进行APP识别，并根据APP识别结果自动的从相应的服务器处下载对应的APP包，之后，服务器端针对该APP包启动有效性验证和完整性验证，服务器端在判断出本地验证和远程验证均通过的情况下，可以利用其APP主动推送模块（如图2所示）通过目标客户端提示用户是否需要安装该APP，在用户确认安装该APP时，APP主动推送模块自动将该APP包推送给目标客户端，并在该目标客户端中安装该APP包；服务器端中的APP主动推送模块也可以不进行上述提示而自动将该APP包推送给目标客户端，并在该目标客户端中安装该APP包。

由上述描述可知，本实施例在不同智能设备的应用之间进行APP包分享时，用户只需选择局域网内的目标智能设备，之后，局域网中的服务器端可以自动识别出需要安装的应用，并自动下载相应的APP包，且在两校验均通过后，将相应的APP包安装在目标客户端，从而实现了APP分享。

B、APP数据分享过程，该过程如附图7所示。

图7中，源客户端使用UPnP协议获取局域网内的智能设备列表，并从该列表中选择需要分享APP数据的智能设备（即目标客户端）；源客户端针对需要分享的APP数据向局域网中的服务器端发送承载有该APP的用于防篡改的数字签名的数据推送请求，该服务器端利用其APP识别模块（如图2所示）根据接收到的数据推送请求进行APP识别，并根据APP识别结果判断目标客户端中是否安装有相应的APP；如果目标客户端中安装有相应的APP，则信息传输模块触发目标客户端中的相应APP处于运行状态；如果目标客户端中没有安装有相应的APP，则APP识别模块自动的从相应的服务器处下载对应的APP包，之后，服务器端针对该APP包启动有效性验证和完整性验证，服务器端在判断出本地验证和远程验证均通过的情况下，可以利用其APP主动推送模块（如图2所示）通过目标客户端提示用户是否需要安装该APP，在用户确认安装该APP时，该APP主动推送模块自动将该APP包推送给目标客户端，并在该目标客户端中安装该APP包；服务器端中的APP主动推送模块也可以不进行上述提示而自动将该APP包推送给目标客户端，并在该目标客户端中安装该APP包，之后，信息传输模块触发目标客户端中的相应APP处于运行状态；信息传输模块向源客户端传输承载有数据发送准许的回复信息的数据发送准许响应，源客户端接收到该响应后准备需要分享给目标客户端的APP数据，并基于UPnP协议向局域网中的服务器端发送APP数据，服务器端中的信息传输模块将服务器端其接收到该APP数据基于UPnP协议传输给目标客户端。

由上述描述可知，本实施例在不同智能设备的应用之间进行APP数据分享传输时，用户只需选择局域网内的目标智能设备，之后，局域网中的服务器端可以自动识别出需要安装的应用，并判断是需要在目标智能设备中安装应用还是立即运行该应用，之后，源智能设备和目标智能设备之间即可通过服务器端直接进行APP数据传输，从而实现了APP数据分享。

目前，现有的UPnP协议通常包含“寻址”、“发现”、“描述”、“控制”、“事件”以及“表达”六个过程。为了实现上述APP管理技术，本发明对现有的UPnP协议中的“描述”、“事件”以及“表达”进行修改，下面结合图8对本实施例对UPnP协议的修改进行简要说明。

本实施例在“描述”过程中的设备描述文件中添加了用于防篡改的数字签名（如图8中的最右侧的最上面的一个方块所示），经本实施例修改后的设备描述文件的一个具体例子如下：

本实施例可以在“事件”过程新增了“文件分享事件”、“数据传输事件”以及“文件防篡改校验事件”（如图8中最右侧的中间方块所示）；其中，“文件防篡改校验事件”的报文简述的一个具体例子如下：

本实施例中，“表达”过程需要实现“文件防篡改校验功能”、“文件自动传输功能”以及“数据自动传输功能”（如图8中最右侧的最下面方块所示）。上述三个功能的具体实现方法会根据智能设备操作系统的不同而各有差异；例如，在Android操作系统的智能设备中，可以使用Java来实现上述功能，而在IOS操作系统的智能设备中，可以使用Object-C来实现上述功能。具体的实现方式在此不再详细说明。

实施例三、APP管理装置，设置于智能设备中。

在本实施例的装置适用于局域网的情况下，该APP管理装置通常设置于局域网内的服务器端，如在将家庭中的局域网内的智能数字电视设置为服务器端时，该APP管理装置设置于智能数字电视中。上述服务器端可以支持UPnP（通用即插即用）协议，即APP管理装置可以利用UPnP协议与局域网内的客户端进行信息交互，且该APP管理装置所在的服务器端可以称为UPnP服务器端，而该客户端可以称为UPnP客户端。

下面结合图9对该装置进行详细说明。

在图9中，上述APP管理装置主要包括：APP识别模块900、发送模块910、完整性校验模块920以及APP主动推送模块930，该装置还可以包括信息传输模块940；其中，APP识别模块900与发送模块910连接，完整性校验模块920与APP主动推送模块930连接，另外，该APP主动推送模块930还与软件智能管理系统服务器端中的有效性校验模块（图中未示出）连接。上述完整性校验模块920与有效性校验模块一起形成上述实施例二中的防篡改签名校验模块。

APP识别模块900主要适于获取需要安装的APP包，计算该APP包的文件特征值，并获取该APP包的标识信息以及APP包的用于防篡改的数字签名。

具体的，APP识别模块900获取需要安装的APP包的方式可以为：作为服务器端的智能设备接收局域网中的其他智能设备传输来的APP包；一个具体的例子，在局域网中的客户端之间需要分享APP包的情况下，客户端（即源客户端）会向服务器端发送APP包分享请求以及APP包，使APP识别模块900从APP包源分享设备（即源客户端）处获取到需要安装至APP包目标分享设备（即目标客户端）的APP包；且该APP包分享请求中可以包含有APP包目标分享设备的信息等信息。

APP识别模块900获取需要安装的APP包的方式也可以为：作为服务器端的智能设备从互联网中的服务器处请求下载APP包；一个具体的例子，在局域网中的客户端之间需要分享APP包的情况下，客户端（即源客户端）会向服务器端发送APP包分享请求，且该APP包分享请求中可以包含有APP包目标分享设备的信息以及该APP包的用于防篡改的数字签名（或者其他可以唯一标识APP包的信息，如APP包的文件名或者APP包名称）等信息，APP识别模块900可以根据该APP包分享请求确定APP包目标分享设备（即目标客户端），且APP识别模块900可以通过与APP包目标分享设备进行信息交互来确定APP包目标分享设备中是否安装有该数字签名对应的APP，在确定出APP包目标分享设备中没有安装该APP的情况下，APP识别模块900向互联网中的相应服务器发送APP下载请求；另一个具体的例子，在局域网中的客户端之间需要分享APP数据的情况下，客户端（即源客户端）会向服务器端发送APP数据分享请求，且该APP数据分享请求中可以包含有APP包目标分享设备的信息以及该APP包的用于防篡改的数字签名（或者其他可以唯一标识APP包的信息，如APP包的文件名或者APP包名称）等信息，APP识别模块900可以根据该APP数据分享请求确定APP数据目标分享设备（即目标客户端），且APP识别模块900可以通过与APP数据目标分享设备进行信息交互来确定APP数据目标分享设备中是否安装有该数字签名对应的APP，在确定出APP数据目标分享设备中没有安装该APP的情况下，APP识别模块900向互联网中的相应服务器发送APP下载请求，以从相应服务器处获取对应的APP。上述APP下载请求中可以承载有APP包的文件名、版本信息以及操作系统类型信息等信息。

本实施例的服务器端中（如APP识别模块900）可以存储有局域网中所有客户端中的所有APP的用于防篡改的数字签名，如APP识别模块900存储有APP的数字签名与APP包标识信息的对应关系，以便于APP识别模块900可以根据接收到的数字签名识别出相应的APP。

APP识别模块900在获取到APP包之后，应根据该APP包中的APP原始文件计算该APP包的文件特征值，并获取该APP包的标识信息以及该APP包的用于防篡改的数字签名。上述APP包的标识信息可以为APP包名称、APP包的版本信息以及APP包对应的操作系统类别信息等。上述APP包的版本信息以及操作系统类别信息可以从APP包中获取，也可以根据APP包的后缀名以及文件属性信息获取（如APP识别模块900根据APP包的后缀名确定操作系统类别信息，根据文件属性中的版本确定文件属性信息），同样，上述数字签名可以从APP包中获取，也可以从APP包的文件名中获取（即APP包的文件名包括APP包名称以及数字签名，也就是说，数字签名是APP包的文件名的一部分）。

上述数字签名通常是由软件智能管理系统服务器端预先设置的。数字签名的设置方式以及设置位置具体如上述方法实施例中的描述，在此不再详细说明。

发送模块910主要适于将APP识别模块900计算出的文件特征值、获取的标识信息以及数字签名传输给软件智能管理系统服务器端，以由软件智能管理系统服务器端中的有效性校验模块利用软件智能管理系统服务器端存储的APP包的用于防篡改的私钥对该APP包进行有效性校验。

具体的，在局域网中的服务器端中的APP识别模块900接收到需要安装的APP包后，发送模块910通过向软件智能管理系统服务器端传输文件特征值、标识信息以及数字签名来触发软件智能管理系统服务器端中的有效性校验模块对该APP包进行有效性校验，如发送模块910将文件特征值、APP包的标识信息以及数字签名等信息承载于有效性校验请求中，并向软件智能管理系统服务器端发送该有效性校验请求。

软件智能管理系统服务器端中的有效性校验模块对该APP包进行有效性校验的过程可以具体为：在软件智能管理系统服务器端接收到有效性校验请求后，有效性校验模块根据该有效性校验请求中承载的标识信息在软件智能管理系统服务器端存储的信息中查找，以获取该APP包对应的私钥（如Hmac私钥），之后，有效性校验模块利用该Hmac私钥、有效性校验请求中承载的文件特征值、APP包名称、APP包的版本信息以及该APP包对应的操作系统类别信息进行Hmac运算，从而生成防篡改校验值，如果该防篡改校验值与服务器端传输来的有效性校验请求中承载的数字签名相同，则本次有效性校验通过，否则，本次有效性校验失败；有效性校验模块通过软件智能管理系统服务器端应向局域网中的服务器端返回有效性校验的结果信息，如有效性校验模块将结果信息承载于有效性校验响应中，并通过软件智能管理系统服务器端返回给局域网中的服务器端。

完整性校验模块920主要适于利用上述APP包的用于防篡改的公钥、文件特征值、标识信息以及数字签名对该APP包进行完整性校验。

具体的，完整性校验模块920可以从软件智能管理系统服务器端处获取上述公钥（如Hmac公钥），并利用Hmac公钥对上述APP识别模块900计算出的文件特征值、APP包名称、APP包的版本信息以及该APP包对应的操作系统类别信息进行Hmac运算（如利用sha-1散列算法进行运算），从而生成防篡改校验值，如果该防篡改校验值与上述APP识别模块900获取到的数字签名相同，则本次完整性校验通过，否则，本次完整性校验失败。

APP主动推送模块930主要适于在完整性校验模块920的完整性校验通过，且接收到软件智能管理系统服务器端返回的有效性校验通过信息的情况下，针对上述APP包执行安装操作。

具体的，APP主动推送模块930在确定出该APP包的完整性校验和有效性校验均通过的情况下，执行将该APP包安装于相应的客户端（即目标客户端）中的操作；APP主动推送模块930在确定出该APP包的完整性校验或有效性校验没有通过的情况下，不再执行将APP包安装于相应的客户端中的操作。

在两次校验均通过的情况下，APP主动推送模块930可以自主的执行自动将该APP包安装在相应的客户端中的操作；一个具体的例子，在服务器端接收到APP包分享请求且两次校验均通过的情况下，APP主动推送模块930立即开始执行自动将该APP包安装在APP包目标分享设备中的操作；另一个具体的例子，在服务器端接收到APP数据分享请求且两次校验均通过的情况下，APP主动推送模块930立即开始执行自动将该APP包安装在APP数据目标分享设备中的操作。

在两次校验均通过的情况下，本实施例的APP主动推送模块930可以在提示用户后，根据用户输入的信息来决定是否执行自动将该APP包自动安装在相应的客户端中的操作；一个具体的例子，APP主动推送模块930向APP包目标分享设备/APP数据目标分享设备发送是否安装APP包的提示信息，以使APP包目标分享设备/APP数据目标分享设备向用户显示相应的信息，APP包目标分享设备/APP数据目标分享设备在接收到用户输入的表征“安装”或者“不安装”的信息后，将该信息传输给服务器端，APP主动推送模块930在根据APP包目标分享设备/APP数据目标分享设备返回的信息判断出用户确定需要安装该APP后，立即执行自动将该APP包安装在APP包目标分享设备/APP数据目标分享设备中的操作。

信息传输模块940主要适于触发APP数据目标分享设备中对应的APP处于运行状态，并向发送APP数据分享请求的客户端返回相应的数据发送准许响应，该信息传输模块940接收来自客户端的APP数据，并将接收到的APP数据传输给APP数据目标分享设备。

具体的，在服务器端接收到客户端的APP数据分享请求的情况下，APP主动推送模块930在将该APP包安装在APP数据目标分享设备中之后，信息传输模块940还应触发APP数据目标分享设备中的该APP处于运行状态，从而需要进行APP数据分享的客户端（即发送APP数据分享请求的客户端，源客户端）在接收到信息传输模块940传输来的数据发送准许响应后，向服务器端发送需要分享的APP数据，之后，信息传输模块940将其接收到的APP数据传输给APP数据目标分享设备。

在服务器端接收到APP数据分享请求的情况下，如果APP数据目标分享设备中已经安装了该APP，则服务器端中的APP主动推送模块930可以不再执行上述APP安装操作，而可以直接由信息传输模块940触发APP数据目标分享设备中的该APP处于运行状态，并向需要进行APP数据分享的客户端（即发送APP数据分享请求的客户端）发送数据发送准许响应，以使源客户端向服务器端发送需要分享的APP数据，之后，信息传输模块940将源客户端传输来的APP数据传输给APP数据目标分享设备。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书（包括伴随的权利要求、摘要和附图）中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书（包括伴随的权利要求、摘要和附图）中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器（DSP）来实现根据本发明实施例的APP管理装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序（例如，计算机程序和计算机程序产品）。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是，上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。

Claims (12)

1.一种APP管理方法，其包括：

智能设备获取需要安装的APP包，计算所述APP包的文件特征值，并获取所述APP包的标识信息以及所述APP包的用于防篡改的数字签名；

所述智能设备将所述文件特征值、标识信息以及数字签名传输给软件智能管理系统服务器端，以由所述软件智能管理系统服务器端利用其存储的所述APP包的用于防篡改的私钥对所述APP包进行有效性校验；

所述智能设备利用所述APP包的用于防篡改的公钥、文件特征值、标识信息以及所述数字签名对所述APP包进行完整性校验；

所述智能设备在所述完整性校验通过，且接收到软件智能管理系统服务器端返回的有效性校验通过信息的情况下，针对所述APP包执行安装操作。

2.如权利要求1所述的方法，其中，所述智能设备为局域网内的服务器端，且所述获取需要安装的APP包包括：

所述服务器端接收来自局域网内的客户端的APP包分享请求以及APP包；或者

所述服务器端接收来自局域网内的客户端的APP包分享请求，所述服务器端根据所述APP包分享请求确定APP包目标分享设备，且所述服务器端在判断出APP目标分享设备中没有安装对应的APP的情况下，请求下载所述APP包；或者

所述服务器端接收来自局域网内的客户端的APP数据分享请求，所述服务器端根据所述APP数据分享请求确定APP数据目标分享设备，且所述服务器端在判断出APP数据目标分享设备中没有安装对应的APP的情况下，请求下载所述APP包。

3.如权利要求2所述的方法，其中，所述服务器端存储有局域网中各客户端中的APP的数字签名与APP包标识信息的对应关系，且所述APP包分享请求/APP数据分享请求中承载有APP包的数字签名；

所述服务器端根据所述APP包分享请求/APP数据分享请求中承载的APP包的数字签名识别分享对应的APP。

4.如权利要求2所述的方法，其中：

所述服务器端为UPnP服务器端，且所述客户端为UPnP客户端。

5.如权利要求2所述的方法，其中，所述服务器端为智能数字电视。

6.如权利要求2所述的方法，其中，所述针对所述APP包执行安装操作包括：

所述服务器端主动将所述APP包自动安装在所述APP包目标分享设备/APP数据目标分享设备中；或者

所述服务器端通过所述APP包目标分享设备/APP数据目标分享设备提示用户是否安装所述APP包，所述服务器端在接收到用户输入的确认安装信息后，将所述APP包安装在所述APP包目标分享设备/APP数据目标分享设备中。

7.如权利要求6所述的方法，其中，所述方法还包括：

所述服务器端触发所述APP数据目标分享设备中对应的APP处于运行状态，并向发送所述APP数据分享请求的客户端返回数据发送准许响应；

所述服务器端接收来自客户端的APP数据，并将所述APP数据传输给所述APP数据目标分享设备。

8.如权利要求7所述的方法，其中，所述来自客户端的APP数据为利用数字签名加密的APP数据，且所述方法还包括：

所述APP数据目标分享设备利用其存储的数字签名对其接收到的APP数据进行有效性校验。

9.如权利要求1至8中任一权利要求所述的方法，其中，所述数字签名被所述软件智能管理系统服务器端设置于所述APP包中；或者，所述数字签名被所述软件智能管理系统服务器端设置于所述APP包的文件名中；

且所述智能设备从所述APP包中获取所述数字签名，或者，所述智能设备从所述APP包的文件名中获取所述数字签名。

10.如权利要求9所述的方法，其中，所述数字签名设置于用于防篡改的校验文件中，所述校验文件和APP原始文件一起被所述软件智能管理系统服务器端打包为APP包，且所述校验文件为XML格式文件。

11.如权利要求1至8中任一权利要求所述的方法，其中，所述APP包的标识信息包括：APP包名称、APP包的版本信息以及APP包对应的操作系统类别信息。

12.如权利要求1至8中任一权利要求所述的方法，其中，所述用于防篡改的私钥和用于防篡改的公钥包括：用于防篡改的Hmac私钥和用于防篡改的Hmac公钥，且所述软件智能管理系统服务器端针对所述APP包生成Hmac私钥，并根据所述APP包的APP原始文件、所述APP包的标识信息以及所述Hmac私钥利用Hmac运算生成所述数字签名。