iOS中的签名机制

说到签名机制，首先要了解一下 加密解密 ,签名文件就是 加密解密 的过程。

加密 是将明文信息改变为难以读取的密文内容，使之不可读的过程。

解密 是通过特殊的对象，将密文还原为正常可读的内容的过程。而在这个过程中，我们所使用的方法，就是加密解密算法。

加密分为 对称加密 与 非对称加密（公开密钥加密） 。

对称加密就是加密和解密使用的都是同一套密钥

常见的对称密码算法有：

如下图，在使用对称密码时，一定会遇到密钥配送问题， 假设，Alice将使用对称密码加密过的消息发给了Bob， 只有将密钥发送给Bob，Bob才能完成解密， 在发送密钥过程中，可能会被Eve窃取密钥，最后Eve也能完成解密。

加密和解密使用的不是同一个密钥，即为非对称加密算法，也称公开密钥加密；

公钥密码中，密钥分为加密密钥、解密密钥2种，它们并不是同一个密钥， 公钥密码也被称为非对称密码（Asymmetric Cryptography）

在公钥密码中：

加密密钥 ，一般是公开的，因此该密钥称为 公钥 （public key）

解密密钥 ，由消息接收者自己保管的，不能公开，因此也称为 私钥 （private key） 公钥和私钥是一 一对应的，是不能单独生成的，一对公钥和密钥统称为密钥对（key pair）

这样就能 解决秘钥配送的问题 了，如下图：

上图解析：

这其中如果有第三者窃听，只有第2步和第4步能够监听数据，由于Bob公钥是公开的谁都可以获取，那么第二步也不用担心被谁获取，第4步如果数据被第三者截获，那么他看到的也是加密后的数据，由于他没有Bob的私钥，那么他也无法知道消息的真实内容。而且他即使篡改密文消息也无任何意义。

虽然非对称加密解决了密钥配送问题，但是它的加解密速度较慢，下面我们总结一下对称和非对称加密的优缺点：

混合密码 系统，是将对称密码和公钥密码的优势相结合的方法:

为本次通信随机生成的临时密钥； 作为对称密码的密钥，用于加密消息，提高速度

首先，消息发送者要拥有消息接收者的公钥； 生成会话密钥，作为对称密码的密钥，加密消息； 用消息接收者的公钥，加密会话密钥； 将前2步生成的加密结果，一并发给消息接收者。

发送出去的内容包括

用会话密钥加密的消息（加密方法：对称密码）

用公钥加密的会话密钥（加密方法：公钥密码）

1 消息接收者用自己的私钥解密出会话密钥

2 再用第1步解密出来的会话密钥，解密消息

发送过程，加密过程

接收过程，解密过程

1Bob利用自己的私钥解密会话密钥（使用的是公钥密码解密，也就是非对称密码解密）

2Bob利用会话密钥解密发送过来的消息（使用的是对称密码解密）

上面的加密算法解决了数据传输的安全问题，那么 数据的完整性 是没法验证的，就是我这个数据有没有被改过，因为公钥大家都能获取，如果有中间人拦截了消息，并改动了内容。那么我们如何验证这个 消息有没有变动 呢

单向散列函数 ，又称单向 Hash函数 、 杂凑函数 ，就是把任意长的输入消息串变化成 固定长的输出串 且由输出串难以得到输入串的一种函数。这个输出串称为该消息的散列值。一般用于产生消息摘要，密钥加密等

单向散列函数，可以根据根据消息内容计算出散列值 散列值的长度和消息的长度无关 ，无论消息是1bit、10M、100G，单向散列函数都会计算出 固定长度的散列值 。

单向散列函数 ，又被称为 消息摘要函数 （message digest function），哈希函数输出的散列值，也被称为消息摘要（message digest）、指纹（fingerprint）

MD4、MD5 产生128bit的散列值，MD就是Message Digest的缩写，目前已经不安全 Mac终端上默认可以使用md5命令

SHA-1 产生160bit的散列值，目前已经不安全

SHA-2 SHA-256、SHA-384、SHA-512，散列值长度分别是256bit、384bit、512bit

SHA-3 全新标准

