简介

Token结构体是访问权限检查中的代表主体身份的核心数据结构，Windows 10 x64平台下的结构见最后。

我们比较关注其中的特权位图和三个代表主体身份的Sid数组：UserAndGroups，RestrictedSids，Capabilities。

 

进程主令牌和模拟令牌

每一个进程有一个主要的令牌，它描述了与当前进程相关的用户帐户的安全上下文。默认情况下，系统用主令牌当一个进程的线程与一个安全对象相互作用时。此外，一个线程可以模拟一个客户端帐户。模拟允许此线程与安全对象交互时用客户端的安全上下文。一个正模拟客户端的线程拥有一个主令牌和一个模拟令牌。

用函数：OpenProcessToken 来接收一个指向一个进程的主令牌句柄。用OpenThreadToken函数来得到一个指向线程模拟令牌的句柄。

Privileges位图

特权在用户态是通过LUID来表示，在内核结构体_TOKEN中是使用三个位图来表示:

kd> dt _SEP_TOKEN_PRIVILEGES

nt!_SEP_TOKEN_PRIVILEGES

+0x000 Present          : Uint8B

+0x008 Enabled          : Uint8B

+0x010 EnabledByDefault : Uint8B

分别代表当前的主体可以选用的特权集合(Present)、已经打开的特权集合(Enabled)和默认打开的特权集合(EnabledByDefault)，后两个集合应该是Present集合的子集。

与代表主体身份的Sid数组不同，特权集合的表示简单，而且没有任何保护。从用户态通过API只能打开或者关闭某一项已经存在的特权，而不能增加可选的特权，换句话说，用户态只能修改Enabled特权集合，而不能修改Present特权集合;从内核态可以直接修改Present特权集合，比如给普通进程增加SeAssignPrimaryTokenPrivilege特权，以便为子进程显式指定令牌，而不是继承当前进程的令牌，可以达到扩大子进程权限的效果。

代表主体身份的Sid数组

三个代表主体身份的Sid数组分别是：

UserAndGroups：

代表着主体的普通用户身份和组身份，是不可或缺的成员;

RestrictedSids：

可选成员，如果不为空，则代表着当前的令牌是受限令牌，受限令牌通过从普通令牌中过滤掉一些比较敏感的身份转化而来，受限令牌中的UserAndGroups成员与普通令牌相同，但是RestriectedSids成员不为空，里面保存着过滤后的身份子集;由于在访问权限检查时，三个身份Sid数组要同时进行检查，只有结果都通过才允许该次访问，因此通过增加代表着受限制的权限集合的RestrictedSids成员，既达到了限制令牌权限的目的，又在UserAndGroups成员中保留了原有令牌的完整身份信息。

Capabilities:

可选成员，仅用于AppContainer，其中的Sid代表着与App相关的身份，比如拥有连接网络、访问当前位置等权限的身份。

这三个Sid数组都关联了哈希信息，以保护其完整性，因此，即使从内核态直接修改，也会因为无法通过完整性验证而失败。不过好在哈希的算法非常简单，下面展示的就是Windows 10 x64平台下面该算法的C++演示代码：浅析Windows的访问权限检查机制 – 绿盟科技技术博客

UAC与关联令牌

当用户登录Windows时，操作系统会为用户生成一对初始令牌，分别是代表着用户所拥有的全部权限的完整版本令牌(即管理员权限令牌)，以及被限制管理员权限后的普通令牌，二者互为关联令牌;此后，代表用户的进程所使用的令牌都是由普通令牌继承而来，用来进行常规的、非敏感的操作;当用户需要进行一些需要管理员权限的操作时，比如安装软件、修改重要的系统设置时，都会通过弹出提权对话框的形式提示用户面临的风险，征求用户的同意，一旦用户同意，将会切换到当前普通令牌关联的管理员权限令牌，来进行敏感操作。通过这种与用户交互的方式，避免一些恶意程序在后台稍稍执行敏感操作。

关联令牌是通过Logon Session来实现的，下图展示了其大致原理：

 

Token结构

下面展示的是Windows 10 x64平台下的构成。

