1.2 三大安全属性的攻防含义
1.2 三大安全属性的攻防含义
本节摘要：机密性、完整性、认证性不是三个名词解释，而是三个可判定的谓词——每个都对应"被攻破时你在抓包与日志里能观察到的具体现象"。本节按攻防双视角逐个拆解，每个属性配一个最小反例，顺带厘清认证与授权这对最常混用的概念。读完你能对任何协议事故快速归类：它击穿的是哪个属性、通过哪条路径。
把三个词放回事故现场
教科书给三个属性的定义往往一句话就完事，背下来毫无用处。有用的记法是给每个属性配两个东西：一个可观察的失效现象，一个最小反例。以后你面对任何安全事件，先问"哪个属性被击穿了"，再问"反例的最小构造是什么"，分析就不会散。
机密性被击穿的现场：本该只有两方能解出的内容，第三方解出来了。抓包层面能看到密文，但密文被解出——现象通常不在抓包里，而在某个下游泄露事件里。最小反例：一个用固定密钥、电子密码本模式加密的图像，密文本身不泄露明文像素值，但同样的明文块产生同样的密文块，图像轮廓直接从密文里透出来。内容没被解密，机密性却已经丢了——这个反例的价值在于它说明机密性是"语义"层面的承诺，不是"看起来乱"的视觉承诺。
完整性被击穿的现场：消息在传输中被改了，接收方没能发现。最小反例：一条转账指令"向账户 A 转 100 元"追加在会话密文后面，只对指令本身做了校验和而没做密码学校验——敌手把 100 改成 9000，校验和顺手重算，接收方毫无察觉。校验和防比特翻转（无意的错），防不了有意的改；防有意篡改必须用带密钥的机制，这条边界 1.3 节还会再强调。
认证性被击穿的现场：B 坚信自己在和 A 对话，证据链完整，但那实际上是敌手扮演的。NS 三步协议 1980 年代末被找出的漏洞就是教科书案例——协议的每一步单看都"有密码学保护"，串起来却允许敌手用会话中的旧材料把自己嵌入一场对话，让 B 把敌手当成 A。机理细节留给 3.1 节，这里记住现象：认证性失效不表现为"解密失败"，表现为身份的证明链被合法组件拼出了错误结论，这是三类失效里最隐蔽的。
图 1-2 三大属性攻防判定矩阵
认证与授权：一对必须掰开的词
工程讨论里"认证"被用得太泛，值得花两段掰开。认证回答"你是谁"：证明某条消息确实出自所声称的主体。授权回答"你能做什么"：这个被认证的主体有没有权限执行请求的操作。协议层管前者，业务层管后者——但事故常发生在两者的接缝上。
一个典型的接缝事故：消息网关正确地验证了每条指令的签名（认证无误），但业务逻辑只检查了"签名有效"就执行——从未核对签名者是否对这笔特定资产有权限（授权缺位）。每个环节单看都合规，合起来是越权。推演室的判别口诀：认证失效是密码学问题，授权失效是设计问题，但两者的事故现场长得一模一样——都是"被冒名/越权执行了操作"。所以复盘时必须先拆：身份证明链断在哪，还是权限模型根本没覆盖这个操作。这个判别动作在 6.3 节的部署守则里会再次出现。
顺带把第四个属性放在这里说一句：不可否认性。它常被列为第四属性，我更愿意把它理解为"认证性 + 可审计存证"的组合需求——认证性保证消息出自某人，不可否认性额外要求这个证据强到本人无法抵赖，通常靠非对称签名 + 时间戳 + 密钥托管流程共同达成。它更多出现在签名类协议（电子合同、审计日志）里，通信类协议（TLS、Signal）一般不把它列进目标，因为通信场景里"事后抵赖"往往不是威胁。
属性是挂在消息上的谓词
本节最想留下的分析习惯：属性判断必须落到具体消息上。"这个协议保证机密性"是无意义的句子，有意义的句子是"消息 3 中被加密的那个字段，在敌手能截获全部流量、且不知道长期私钥的前提下，对第三方保持机密"。做协议分析时建议写一张三列表：每条消息一行，列出"它用密码学手段保护了什么属性、保护的前提假设是什么、假设若不成立哪个属性先失效"。这张表在 2.3 节会被形式化成安全命题，在第 5 章会被写成机器可验证的查询语句——它是贯穿全册的同一张表，只是精确度逐章上升。
属性之间会互相牵制
三个属性不是三份独立的试卷，它们之间存在真实的张力，设计时常常要拿一个换另一个。最经典的一对张力在机密性与可审计之间：端到端加密把服务器彻底排除在读者之外（机密性拉满），代价是服务器无法为纠纷提供内容证据（审计归零）——企业通信与消费通信在这条轴上选点不同，没有对错，但选点必须显式。第二对张力在认证性与匿名性之间：要求每条消息都证明来源，等于要求每个用户随时亮身份；隐私敏感的场景会用群签名、匿名凭证这类机制换取"可证明来自合格成员、但不可定位到个人"的折中，代价是协议复杂度与滥管难度的上升。第三对更朴素：性能预算。完整性保护与认证都要在每条消息上付费，低功耗设备上"哪些字段全额保护、哪些字段降级处理"是真实的取舍——但降级的决定必须写进命题（2.3 节的粒度原则），不能默认全保。
把这些张力摆出来是想纠正一种评审习惯：把三个属性当三项检查打勾，勾完了事。真实的协议设计是三股力之间的平衡点，评审要问的不是"三项都有吗"，而是"为了 A 多付了多少 B、这个代价声明过没有"。第 4 章对比四大信道协议时，这条思路会变成横向对比表的三列——同一组张力，不同协议给出了不同的平衡点。
一个综合演练：把三个属性挂到一次登录上
三个属性分开讲完了，用一次最常见的操作把它们串起来：用户在客户端输入密码登录服务器。逐条问属性。密码在键盘到客户端进程之间走的是操作系统输入栈——这一段的保护不属于我们的协议，属于端点（2.1 节的限制二，先划出去）。密码从客户端到服务器走网络——机密性命题覆盖这一段，TLS 握手产生的会话密钥兑现它。服务器把密码存下来——机密性命题的另一个分支，落点在 1.3 节讲的加盐慢哈希。服务器回"登录成功"——完整性命题覆盖这条响应，没有完整性保护时，一条被篡改的"登录成功"就是会话劫持的开场。服务器确认"你就是你声称的那个人"——认证性命题，密码本身就是认证因子，但它只证明"持密者在线"，不证明"持密者就是户主"（密钥被钓走时密码学层无能为力）。
这次演练想让你看到的是：三个属性不是三次独立的考试，而是同一次交互的三个侧面，每一次真实的系统交互都能画成这样一张属性落点图。评审系统时把这张图画出来，哪些侧面没人管、哪些侧面管了但管错了层（比如用校验和管完整性），一眼可见。这张图还有个变式练习：把"密码登录"换成"扫码支付"，自己画一遍属性落点，你会发现多出来的侧面几乎都集中在认证性与授权的接缝上——正是本节后半段掰开的那对概念。
本节要点回顾
- 按现象记属性：机密性失效看"内容或结构泄露"，完整性失效看"改动未被察觉"，认证性失效看"身份证明链拼出错误结论"。
- 校验和不是完整性机制：无意的比特翻转归它管，有意的篡改必须用带密钥的消息校验码或签名。
- 认证与授权是两层：认证失效是密码学问题，授权失效是设计问题，事故现场相似，修法完全不同。
- 不可否认性是组合需求：认证性加可审计存证，多见于签名类协议，通信协议一般不列为目标。
- 属性是谓词不是标签：写分析表时逐消息标注"保护了什么、前提是什么、前提破了先丢哪个"。
下一节进入道具间：三块密码积木各自的能力边界，以及拼装时最常见的三种错拼。上一节留下的变式练习（NS 协议的对称版本）在那一节会有答案。