博客

Views: 9

填充是PKCS#1的主要内容，占了正文三分之二的篇幅
早期的填充方式称为RSA-PKCS#1 v1.5填充，这种填充方式只是生成一个随机数与明文连接在一起，相对不安全，后来在RSA-PKCS#1 v2.1中(也就是RFC3447)定义了OAEP(用于加密)和PSS(用于签名)两种填充方式，新的填充方式使用MGF基于随机数对明文进行掩码处理。建议使用OAEP和PSS填充而不是RSA-PKCS#1 v1.5填充。

MGF: 掩码生成函数

https://datatracker.ietf.org/doc/rfc8017/
RSA-PKCS#1 v2.2
https://datatracker.ietf.org/doc/rfc3447/
RSA-PKCS#1 v2.1

Views: 82

• DH用于匿名的双方生成临时密钥，后面会用其它协议进行身份认证
• Dragonfly在生成临时密钥的同时完成身份认证，若生成的密钥相同则认证通过
• DH只需要1次报文交换(各自发送1个报文）来生成共享密钥
• Dragonfly需要2次报文交换，第一次交换生成共享密钥，第二次交换验证密钥是否相同(交换密钥的Hash)
• DH需要发起方在第一次密钥交换的时候生成公私钥对，并把公钥分发给对方,后续只交换随机数不再交公钥
• Dragonfly双方各自基于预共享密钥和随机数生成PWE，并把PWE和随机数发送给对方
• WPA3中使用Dragonfly，又叫SAE
• TLS和IPsec使用DH，ECDH，ED25519

SAE密钥交换示意图,PWE不是明文传输的，而是用u进行了掩码处理，就是mask_u,不过这个mask_u应该是直接参与运算而不需要去掩码的。

DH密钥交换示意图，其中g和p是公钥，A和B是公开的随机数，K是共享密钥

参考：
https://blog.csdn.net/weixin_47877869/article/details/136711988

Views: 8

PKCS#7(RFC2315)描述了Data(明文),Signed-data(签名), Enveloped-data(数字信封）signedAndEnvelopedData, digestedData, and encryptedData六种数据结构，并用PEM格式存储。定义了如何对数据进行签名和加密并进行存储的方法。在Windows上可以用PKCS#7来存储证书，它是通过无正文数据的Signed-data来存储证书的(后缀名为.p7b，事实上PKCS#7中data正文是必选的，证书是可选的)，因为PKCS#7设计并不是专门用来存储证书的，这样存储蛮奇怪的而且不符合标准。

关于对证书的定义PKCS#12标准(RFC7292)的原话是：A digitally signed data unit binding a public key to identity information.

我的理解证书就是将身份信息用私钥进行签名，并把签名和公钥绑定在一起的数据单元(PKCS#12把存储的一个个数据对象称为PDU)。PKCS#7中的Signed-data包含了身份信息(虽然没有X.509中的身份信息详尽)和签名，但是没有包含公钥，所以不能称为证书。

PKCS#12定义了KeyBag,PKCS8ShroudedKeyBag,CertBag,CRLBag,SecretBag,SafeContents一共6种PDU类型和Data，EncryptedData，EnvelopedData三种PDU加密方式，但是仍然不包含公钥(虽然可以把证书文件塞进去作为CertBag)。PKCS#12是一个复合容器(keystore)，可以存储多种不同类型的密钥和证书，并且可以对PDU进行加密和完整性验证。属于一种keystore，PKCS#12不用来存储用户数据。

按照PKCS#12和PKCS#8中的要求虽然KeyBag,PKCS8ShroudedKeyBag只用来存储单个私钥，是不能包含公钥的(虽然私钥可以导出公钥)。

PKCS虽然涵盖了PKI的方方面面，但是唯独没有定义证书的格式，只有X.509同时包含了身份信息，公钥，签名三种信息，符合证书的定义。

以上，只有X.509证书的说法，没有PKCS格式证书的说法，X.509证书可以保存在PKCS#12证书容器中。X.509与PKCS的大多数规范并没有太大关系，反而PKCS#7中的Signed data可以使用X.509证书，只有PKCS#1中定义的公私钥存储格式和RSA加密/签名操作规范在X.509中有所体现。

https://lapo.it/asn1js/
asn.1解码器，可以解码PKCS和X.509编码的文件

Views: 16

• 密钥层次
  80211r的重点是三层密钥模型
  WLAN Controller : PMK-R0 key holder (R0KH)
  Access Point : PMK-R1 key holder (R1KH)
  Client Station : PMK-S0 key holder (S0KH)
  Client Station : PMK-S1 key holder (S1KH)

802.11r defines a three-level key hierarcy
1. Pairwise Master Key R0(PMK-R0) : The first level key of the FT key hierarchy. This key is derived from master session key (MSK)
2. Pairwise Master key R1(PMK-R1) : The second level key of the FT key hierarchy.
3. Pairwise Transit Key (PTK) : The third-level key of the FT key hierarchy. The PTK is the final key used to encrypt 802.11 data frames.

PMK-R0属于属于第一层，PMK-R1属于第二层，PMK属于第三层,S0和S1是PMK-R0和PMK-R1在STA上的对应体现。
– 首次连接

– Over-the-Air Fast BSS Transition

– Over-the-DS Fast BSS Transition

带Resource Request，多了一对握手包

参考：
https://www.cwnp.com/uploads/802-11_rsn_ft.pdf

CWSP-802.11r Key Hierarchy

Views: 17

• 密钥层次
  
• 握手过程
  
  握手过程是通过EAPOL报文封装的，也可以称为EAPOL握手。
• 完整的连接过程
  
• KRACK
  
  诱导AP重发Message3报文可以让STA重装PTK密钥，重装密钥的同时初始化向量会重新计数，造成加密密钥重复使用。
  在STA上重装相同的密钥并不是802.11规定的，是认证客户端在实现的时候(wpa_supplicant2.4以下版本)没有意思到密钥重装会带来安全问题，当然802.11也没有提醒这一点。
  KRACK解决方法：
• 在STA上一次EAPOL握手只允许安装一次PTK密钥，禁止密钥重装
• STA安装密钥时判断与现有密钥是否相同，相同则忽略当前密钥安装
• 禁止或限制AP重发Message 3报文
  完全禁止重发Message 3会对连接稳定性造成影响，目前一般是在AP上限制重发次数(通常是3或4次)并在 STA上禁止密钥重装。
  Openwrt或hostapd上有一个禁止重发Message1和Message3报文的配置

# Workaround for key reinstallation attacks
#
# This parameter can be used to disable retransmission of EAPOL-Key frames that
# are used to install keys (EAPOL-Key message 3/4 and group message 1/2). This
# is similar to setting wpa_group_update_count=1 and
# wpa_pairwise_update_count=1, but with no impact to message 1/4 and with
# extended timeout on the response to avoid causing issues with stations that
# may use aggressive power saving have very long time in replying to the
# EAPOL-Key messages.
#
# This option can be used to work around key reinstallation attacks on the
# station (supplicant) side in cases those station devices cannot be updated
# for some reason. By removing the retransmissions the attacker cannot cause
# key reinstallation with a delayed frame transmission. This is related to the
# station side vulnerabilities CVE-2017-13077, CVE-2017-13078, CVE-2017-13079,
# CVE-2017-13080, and CVE-2017-13081.
#
# This workaround might cause interoperability issues and reduced robustness of
# key negotiation especially in environments with heavy traffic load due to the
# number of attempts to perform the key exchange is reduced significantly. As
# such, this workaround is disabled by default (unless overridden in build
# configuration). To enable this, set the parameter to 1.
#wpa_disable_eapol_key_retries=1

Views: 28

在Wi-Fi中，WEP（Wired Equivalent Privacy）是一种早期的加密协议，用于保护无线网络通信的安全性。WEP的含义是提供与有线网络相当的安全性，1997年随第一代802.11协议推出。
WEP使用RC4加密，可以提供无线流量的加密，认证，完整性保护。
WEBP的密码是直接当密钥用的，不会做PRF处理。
目前常用的wep加密长度有：
1. 64-bit WEP： 其中密码长度为40位，也就是（40/8=）5个ASCII码。
2. 128-bit WEP：其中密码长度为104位，也就是（104/8=）13个ASCII码。
剩下的24bit就是IV(初始化向量)，IV+Shared Key就是RC4的密钥。
802.11并没有规定IV的生成方式，只是规定IV不能重复，所以最好的方法无非是序列号。

WEP加密下的帧格式包括以下几个部分：

WEP帧格式

1. MAC Header：包含帧控制、地址和序列控制信息。
2. IV（Initialization Vector）：初始化向量，用于加密过程中的随机化。
3. 加密数据：实际的加密数据负载。
4. ICV（Integrity Check Value）：完整性校验值，用于验证数据的完整性。

详细结构

+------------------+------------------+------------------+------------------+
|    MAC Header    |        IV        |   Encrypted Data |        ICV       |
+------------------+------------------+------------------+------------------+

1. MAC Header

• Frame Control：2字节，包含帧类型和控制信息。
• Duration/ID：2字节，包含持续时间或ID信息。
• Address 1：6字节，目的地址。
• Address 2：6字节，源地址。
• Address 3：6字节，BSSID（基本服务集标识符）。
• Sequence Control：2字节，包含序列号和片段号。
• Address 4（可选）：6字节，用于WDS（无线分布系统）。

2. IV（Initialization Vector）

• IV：3字节，用于加密过程中的随机化。
• Key ID：1字节，指示使用的WEP密钥。

3. Encrypted Data

• 加密数据：实际的加密数据负载，使用RC4算法加密。

4. ICV（Integrity Check Value）

• ICV：4字节，用于验证数据的完整性。

示例

以下是一个WEP加密帧的示例：

+------------------+------------------+------------------+------------------+
|    MAC Header    |        IV        |   Encrypted Data |        ICV       |
+------------------+------------------+------------------+------------------+
| Frame Control    | IV (3 bytes)     | Encrypted Data   | ICV (4 bytes)    |
| Duration/ID      | Key ID (1 byte)  | (variable length)|                  |
| Address 1        |                  |                  |                  |
| Address 2        |                  |                  |                  |
| Address 3        |                  |                  |                  |
| Sequence Control |                  |                  |                  |
| Address 4 (opt.) |                  |                  |                  |
+------------------+------------------+------------------+------------------+

总结

WEP加密下的Wi-Fi帧格式包括MAC Header、IV、加密数据和ICV。IV用于加密过程中的随机化，ICV用于验证数据的完整性。WEP使用RC4算法进行加密，但由于其安全性较弱，已经被更安全的协议（如WPA和WPA2）所取代。
WEP的主要问题是密钥不变而且无法防重放攻击，这样通过重放攻击制造大量报文，然后收集到足够的报文后再利用RC4的弱点就可以破解了。

Views: 101

中文叫挑战/应答或质询/应答，是一种身份认证方式，具体流程为：
1. 客户向认证服务器发出请求，要求进行身份认证；
3. 认证服务器内部产生一个随机数，作为”质询值”，发送给客户；
4. 客户把质询值用预先配置的密码进行RC4加密作为应答；
5. 认证服务器将应答串与自己的计算结果比较，若二者相同，则通过一次认证；否则，认证失败；
6. 认证服务器通知客户认证成功或失败。

因为质询值是明文发送的，所以存在安全隐患。

Views: 31