kd> dt nt!_TOKEN
   +0x000 TokenSource      : _TOKEN_SOURCE
   +0x010 TokenId          : _LUID
   +0x018 AuthenticationId : _LUID
   +0x020 ParentTokenId    : _LUID
   +0x028 ExpirationTime   : _LARGE_INTEGER
   +0x030 TokenLock        : Ptr64 _ERESOURCE
   +0x038 ModifiedId       : _LUID
   +0x040 Privileges       : _SEP_TOKEN_PRIVILEGES
   +0x058 AuditPolicy      : _SEP_AUDIT_POLICY
   +0x078 SessionId        : Uint4B
   +0x07c UserAndGroupCount : Uint4B
   +0x080 RestrictedSidCount : Uint4B
   +0x084 VariableLength   : Uint4B
   +0x088 DynamicCharged   : Uint4B
   +0x08c DynamicAvailable : Uint4B
   +0x090 DefaultOwnerIndex : Uint4B
   +0x098 UserAndGroups    : Ptr64 _SID_AND_ATTRIBUTES
   +0x0a0 RestrictedSids   : Ptr64 _SID_AND_ATTRIBUTES
   +0x0a8 PrimaryGroup     : Ptr64 Void
   +0x0b0 DynamicPart      : Ptr64 Uint4B
   +0x0b8 DefaultDacl      : Ptr64 _ACL
   +0x0c0 TokenType        : _TOKEN_TYPE
   +0x0c4 ImpersonationLevel : _SECURITY_IMPERSONATION_LEVEL
   +0x0c8 TokenFlags       : Uint4B
   +0x0cc TokenInUse       : UChar
   +0x0d0 IntegrityLevelIndex : Uint4B
   +0x0d4 MandatoryPolicy  : Uint4B
   +0x0d8 LogonSession     : Ptr64 _SEP_LOGON_SESSION_REFERENCES
   +0x0e0 OriginatingLogonSession : _LUID
   +0x0e8 SidHash          : _SID_AND_ATTRIBUTES_HASH
   +0x1f8 RestrictedSidHash : _SID_AND_ATTRIBUTES_HASH
   +0x308 pSecurityAttributes : Ptr64 _AUTHZBASEP_SECURITY_ATTRIBUTES_INFORMATION
   +0x310 Package          : Ptr64 Void
   +0x318 Capabilities     : Ptr64 _SID_AND_ATTRIBUTES
   +0x320 CapabilityCount  : Uint4B
   +0x328 CapabilitiesHash : _SID_AND_ATTRIBUTES_HASH
   +0x438 LowboxNumberEntry : Ptr64 _SEP_LOWBOX_NUMBER_ENTRY
   +0x440 LowboxHandlesEntry : Ptr64 _SEP_LOWBOX_HANDLES_ENTRY
   +0x448 pClaimAttributes : Ptr64 _AUTHZBASEP_CLAIM_ATTRIBUTES_COLLECTION
   +0x450 TrustLevelSid    : Ptr64 Void
   +0x458 TrustLinkedToken : Ptr64 _TOKEN
   +0x460 IntegrityLevelSidValue : Ptr64 Void
   +0x468 TokenSidValues   : Ptr64 _SEP_SID_VALUES_BLOCK
   +0x470 IndexEntry       : Ptr64 _SEP_LUID_TO_INDEX_MAP_ENTRY
   +0x478 VariablePart     : Uint8B

欢迎关注我的微博：大雄_RE。专注软件逆向，分享最新的好文章、好工具，追踪行业大佬的研究成果。

BLE安全机制从入门到放弃

原文作者： Jayden Huang
原文链接： https://jaydenh215.github.io/2019/05/14/BLE安全机制从入门到放弃/

---

网上介绍BLE安全机制的文章大多只关注业务概念，如：配对加密是什么，绑定过程是什么；而忽略了其中涉及到的信息安全知识，如：使用了加密和认证有什么用，不用又会怎么样。让新人读了有种云里雾里，知其然而不知其所以然的感觉。这里结合涉及到的信息安全知识，换一个角度来认识BLE安全机制。

前言

标题中的“放弃”有点调侃的意思，是指读者在读完之后，可以不依赖别人，靠自己读蓝牙核心规范加深认识，这样收获也会更多，也是这篇博文的目标。
为了易于理解，会对蓝牙核心规范的算法进行裁剪，但是原理是不变的，标准算法应参考蓝牙核心规范。
最后，这是博主的一得之见，欢迎各位指正。

目录

• 密码技术初探
  • 对称密码
  • diffie-hellman密钥交换算法
  • 椭圆曲线diffie-hellman密钥交换算法
  • 消息认证码
  • 认证加密CCM
  • 信息安全小结
• ble安全机制初探
  • ble40安全机制
  • ble42安全机制
• 总结
• 参考资料

密码技术初探

在介绍密码技术之前，我们先给参与信息交互的对象赋予名称，方便举例和记忆。
下图是重要角色一览表：

Alice和Bob分别是两家银行，Bob银行通过网络向Alice银行发送了一条500元的汇款请求：从账户B-6789向账户A-1234汇款500元。

当然，会有人在网络中尝试攻击银行间通信，妄想用非法手段牟利，其中就有这样一个分工明确的组织，由以下成员组成：

