显示某些数据以指示我批准（命名）数据，然后将其发送给其他人。其他人可能知道此数据已由他们自己进行了身份验证，并且尚未被篡改。

首先，使用一种算法来计算原始数据的摘要。必须满足如果原始数据有任何变化，则计算出的汇总值将发生变化。 b。摘要应该足够简短。此处最常用的算法是MD5。

它生成用于非对称加密的公钥和私钥。按住您的私钥并发布您的公钥。

对于一条数据，在计算摘要之后，您可以使用私钥对摘要进行加密以获得加密的数据，这称为原始数据签名。将其与原始数据一起发送给用户。

用户接收到数据和签名后，便使用公共密钥对其进行解密以获得摘要。同时，用户使用相同的算法来计算原始数据的摘要，并将此处计算的摘要与通过使用公钥解密签名获得的摘要进行比较。如果它们相同，则数据未被篡改。如果损坏，则总结为实物

让我们看看什么是苹果的签名机制。在iOS发行之前，在主流操作系统（Mac/Windows/Linux）上开发和运行软件不需要签名。由于该软件可以在任何地方下载，因此该平台很难控制第三方软件，并且盗版变得很流行。苹果希望解决此问题。您可以完全控制iOS平台上的第三方应用程序。您需要确保iOS上安装的所有应用均已得到Apple的正式批准。您如何保证？通过签名机制。

您在Mac开发计算机上生成了一对称为公钥L和私钥L的公钥和私钥。本地

苹果本身具有固定的公钥和私钥对。与上面的AppStore示例一样，私有密钥位于Apple的后端，公共密钥位于每个iOS设备上。这些称为公钥A和私钥A。苹果

将公钥L传递到Apple后端，并使用Apple后端的私钥A签名公钥L。获得的数据包含公钥L及其签名，该数据称为证书。

通过在Apple后台申请AppID，配置可在APP中使用的设备ID和权限列表，在步骤③中配置证书，使用私钥A对配置的数据进行签名，将数据和签名结合在一起，在本地下载的配置文件文件来形成。 Mac开发机。

在开发过程中编译APP后，用本地私钥L对APP签名，并将步骤④中获得的Provisioning Profile文件打包到APP中，文件名为embed.mobileprovision，并将APP安装在手机上。在安装过程中，iOS系统会获取证书，通过系统中内置的公钥A验证embed.mobileprovision的数字签名是否正确，然后重新验证内部证书签名。

在确认Embedded.mobileprovision中的数据已被Apple批准后，您可以取出内部数据并执行各种验证，例如使用公钥L检查APP签名，确认设备ID在ID列表中以及确认AppID与此相对应。权限开关是否对应于应用程序的权限等。

苹果从签名到对开发人员证书进行身份验证所采用的过程几乎相同，其中有一些细节，例如证书/证书类型有效的时间。我不会详细介绍。

概念与运作

上面的步骤通常对应于特定的任务和概念，例如：

步骤1对应于钥匙串中的“从证书颁发机构请求证书”。在此，本地生成公用和专用密钥对。存储的CertificateSigningRequest是公用密钥，而专用密钥存储在本地计算机上。

步骤2苹果处理，请放心。

步骤3对应于生成证书并通过将CertificateSigningRequest传递到Apple后端在本地下载证书。此时，本地有两个证书，一个是在步骤1中生成的，另一个是从此处下载的。钥匙串连接这两个证书，因为公钥和私钥匹配。实际上，如果选择通过XCode下载的证书，则可以对钥匙串中的相应私钥进行签名。此处的私钥只能由生成私钥的Mac使用。如果我也需要在另一台Mac上编译并签名此应用程序怎么办？答案是将私钥导出到另一台Mac。导出钥匙串的私钥时，它会另存为.p12文件。其他Mac打开私钥并将其导入。

第四步是在Apple网站上工作，配置AppID /权限/设备等，然后最终下载Provisioning Profile文件。

步骤5 XCode在步骤3中下载证书（存储在公共密钥中），在本地找到对应的私有密钥（在第一步中生成），并使用本地私有密钥，供应配置文件的名称对应用程序进行签名指定。 Embedded.mobileprovision打包在一起。存储应用程序的签名数据分为两部分，Mach-O可执行文件将签名直接写入此文件，其他资源文件存储在_CodeSignature目录中。Xcode和iOS系统自动完成步骤6-7中的打包和验证。

以下是这些概念的摘要。

证书：内容是公钥或私钥，是一个数据包，其中包含来自其他机构的签名。

权限：包含应用程序权限开关的列表。

CertificateSigningRequest：本地公钥。

p12：可以导入到另一台计算机的本地私钥。

供应配置文件：数据包，其中包含诸如证书/授权机构之类的数据，并使用Apple的后端私钥签名。