不同的数据生成的散列值是不一样的，只要你对一个文件改动过，那么它的散列值就会发生变化，要想确定我们的数据有没有发生变化，只要对比两次散列值相不相同就可以了，我们常常做的登录功能，在保存用户密码的时候就采用单项散列函数生成的值来进行保存，防止第三方人员串改密码。

数据防篡改的技术我们知道了，在数据传输的过程中，我们对数据生成一个散列值，和发送的数据一并发给接收者，当接收者收到这个数据的时候，它拿接收到的数据重新生成散列值，然后跟接收到的散列值进行比较，就可以判断这个数据有没有被人改过。

到此我们通过混合密码技术解决的传输数据的保密性，通过单项散列函数确定数据的一致性，但是还是没有解决 中间人截获篡改 的问题，因为散列函数中间人也可以重新生成一次，接下来我们就要讲数字签名了，他可以对消息发送者的真实性进行认证。

数字签名 （又称公钥数字签名）是只有信息的发送者才能产生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。

它是一种类似写在纸上的普通的物理签名，但是使用了公钥加密领域的技术来实现的，用于鉴别数字信息的方法。一套数字签名通常定义两种互补的运算，一个用于签名，另一个用于验证。数字签名是非对称密钥加密技术与数字摘要技术的应用。

说白了就是用用消息发送者的私钥进行签名就是数字签名

在数字签名中，任何人都可以使用公钥验证签名

在数字签名技术中，有以下2种行为:

生成签名 由消息的发送者完成，通过“签名密钥”生成

验证签名 由消息的接收者完成，通过“验证密钥”验证

数字签名由于是消息发送者的私钥进行签名，消息发送者的私钥只有他自己拥有，别人是没有的，从而我们通过私钥进行签名，别人通过消息发送者的公钥就能确定消息发送者的真实身份。

接下来我们看一下数字签名和公钥密码的对比:

上图Alice将要发送的消息用自己的私钥加密，发送给Bob,Bob用Alice的公钥解密消息，这里其实有一个不好的点，就是如果Alice如果发送的消息比较大，比如发1GB的视频文件，那这个签名过程就太慢了，本身非对称加密的速度就是比较慢的，

下面我们来看一个改进版的:

这里我们将要发送的消息先生成固定大小的散列值，然后再签名，这样签名文件就小的多了，然后我们将消息和签名一同发送该Bob,然后Bob再用公钥解密 对比等。

下面有关数字签名的一些点进行一下说明：

1 如果有人篡改了文件内容或者签名内容，会是什么结果？ 结果是：签名验证失败，证明内容会篡改

2 数字签名不能保证机密性？ 数字签名的作用不是为了保证机密性，仅仅是为了能够识别内容有没有被篡改

3 数字签名的作用

数字签名是能确定消息发送者，前提是你要确定你获取的公钥是确定是消息发送者的，如果你拿到的公钥是中间人伪造的，那么你就无法验证消息发送者的真实性了，就如下图：

[上传中(image-b6d6e1-1614756605461-3)]

A问B要公钥，M从监听到了中间，B给A发的公钥被M拦截了并保存，M把他自己的公钥给了A，A以为这个公钥是B的，A用公钥加密发消息给B，M拦截然后用自己的私钥解密，修改消息内容后，然后用保存的公钥加密把消息发送给B，B解密消息。A,和B都以为是正常通信的，但消息确实不是那个消息了，那么如何确定公钥合法？也就是如何确定这个公钥就是B的呢？

接下来就是我们要讲的证书了，我们引入一个第三方权威机构来认正，说这个公钥就是B的。接下来我们来看一下。

CA是证书的签发机构，它是公钥基础设施（Public Key Infrastructure，PKI）的核心。CA是负责签发证书、认证证书、管理已颁发证书的机关。

CA 拥有一个证书（内含公钥和私钥）。网上的公众用户通过验证 CA 的签字从而信任 CA ，任何人都可以得到 CA 的证书（含公钥），用以验证它所签发的证书,密码学中的证书，全称叫公钥证书（Public-key Certificate，PKC），跟驾驶证类似 里面有姓名、邮箱等个人信息，以及此人的公钥； 并由认证机构（Certificate Authority，CA）施加数字签名。

图已经表示的很清楚了，消息发送者先向CA机构 注册自己的证书，那么任何拿到消息发送者的公钥都可以向CA进行验证公钥的真实性。