• Eve
  • 窃听不同银行之间的消息，从中获取重要信息，如获知“从账户B-6789向账户A-1234汇款500元”。
• Mallory：
  • 篡改不同银行之间的消息，如修改汇款请求为“从账户B-6789向账户A-1234汇款5000000元”。
  • 伪装成Bob银行，以Bob银行名义发送一条新的汇款请求给Alice银行。

从上述例子可知消息面临的威胁有：窃听、篡改和伪装，对应的安全特性为：机密性、一致性、是否已认证。

“威胁”和“安全特性”的关系可以这样描述：

• 如果消息没有加密，消息则不具有机密性，无法防止他人窃听；
• 如果发送者发送的消息和接收者的消息是不同的，说明消息被篡改过，不具有一致性；
• 如果没有对消息进行认证，无法保证消息来自正确发送者而不是伪装者。

存在威胁，就会有对应的解决方法，下面会针对每个威胁介绍对应的密码技术。

对称密码

算法一般指复杂步骤，加密算法指的是用明文生成密文的步骤，解密的步骤称为解密算法，两者统称为密码算法，密码算法需要用到密钥。

所谓对称密码（symmetric cryptography）技术，即加密和解密时用的是同一个密钥，加密和解密的算法一般是公开的，如AES128。
对称密码应用图：

对称密码解决的问题

如上图所示

1. Bob创建一条汇款请求消息；
2. 用密钥key对它加密；
3. 将加密后的消息发给Alice；
4. Alice收到密文；
5. Eve窃听到了加密后的消息，由于没有密钥key，无法解读内容；
6. Alice用密钥key对消息解密；
7. Alice获得一条汇款请求消息。

对称密码技术可以解决窃听的威胁。

对称密码无法解决的问题

对称密码技术可以解决窃听的威胁，但是有一个前提，就是在这之前发送者和接收者要有相同的密钥key，所以一定要先给接收者配送密钥，有以下几种方式：

1. Bob通过网络先将key发送给Alice，但容易被Eve截取到；
2. Bob乘坐交通工具将密钥key亲手交给Alice，或者其他网络以外的方式配送密钥，这种方式成本高维护麻烦，称为带外（Out-Of-Band）配送；
3. 用diffie-hellman密钥交换算法解决；
4. 用椭圆曲线diffie-hellman密钥交换算法解决。

diffie-hellman密钥交换算法

先不管DH密钥交换算法是什么，我们现在关注问题是：在Eve窃听网络的情况下，如何解决Bob配送key给Alice的问题？

密码界的前辈们从数学角度上找到了答案：利用这个数学难题，Bob和Alice可以在Eve窃听的情况下，协商出一个密钥，而Eve不知道密钥是什么。

最好解决配送问题的办法就是不配送，通过协商获得相同的密钥，是不是很神奇，话不多说，我们看看是怎么实现的。

离散对数问题

背景知识：mod符号表达的意思是求余数，如表达式5 mod 7的计算思路为：5除以7等于0，余数为5，所以5 mod 7 = 5。

现有离散对数问题如下，请问满足公式的x是多少：

为了求x，我们可以运用上面提到的背景知识来做计算，像下面这样依次尝试一遍，就可以得到x = 9。

例子的数字较小，所以很快就找到答案了，当数字很大时，计算x就会变得非常耗时，快速求出离散对数的算法到现在还没被发现，所以可以得到这样的一个简单结论：

对于上图公式，已知G、p、Y的时候，很难求出x。

接下来我们看看如何具体利用这个数学问题来协商出密钥的。

diffie-hellman密钥交换算法应用

在DH中，我们将Y称为公钥（public key），将x称为私钥（private key），则有以下结论：已知G、p、公钥的时候，很难求出私钥。

如上图所示

1. Bob和Alice选择一个公开的G和p，Eve当然也知道这个公开的G和p；
2. Bob和Alice分别随机生成各自的私钥sb和sa；
3. Bob和Alice根据G、p以及各自的私钥，生成公钥pb和pa；
4. Bob和Alice互发公钥pb和pa，Eve窃听到了pb和pa；
5. Bob和Alice计算出共享密钥DHkey。

Eve能计算出DHkey吗？

对比三个角色最后的“已知信息”可知，只要Eve知道任一私钥（sb或sa），它就能容易算出DHkey，而这时候问题就变成了：Eve在已知G、p、公钥情况下，是否能求出私钥，这也就是我们上面提到的离散对数问题，这是很难做到的。

diffie-hellman密钥交换算法解决的问题

因为DH密钥交换算法利用了“离散对数问题”的复杂度，所以就算Eve一直窃听，Bob和Alice也能协商出一个共享密钥，而Eve却因为复杂的数学问题而没办法算出共享密钥，也就解决了对称密码中的配送问题。

椭圆曲线diffie-hellman密钥交换算法

DH是利用了“离散对数问题”的复杂度来实现密钥的安全交换的，如果将“离散对数问题”改为“椭圆曲线上的离散对数问题”，这样的算法就叫椭圆曲线diffie-hellman密钥交换（ECDH）。

两者密钥交换总体流程相同，只是利用的数学问题不同而已，ECDH能够用较短的密钥长度实现较高的安全性。

椭圆曲线diffie-hellman密钥交换算法应用

ECDH中的数学问题可以这样简单定义：

已知椭圆曲线上的点Y、基点G的时候，很难求出x。其中算术符号*表示的不是普通的乘法，而是一种在椭圆曲线上的特殊算法。

在ECDH中，我们称Y为公钥（public key），x为私钥（private key）。

如上图所示

1. Bob和Alice选择一条密码学家推荐的椭圆曲线，选择曲线上的一个基点G；
2. Bob和Alice分别随机生成各自的私钥sb和sa；
3. Bob和Alice根据G以及各自的私钥，生成公钥pb和pa；
4. Bob和Alice互发公钥pb和pa，Eve窃听到了pb和pa；
5. Bob和Alice计算出共享密钥DHkey。

椭圆曲线diffie-hellman密钥交换算法无法解决的问题

DH和ECDH都能解决密钥配送问题，结合对称密码技术，就能保证消息的机密性，防止被窃听了，但是对于篡改和伪装的攻击，却无能为力。为了解决剩下这两个威胁，就要靠其他技术手段了。

如上图所示，Mallory不需要知道密文是什么意思，但是他可以修改密文，导致Alice解密出预期以外的内容。

如上图所示，Mallory夹在Bob和Alice之间并伪装他们。对于Mallory来说，DHkey是赤裸裸的，所以Bob和Alice互发的消息是没有机密性的，这种攻击也称为中间人攻击（MITM）。

消息认证码

消息认证码（MAC）技术是检查信息一致性并进行认证的技术，发送者通过MAC算法可以输出一个MIC值，接收者通过校验MIC值不仅可以判断消息一致性，还能判断消息是否来自正确的发送者。

MAC技术有以下几种重要性质：

• 正向快速：给定明文、MAC算法和密钥key，在有限时间和有限资源内能计算出MIC。
• 逆向困难：给定MIC、MAC算法和明文，在有限时间内很难（基本不可能）逆推出密钥。
• 输入敏感：原始输入信息修改一点信息，产生的MIC看起来应该都有很大不同。
• 冲突避免：很难找到两段内容不同的明文，使得它们的MIC一致（发生冲突）。即对于任意两个不同的数据块，其MIC相同的可能性极小；对于一个给定的数据块，找到和它MIC相同的数据块极为困难。

MAC技术与对称加密技术有一个显著差异：加密解密是双向的，可以互相推导，而认证只能单向；加密是为了解密，MAC设计是无法解。

消息认证码解决的问题

消息经过CMAC算法之后，为何Mallory无法篡改消息和伪装呢？
消息一致性检查和认证示意图：

• Mallory如果想篡改明文，那就同时也要篡改MIC，否则无法通过Alice的校验，但是应该将MIC改成多少呢？因为Malloyr没有共享密钥，所以他也不知道MIC应该是什么。如果想篡改MIC，那就同时也要篡改明文才能通过Alice的校验，由于MAC算法的逆向困难性质，Mallory不知道明文应该是什么。

• Bob用CMAC算法认证一条消息并发给Alice，并要求Alice也用CMAC算法认证并返回一条消息给Bob。若Mallory伪装成Alice，由于没有认证密钥，无法返回通过Bob校验的消息。

消息认证码无法解决的问题

没错，要使用MAC技术，首先要有相同的认证密钥，又回到了之前的密钥配送问题，具体这里采用哪种方式解决配送密钥问题，视实际情况而定。

消息认证码攻击方式

对于MAC算法来说，应保证不能根据MIC和明文推测出通信双方所使用的密钥。但实际上用穷举法是可以推测出来的，如果使用密码学安全的、高强度的伪随机数生成器生成密钥，就会使得破解时间需要很长以至在现实中几乎不可能破解。而如果密钥是人为选定的，就会大大增加被推测出来的风险。

认证加密CCM

其实上文一直在有意无意的强调一个事情，那就是加密和认证是独立的两个概念。加密能防止窃听，认证能防止篡改和伪装。前辈们用一种密码技术将两者融合起来——CCM（Counter with CBC-MAC）。