首先我们要知道iOS签名机制的作用是什么？

保证安装到用户手机上的APP都是经过Apple官方允许的

不管是真机调试，还是发布APP，开发者都需要经过一系列复杂的步骤：

大致如下图：

[上传中(image-169a4f-1614756605461-0)]

总结：

1、cerSigningRequest文件 ： Mac公钥

2、cer文件：利用Apple私钥（CA）,对Mac公钥生成了数字签名

3、mobileprovision : 利用Apple私钥，对cer证书 + devices + AppID + entitlements进行数字签名

目前我所知道的项目开发中，基本上都是前后端分离的。这就出现了数据传输的问题，前端传给服务器 或者 服务器传给前端的数据都是容易被别人窃取的。这里就要对传输的数据进行加解密，以保证数据安全。

下面介绍两种前后端数据传输的方式

前后端约定一个key,将请求参数按照字母排序拼接成一个字符串（通常都是ASCll排序），然后拼接上key,最后用MD5或者SHA进行加密，得到一个加密的签名sign，再把sign作为最后一个参数传到服务端。

服务端拿到前端传过来的结果之后，也将参数(排除sign)按照顺序拼接成一个字符串，再拼接上key，再用MD5或者SHA进行加密，也得到了一个新的sign，服务端比较这两个sign，如果相同就说明传回来的数据没有问题，如果不相同，说明数据被串改了。

例如：

传递的参数是

id=5&age=10

现在通过加签 应该传递的参数为

id=5&age=10&sign=MD5(age=10&id=5)

服务端拿到的就是

id=5&age=10&sign=MD5(age=10&id=5)

服务端经过筛选参数，得到 id=5&age=10 ，然后进行排序得到 age=10&id=5 ,再MD5得到sign，两个sign进行比较

目前我知道的根据秘钥的使用方法，可以将密码分为两种

在对称密码中，加密、解密时使用的是同一个密钥，我们常用的AES算法就是对称密码算法。具体AES算法大家自己百度就好了

但是通常使用对称密码时，就会有秘钥配送问题。

例：发送者A将使用对称密码加密过得信息发送给接收者B，只有将秘钥发送给接收者B，B才能进行解密，这里A发送秘钥给B的过程中，就容易被别人窃取秘钥，别人拿着秘钥也能进行解密。

如何解决秘钥配送问题

我知道的几种解决方法

公钥密码

公钥密码中，密钥分为加密密钥、解密密钥2种，它们并不是同一个密钥。

目前使用最广泛的公钥密码算法是RSA

加密密钥，一般是公开的，因此该密钥称为公钥（public key）

解密密钥，由消息接收者自己保管的，不能公开，因此也称为私钥（private key）

公钥和私钥是一 一对应的，是不能单独生成的，一对公钥和密钥统称为密钥对（key pair）

由公钥加密的密文，必须使用与该公钥对应的私钥才能解密

由私钥加密的密文，必须使用与该私钥对应的公钥才能解密

1由消息的接收者，生成一对公钥、私钥

2将公钥发给消息的发送者

3消息的发送者使用公钥加密消息

混合密码系统

不能很好地解决密钥配送问题

加密解密速度比较慢

混合密码系统，是将对称密码和公钥密码的优势相结合的方法，解决了公钥密码速度慢的问题，并通过公钥密码解决了对称密码的密钥配送问题

会话密钥（session key）为本次通信随机生成的临时密钥，作为对称密码的密钥，用于加密信息，提高速度

发送出去的内容包括

前端A >>>>> 服务器端B

发送过程，加密过程

接收过程，解密过程

文章参考了 猿天地的再谈前后端API签名安全？ 和李明杰的底层原理iOS签名机制

乐橙目前这几款智能锁都是有临时密钥的功能的,百度答主回答您。你可以从乐橙APP中的设置里面下划，能看见有个临时密钥的功能，不仅可以限定临时工上门的时间，还可以选择单次使用或者多次使用，经过验证码认证后系统会自动生成一串临时密钥，让临时工在规定的时间内用这个密码就行。

以上就是关于iOS中的签名机制全部的内容，包括:iOS中的签名机制、前后端分类，数据传输问题、我记得乐橙视频锁是可以设置临时密钥的吧家里请了临时工，但是又不想暴露自己家的密码，要怎么整等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！