通过查阅资料，以我的战五渣水平只能理解到这一程度：

• 发送方先对明文使用MAC技术，然后对称加密成密文；
• 接收方先用对称加密技术解密密文，然后用MAC技术校验明文；
• 发送方和接收方需要至少一个共享随机数和一个共享密钥，随机数可以公开，密钥不可以公开。
  
  上图只是个人猜测的CCM应用示意图，有可能是不对的，因为不是术业专攻方向，没有深入研究，秉着求真精神，觉得应该提醒大家，避免误导。

放上图的目的是：加密和认证可以做在一个算法中，而且BLE就是这么用的。

信息安全小结

威胁、安全特性、密码技术关系图：

总结：

• 为了解决窃听问题，采用对称密码技术；
• 为了解决对称密码技术的加密密钥配送问题，采用配送密钥技术；
• 为了解决篡改问题，采用消息认证码技术；
• 为了解决伪装问题，采用消息认证码技术；
• 为了解决消息认证码技术的认证密钥配送问题，采用配送密钥技术。

Tips：无论消息认证码技术还是对称密码技术，都需要用到配送密钥技术，而不同的配送密钥技术本身，也会涉及到认证强度的问题。比如希望用ECDH来解决消息认证码的认证密钥配送问题，但是ECDH本身认证强度为零，所以它也需要消息认证码技术来证明ECDH过程中没有出现篡改或者伪装攻击，即又要使用消息认证码技术，导致进入了死循环。所以需要选择合适的密钥配送技术，常见的有：邮箱验证码、手机短信验证码、NFC、目测法等。

ble安全机制初探

在介绍ble安全机制之前，我们先给参与信息交互的对象赋予名称，方便举例和记忆。
ble重要角色一览表：

背景知识：简单来说ble设备可分为两种角色，一种是主机角色（master），另一种是从机角色（slave），有以下几种差异：

1. 建立连接前

• 主机能进入扫描状态、发起连接状态，不能进入广播状态；

• 从机能进入广播状态，不能进入扫描状态和发起连接状态；

• 一定是由主机发起连接，从机只能被连接。
  2. 建立连接后

• 一定是由主机发起配对，但是从机能够请求主机发起配对；
  ble各个状态示意图：
  

• 广播状态：设备正在往空中发送广播包，谁都可以收得到；

• 扫描状态：设备正在接收空中的广播包，看看谁在发，发什么；

• 发起连接状态：设备指定与另外一个设备发起连接；

• 明文数传阶段：两个已连接设备之间，用明文传送数据包；

• 配对阶段：两个已连接设备之间，运用密码技术生成各种安全强度的密钥；

• 加密过程：两个已连接设备之间，使用配对阶段输出的密钥，或者绑定阶段提供的密钥，衍生出最终用于加密底层数据包的密钥；

• 密文数传阶段：两个已连接设备之间，用密文传送数据包；

• 绑定阶段：用“绑定”这个词特定描述配对阶段中的第三阶段，该阶段交换绑定信息，有了绑定信息下次需要密文数传可以跳过配对阶段。

除了展示两种角色的异同，我觉得有必要通过上图澄清几个概念，加深大家的理解：

1. 复杂密码技术是运用在已连接之后的配对阶段，所以不存在配对失败，导致ble无法正常建立连接，至多是配对失败，导致连接断开。
2. 连接后，不一定要启动配对，如果明文数传已经满足应用要求，就没必要启动配对了。

ble4.0安全机制

从用户角度提出问题：我现在对密码技术有初步了解了，也知道ble安全机制的一些背景知识，评估下来连接之后的明文数传风险太大，我要用到密文数传，ble提供什么样的解决方案呢？

上图是ble4.0安全机制简单示意图，是上一节“建立连接后”的细节展开，观察方式从上到下为角色的时间轴，从左到右分别是不同的角色，空白地方的文本为传递的数据，虚线为可选项，双斜杠为不展开讨论的内容。

对于密文数传，ble提供解决方案分四种情况：

1. 首次连接无绑定

   首次连接，配对输出临时密钥（STK），加密过程用STK衍生出会话密钥（sessionKey）和随机数（IV）用于CCM认证加密，后面都是密文数传。

2. 首次连接有绑定

   首次连接，配对输出临时密钥（STK），加密过程用STK衍生出会话密钥（sessionKey）和随机数（IV）用于CCM认证加密，后面都是密文数传，进入绑定阶段，从机将长期密钥（LTK）发送给主机保存。

3. 第二次连接且首次连接无绑定

   第二次连接，配对输出临时密钥（STK），加密过程用STK衍生出会话密钥（sessionKey）和随机数（IV）用于CCM认证加密，后面都是密文数传。

4. 第二次连接且首次连接有绑定

   第二次连接，跳过配对阶段，加密过程使用之前绑定的LTK衍生出会话密钥（sessionKey）和随机数（IV）用于CCM认证加密，后面都是密文数传。

由下往上读图，回答用户提出的问题：

ble4.0选择CCM给明文数据认证加密，想要使用CCM，就需要一个密钥和一个随机数用于CCM认证加密，所以ble有一个“加密过程”负责输出一个密钥（sessionKey）和一个随机数（IV），而加密过程又需要一个密钥来产生sessionKey，所以ble有一个“配对阶段”来输出一个临时密钥（STK）给加密过程，或者在绑定阶段输出一个长期密钥（LTK）给加密过程下一次连接时候使用。

TK配对码的生成和配送

ble4.0的TK配对码生成和配送方式有多种，常用的两种TK配对码的生成和配送方式是：JustWorks和Passkey，他们有以下差异：

1. JustWorks模式时，生成的TK是000000，因为这是公开的，没有配送的意义，配送目的是为了防止通信双方以外的第三方获得密钥，由于现在认证码是公开的，就没配送的意义了，而且由于认证码泄露，这种模式不能提供篡改和伪装保护。

2. Passkey模式时，TK的生成方式和配送方式如下：通信其中一方如Alice随机生成TK为142536，通过显示屏/短信/NFC等蓝牙以外的输出数据的方式，将配对码告知给Bob’s User，Bob’s User通过键盘往Bob设备输入142536，使得Bob和Alice拥有一个共享认证密钥，而针对蓝牙基带攻击的第三方Mallory不知道，从而提供篡改和伪装保护。

下面来看一下图，Passkey模式是怎么做到认证保护的。
认证保护示意图：

通过正常认证过程，可以发现Bob和Alice只在空中交互了两次，所以Mallory的攻击时机有两个，第一个是Bob和Alice交换MIC的时刻，另一个是在Bob和Alice交换明文的时刻。

分两种攻击行为

1. 篡改MIC或者明文其中一项，属于篡改攻击。

• 如果篡改MIC，那就是在未知明文和TK的情况下，凭空捏造一个EMIC，而且这个EMIC还要能够通过后续校验，这个几乎不可能。MIC是果，明文和TK是因，因果倒置不可能吧。
• 如果篡改明文，那就是给定MIC，基于MAC算法且未知认证密钥TK的情况下，推导出另一份明文，根据MAC算法性质，这个是很难做到的。

2. 同时篡改MIC和明文，属于伪装攻击，也叫MITM攻击。

• 因为伪造认证码EMIC和伪造明文Erand是Mallory提供的，计算过程可能是EMIC = MAC(EK, Erand)，而真实配对码TK和伪造配对码EKEY只有百万分之一的几率是相同的，所以看作是不相同的，也即EK != TK，根据MAC的输入敏感性质，EMIC != MAC(TK, Erand)，最终认证失败。

ble4.0真的足够安全吗？

我们先列出ble4.0安全机制各个密钥的安全依赖关系：

CCM -> sessionKey -> STK(LTK) -> TK

可以看到，最终的源头是TK认证码，只有保证TK足够安全，密文才能保证安全，也就是说不能让非法分子获得TK，否则他们就能够将密文解密了。

一般我们依靠MAC算法本身的性质，可以保证认证密钥不被推算出来，但是但是这些性质的前提是：认证密钥是使用密码学安全的、高强度的伪随机数生成器生成的，而且这些密钥位数很多，以至于无法穷举。

而实际TK的取值是000000~999999，最多只有100万种可能性，先抓取配对阶段（phase2.2）中用到的明文、MIC，再通过穷举的方式，就可以推算出TK了。

我们分析一下，如果在整个安全机制过程中，一直存在窃听者Eve，那么我们会面临什么威胁。

Tips：在这里也顺带分析静态配对码和动态配对码的区别，静态配对码是指每次输入都是固定的TK值，动态配对码是指每次输入都是动态产生的TK值，其实核心规范里面没有提过静态配对码，但是很多人会希望有如下功能：在一个设备预设一个配对码为123456，然后配对阶段时另一个设备输入配对码123456则通过认证，否则不通过，其实对于ble来说，由于TK可以被破解，所以静态配对码没有起到安全保护作用。

1. 如果是静态配对码，Eve推算出首次连接TK，从而推算出STK，从而推算出sessionKey，从而破解CCM，从而窃取绑定过程中的LTK。

1. Bob和Alice首次连接，因TK和STK被破解，所有阶段被破解，可任意窃听和篡改；
2. Bob和Alice第二次连接，因LTK被窃取，所有阶段被破解，可任意窃听和篡改；
3. 伪装Bob或者Alice与对方首次连接，因为TK是静态配对码，通过认证，伪装成功。

2. 如果是动态配对码，Eve推算出首次连接TK，从而推算出STK，从而推算出sessionKey，从而破解CCM，从而窃取绑定过程中的LTK。

1. Bob和Alice首次连接，因TK和STK被破解，所有阶段被破解，可任意窃听和篡改；
2. Bob和Alice第二次连接，因LTK被窃取，所有阶段被破解，可任意窃听和篡改；
3. 伪装Bob或者Alice与对方首次连接，因为TK是动态配对码，之前破解的TK用不上，无法通过认证，伪装失败。

总结出几个观点：

1. 因为“加密”都依赖于认证码TK，而TK容易被穷举破解，加密则形同虚设。

2. 上面描述的威胁，首先是窃听成功，才能篡改成功，问题是出在了窃听上。正常情况下对于密文的处理，CCM需要先解密，后认证。如果Eve没有窃听成功，乱篡改Bob发出的CCM认证加密过的密文，那么Alice解密出来的数据几乎不可能通过后续认证的。正是因为Eve窃听成功，知道篡改哪部分内容，所以才会造成威胁。解决窃听问题，就能同时解决篡改问题了。

3. TK是不安全的，以至于如果使用静态配对码而不是动态配对码，就无法解决伪装问题，如果认证码不像TK那样范围窄，静态配对码技术本身也没什么问题，但是最好还是定期更新。

上面总结的也是ble4.2安全机制里面做的一部分改善，比如增加破解TK的难度，引入ECDH解决窃听问题。

ble4.2安全机制

上一节，我们分析了ble4.0的安全“漏洞”， 接下来简单说一下ble4.2作出的应对措施。

• 无法改变的前提：

  • 配对码是6个字节。

• 可能的攻击方式：

  • Eve窃听整个过程，从而破解TK，下一次可以伪装Bob和Alice主动发起连接认证。
  • Eve窃听整个过程，从而破解TK，从而得到STK，然后窃取LTK。
  • Mallory发起MITM攻击，即使攻击失败，包含整个TK信息的MAC和MIC会被Mallory获得。（虽然我不知道有什么用）

• 提出对应解决的方案：

  • 动态认证码；
  • ECDH保证机密性；
  • 将TK拆成20bit，每次认证一个bit，攻击失败只会暴露1个bit，不会暴露整个TK。

BLE4.2与BLE4.0的安全机制区别主要体现在“配对阶段”的phase2，在这个阶段引入了ECDH，下面展开passkey模式的phase2（包括phase2.1~2.3）。

在“Authentication Stage1”过程，可以发现Bob和Alice只在空中交互了三次，所以Mallory的攻击时机有三个：

1. 交换公钥的时刻
2. 交换MIC的时刻
3. 交换明文的时刻。

后两个攻击方式，在BLE4.0已经分析过了，至于第一个攻击时机，因为公钥是也是MAC算法里面的一个参数，所以它也不能被随意篡改，如果改了后面的Ea和Eb校验就不通过了，即给ECDH也提供了MITM保护。

Tips：这里之所以可以提供MITM保护的实质是人的参与，通过观察的方法获得配对码，绕开了蓝牙空中传输来获得配对码，从而不会受到第三者攻击。

对比BLE4.2和BLE4.0的主要区别：

• BLE4.2没有STK，在配对过程直接生成LTK，因为LTK在配对阶段就已经强制生成了，加密过程直接使用LTK，BLE4.2的绑定阶段(phase3)不会发送LTK。

• LTK是DHkey衍生出来的，DHkey是第三方无法窃听也无法破解出来的，所以可以保证后面用CCM加密后数据的机密性。

BLE4.2完美解决了BLE4.0的安全漏洞。

总结

文章提到的只是BLE常见的一些概念，其他如：签名（Signed）、授权（Authorization）之类都没有提及，有兴趣的读者可以去核心规范探索一番。

参考资料里面有许多优秀的书籍和文章，比如密码技术相关知识我是从《图解密码技术》获知的，关于具体的实战抓包分析，吹爆“BLE配对过程详解”这篇文章。

最后最后，感谢您阅读到最后，这是对我最大的鼓励，也希望这篇博文能让您有一点点的收获。

后记

一开始是想将MESH加进来的，但是考虑到还没上过正式的项目去体验过，怕写出来理解的不够透彻，所以还是算了，以后有机会再单独开一篇吧，但是有兴趣的朋友可以私底下一起交流。

参考资料

• 《图解密码技术》
• BLE配对过程详解
• BLE核心规范
• Hash算法总结
• 穷举法破解BLE的TK值

等保测评之服务器未配置登录失败锁定策略及登录连接超时自动退出策略

真是一事未完又来一事哈，昨天收到的等保测评出现了好多的问题，这里将部分问题做一下记录

看看问题

问题如下

测试服务器

主要是测试服务器是不是存在这种问题，经过测试问题存在，测试过程这里省略了

问题描述

恶意人员可通过暴力破解的方式获取账户口令。且设备易被非授权人员恶意操作，存在非授权访问的风险。

问题解决

• 一下文件配置完成后不需要重启服务器的哈，直接生效，还有就是在操作时，建议保持一个ssh远程连接到服务器，方便出现错误及时的回滚操作

备份主要涉及的两个重要文件

[root@localhost ~]# cp /etc/pam.d/sshd /etc/pam.d/sshd.bak    #这个是ssh的配置文件
[root@localhost ~]# cp /etc/pam.d/login /etc/pam.d/login.bak
[root@localhost ~]# ll /etc/pam.d/sshd.bak  /etc/pam.d/login.bak   ##这个文件里面记录了所有关于登录的配置文件记录
-rw-r--r--. 1 root root 796 10月 13 10:01 /etc/pam.d/login.bak
-rw-r--r--. 1 root root 904 10月 13 10:00 /etc/pam.d/sshd.bak

检查是否存在的重要pam模块.so文件

[root@localhost ~]# find /* -name "*pam_tally2.so*"
/usr/lib64/security/pam_tally2.so

配置登录失败处理功能策略（服务器终端）

[root@localhost ~]# cp /etc/pam.d/system-auth /etc/pam.d/system-auth.bak
[root@localhost ~]# vim /etc/pam.d/system-auth
[root@localhost ~]# cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        required      pam_faildelay.so delay=2000000
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        required      pam_deny.so
auth required pam_tally2.so  onerr=fail  deny=3  unlock_time=40 even_deny_root root_unlock_time=30   ###需要添加的这一行

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

• deny 指定最大几次认证错误，如果超出此错误，将执行后面的策略。如锁定N秒，如果后面没有其他策略指定时，默认永远锁定，除非手动解锁。
• lock_time 锁定多长时间，按秒为单位；
• unlock_time 指定认证被锁后，多长时间自动解锁用户；
• magic_root 如果用户uid＝0（即root账户或相当于root的帐户）在帐户认证时调用该模块发现失败时，不计入统计；
• no_lock_time 不使用.fail_locktime项在/var/log/faillog 中记录用户 －－－按英文直译不太明白，个人理解即不进行用户锁定；
• even_deny_root root用户在认证出错时，一样被锁定（该功能慎用，搞不好就要单用户时解锁了）
• root_unlock_time root用户在失败时，锁定多长时间。该选项一般是配合even_deny_root 一起使用的。

终端测试效果如下：

查看安全日志验证：

[root@localhost ~]# tail -100 /var/log/secure | grep "max"
Oct 13 10:19:17 localhost sshd[2242]: PAM service(sshd) ignoring max retries; 5 > 3

配置登录失败处理功能策略（ssh远程连接登录）

[root@localhost ~]# vim /etc/pam.d/sshd
[root@localhost ~]# cat  /etc/pam.d/sshd
#%PAM-1.0
auth	   required	pam_sepermit.so
auth       substack     password-auth
auth       include      postlogin
auth required pam_tally2.so  onerr=fail  deny=3  unlock_time=40 even_deny_root root_unlock_time=30   ##添加部分
# Used with polkit to reauthorize users in remote sessions
-auth      optional     pam_reauthorize.so prepare
account    required     pam_nologin.so
account    include      password-auth
password   include      password-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open env_params
session    required     pam_namespace.so
session    optional     pam_keyinit.so force revoke
session    include      password-auth
session    include      postlogin
# Used with polkit to reauthorize users in remote sessions
-session   optional     pam_reauthorize.so prepare

ssh远程测试效果：

经过测试连续登录3此输入错误的密码后，第四次或之后的40秒内，那怕输入正确的密码，也不会正常的登录

查看安全日志验证：

其他的辅助命令

[root@localhost ~]# pam_tally2 --user root       ###其中root为用户，这个是查看当前root用户登录失败了多少次
Login           Failures Latest failure     From
root                4    10/13/21 10:43:06  192.168.211.1
[root@localhost ~]# pam_tally2 -r -u  root    ##解锁root用户
Login           Failures Latest failure     From
root                8    10/13/21 10:44:54  tty1
[root@localhost ~]# pam_tally2 --user root   #再次查看root用户的饿登录失败次数，此时为0
Login           Failures Latest failure     From
root                0