数据加密与签名与业务安全与风控

• BouncyCastle 的角色（Provider）
• 扩展算法（国密、Argon2、Ed25519 等）
• 注册与使用

BouncyCastle（bcprov）是一个开源的 Java 加密 Provider（org.bouncycastle.jce.provider.BouncyCastleProvider），为 JCA/JCE 提供大量 JDK 标准不直接支持的算法。它扩展的算法包括：国密算法（SM2 非对称、SM3 哈希、SM4 对称）、Argon2/Scrypt 等密码哈希、Ed25519/Ed448 曲线签名、X25519 密钥交换、更多哈希（SHA-3、Keccak、Blake2）、以及一些流密码/ECC 曲线等。工程应用：当业务需要 JDK 未内置的算法（如国密合规、Argon2 强密码哈希、Ed25519 现代签名）时，通过 Security.addProvider(new BouncyCastleProvider()) 注册后，用标准 Cipher/MessageDigest/Signature/KeyPairGenerator API 配合算法名（如 "SM4/ECB/PKCS7Padding"、"SM3"、"Argon2"）使用。注意：注册 Provider 后注意优先级（Security.insertProviderAt(..., 1) 可提高优先级）；某些算法（如国密）需配合 BouncyCastle 的 KeyPairGenerator/Cipher 提供商实例。BouncyCastle 也提供 PEM 读写、证书生成等高级功能。工程上引入 bcprov-jdk18on 依赖并按需注册。

本题考察 BouncyCastle 扩展算法。核心是"Provider 注册 + 扩展算法（国密/Argon2/Ed25519）"。回答应点出注册与算法使用。

• Java 加密体系（JCA/JCE）
• Spring Security Crypto 模块
• 常用工具（Encryptors、KeyGenerators）

Java 加密体系指 JCA（Java Cryptography Architecture，框架与算法抽象）与 JCE（Java Cryptography Extension，加密实现），通过 Cipher、MessageDigest、Signature、KeyGenerator、KeyPairGenerator 等标准 API 提供对称/非对称加密、哈希、签名能力，算法由 Provider 提供。Spring Security Crypto 模块（spring-security-crypto）在上述之上提供更易用的高级封装，面向业务场景：Encryptors（如 Encryptors.standard() 用 AES/GCM 加密、Encryptors.text() 用 AES 加密字符串）、KeyGenerators（生成随机密钥、盐）、PasswordEncoder（BCrypt/Argon2）、SecureRandom 封装、BytesKeyGenerator 等。关系：Spring Security Crypto 是"开箱即用"的加密工具层，底层依赖 JCA/JCE 的算法实现；它隐藏了密钥派生、IV 管理等细节，适合应用层直接使用。工程上：简单业务加密（如 token、敏感字段）可用 Encryptors；密码哈希用 PasswordEncoder；底层复杂加密用 JCA。注意 Crypto 模块的加密是独立于 Spring Security 认证的，可单独使用。

本题考察 Java 加密与 Crypto 模块。核心是"JCA/JCE 标准 API + Crypto 模块高级封装"。回答应点出 Encryptors/PasswordEncoder 与底层关系。

• 并发扣减的原子性
• 乐观锁/悲观锁/Redis Lua 的机制
• 选型权衡

优惠券/积分扣减是典型的高并发写操作，必须保证原子性与超卖防护。三种方案：乐观锁——通过 @Version 字段，UPDATE 时 WHERE version=?，受影响行数为 0 则冲突重试，适合低冲突、读多写少的场景，无锁但需重试；悲观锁——SELECT ... FOR UPDATE 锁定行，事务内串行扣减，保证强一致，但锁定开销大、并发降低，适合高冲突、强一致场景；Redis Lua 原子操作——在 Redis 中先用 Lua 脚本原子地"检查余额/数量并扣减"，脚本在 Redis 单线程内原子执行，无竞争、极高并发，适合积分/库存放在 Redis 的缓存场景，但需处理 Redis 与 DB 的一致性（最终落到 DB）。选型权衡：若数据在数据库且扣减冲突低，用乐观锁；若强一致且冲突高，用悲观锁；若追求极致并发且数据可缓存，用 Redis Lua（配合扣减后异步落库、幂等）。更优设计：Redis Lua 做预扣减/限流控制超卖，DB 用乐观锁（版本/条件更新 balance >= amount）做最终一致性，DB 更新成功后再回滚 Redis。核心是"条件更新 + 原子性 + 幂等"。

本题考察并发扣减方案。核心是"乐观锁无锁重试、悲观锁强一致、Redis Lua 原子高并发"。回答应点出选型与组合。

• 各哈希算法的安全性
• 碰撞/前像攻击
• 适用场景（完整性 vs 密码存储）

哈希算法用于完整性校验与数据指纹，但安全性不同：MD5——已发现碰撞攻击（可构造任意碰撞），且速度极快，不适用于安全场景（完整性校验、密码存储、签名），仅用于非安全校验（如文件去重、非安全缓存键）；SHA-1——已发现理论碰撞攻击（SHAttered），被 NIST 弃用，不推荐用于安全哈希；SHA-256——目前安全，抗碰撞与前像，广泛用于完整性校验、签名、证书、区块链；SM3——国密标准哈希，256 位输出，安全性对标 SHA-256，用于国内合规场景。安全边界：哈希算法不能直接用于密码存储（即使 SHA-256 也需加盐 + 慢哈希如 BCrypt/Argon2，因为 SHA 快速可被 GPU 爆破）；哈希用于完整性/签名时需抗碰撞（MD5/SHA-1 不够）；选用时应遵循"算法强度 + 场景匹配"：完整性/签名用 SHA-256 或 SM3，密码存储用慢哈希。同时注意哈希只是"单向"校验，不提供机密性，不能用于加密数据。

本题考察哈希算法安全边界。核心是"MD5/SHA-1 不安全、SHA-256/SM3 安全、密码存储须慢哈希"。回答应点出各算法适用场景。

• 密钥长度与强度
• 分组与模式
• 安全性演进

DES——56 位密钥，已不安全（可被暴力破解），且密钥长度过短，不推荐使用；3DES——对 DES 做三次加密（有效密钥 112/168 位），强度高于 DES，但算法慢、分组 64 位、存在已知弱点（如 meet-in-the-middle、块大小相关攻击），已被逐步弃用（NIST 已将其退役）；AES——现代标准对称加密，支持 128/192/256 位密钥，分组 128 位，速度快、硬件支持好（AES-NI），是当前唯一推荐的分组加密算法。差异：密钥长度、强度、性能、分组大小（DES/3DES 为 64 位块，AES 为 128 位块）。适用场景：现代业务一律用 AES（128/256 位），配合 GCM 等认证加密模式；DES/3DES 仅用于兼容旧系统。工程上 Java 用 Cipher.getInstance("AES/GCM/NoPadding")，用 SecureRandom 生成 IV，密钥安全存储。注意：分组加密还需选择正确模式（GCM 认证加密优于 CBC），并避免 ECB 模式（泄漏模式信息）。

本题考察对称加密差异。核心是"DES 弱、3DES 过渡、AES 现代标准"。回答应点出密钥长度与模式。

• 令牌桶/滑动窗口/漏桶原理
• Redis 实现（Lua/固定窗口）
• 网关限流选型

三种限流算法：令牌桶——以固定速率向桶中放令牌，请求需取令牌才能通过，桶容量限制突发，允许一定突发流量，是最常用的平滑限流算法；漏桶——请求以固定速率从桶中流出，不管流入多快，输出速率恒定，适合平滑输出/削峰，但无法处理突发；滑动窗口——统计滑动时间窗口内的请求数，超限拒绝，比固定窗口更平滑（避免窗口边界突刺），精度好但实现略复杂。在 Spring Cloud Gateway 与 Redis 下实现：令牌桶可用 Redis 的 Lua 脚本（如 REDIS 的令牌桶命令或自行实现）、或 spring-cloud-gateway 内置的 RequestRateLimiter 过滤器（基于 Redis 的令牌桶，redis-rate-limiter，可配置 replenishRate/burstCapacity）；滑动窗口可用 Redis 的 ZSET 记录时间戳实现（移除窗口外记录、统计窗口内数量），或用固定窗口近似；漏桶可配合消息队列削峰或 Redis 单队列。选型：网关统一限流用 Spring Cloud Gateway 的 RequestRateLimiter（Redis 令牌桶，支持按 IP/用户等 key 限流）；平滑突发用令牌桶；严格削峰用漏桶；需要精确窗口统计用滑动窗口。工程上常组合：网关令牌桶限流 + 业务层滑窗/参数校验。

本题考察限流算法与实现。核心是"令牌桶允许突发、漏桶恒定速率、滑窗精确统计"，网关用 Redis 实现。回答应点出实现与选型。

• 验证码与人机校验
• 登录失败锁定与指数退避
• 短信接口频率限制

登录与短信接口是撞库/短信轰炸的攻击面，防爆破策略：一是验证码——图形/滑块/数字验证码，验证码绑定会话（一次性、限时），阻止自动化尝试；二是人机校验——reCAPTCHA、滑块验证、行为验证（无感），通过服务端二次校验（siteverify）确认是真人，抗自动化；三是指数退避锁定——同一账号/IP 连续失败后，锁定时间成倍增长（如 1 分钟、5 分钟、15 分钟），或要求验证码，降低爆破速率；四是短信接口频率限制——同一手机号/IP 在单位时间内发送次数受限（如 1 分钟 1 次、1 天 N 次），防止短信轰炸，并做同号/IP 校验；五是失败计数与账号锁定——记录失败次数，超过阈值锁定账号或要求人工/短信验证；六是风控联动——结合设备指纹、IP 信誉、行为异常。实现要点：验证码与人机校验用 Redis 存储状态（一次性、TTL）；失败计数用 Redis 原子递增；锁定与退避用 Redis 记录时间戳；短信限流用 Redis 计数器 + Lua。注意防爆破要兼顾"防自动化"与"用户体验"，且对抗分布式攻击（按 IP 段、设备指纹多维度）。

本题考察防爆破策略。核心是"验证码/人机校验 + 指数退避锁定 + 短信频率限制"。回答应点出 Redis 实现与多维度。

• 设备指纹采集（Canvas/WebGL/UA）
• 指纹哈希与稳定性
• 多账号关联检测

设备指纹用于识别同一设备，常用于风控与多账号检测。前端采集：Canvas 指纹——绘制指定图形，不同设备的 GPU/渲染引擎产生不同像素，转 base64 后哈希；WebGL 指纹——通过 WebGL 渲染信息获取 GPU 型号/渲染器指纹；其他——结合 UA、屏幕分辨率、时区、语言、字体、时间戳、插件等生成多维指纹。指纹生成：把采集的特征向量序列化后做 SHA-256 哈希，得到稳定指纹；需注意指纹的稳定性（浏览器更新、隐私模式会影响）与唯一性（用户可能关闭 JS 指纹）。多账号关联检测：同一设备指纹关联多个账号 → 判定为马甲/养号/注册机；结合 IP、Cookie、行为特征（操作时间、点击路径）做关联分析。实现：设备指纹存于数据库（deviceId → 账号列表），风控引擎查询关联账号数，超阈值触发风控（如限制注册、封号、要求验证）。注意隐私合规：设备指纹采集需合法合规（如 GDPR），且指纹可能被伪造/规避（需结合多种特征）。

本题考察设备指纹与多账号检测。核心是"Canvas/WebGL 采样 + 哈希 + 同一指纹关联多账号判定"。回答应点出采集与关联检测。

• 幂等设计（唯一键/状态机/令牌）
• 防重复领取/注册
• 业务一致性

防薅羊毛（注册、领券、签到）的核心是防止重复操作与并发超发，需幂等与一致性约束。唯一键幂等——为操作建立唯一业务键（如 手机号+活动ID、用户ID+券模板ID），数据库唯一索引保证同一键只能插入一次，重复请求被唯一约束拒绝（乐观锁/条件插入）；状态机幂等——业务对象有状态机（如 券：未领取→已领取→已使用），操作校验当前状态，状态不匹配则幂等返回（不是重复执行）；令牌（Token）幂等——客户端先获取一次性令牌（如 Redis 的幂等键），提交时携带令牌，服务端通过"令牌是否存在"判断是否已处理（SETNX 原子操作），保证同一操作只执行一次。并发场景：用 Redis 的 SETNX/INCR 或数据库唯一索引做互斥，防止并发超发；领取后设置状态并落库。业务一致性：领券与扣库存需在事务内完成，或采用"先占额度、后确认"的柔性方案。防薅羊毛还结合设备/IP/手机号风控（关联设备指纹、新号检测、频率限制）。核心是"幂等键 + 原子操作 + 状态机"保证"同一用户同一活动只领一次、并发不超发"。

本题考察幂等与防薅羊毛。核心是"唯一键/状态机/令牌的三类幂等 + 原子互斥"。回答应点出 Redis SETNX 与唯一索引。

• 密钥长度与安全性
• 性能与密钥大小
• 国密适配

非对称加密用公钥加密、私钥解密（或私钥签名、公钥验证）。RSA——基于大整数因数分解，密钥较安全（2048 位起），但密钥大、加解密慢，适合做密钥交换/数字签名；ECC（椭圆曲线）——基于椭圆曲线离散对数，相同安全强度下密钥更短（256 位 ECC 约等于 3072 位 RSA）、性能更好、带宽更省，适合移动端与资源受限场景（如 ECDSA 签名、ECDH 密钥交换、X25519/P-256）；SM2——国密椭圆曲线算法，安全性对标 ECC P-256，国内合规场景（金融、政务）使用。差异：密钥长度与安全强度、性能、密钥/密文大小、应用场景。选型：新系统优先用 ECC（短密钥、高性能）或 RSA-2048+（兼容性好）；国内合规用 SM2；签名用 ECDSA/RSA-SHA256/SM2。注意：非对称加密不适合加密大数据（性能差），通常用于"密钥交换 + 签名 + 对称加密传输数据"（混合加密）。Java 用 KeyPairGenerator（"RSA"/"EC"/"SM2"）生成密钥。

本题考察非对称加密差异。核心是"RSA 密钥大但慢、ECC 短密钥高性能、SM2 国密"。回答应点出选型与混合加密。

• JKS 与 PKCS12 的格式差异
• 密钥库用途（SSL、证书）
• 安全性

JKS（Java KeyStore）是 Java 特有的密钥库格式，由 Sun 定义，组织机构为 JKS，只能存密钥与证书，密码保护较弱（基于自定义的加密），且是 Java 专有，非 Java 生态不兼容；PKCS12（.p12/.pfx）是标准格式（RFC 7292），可存私钥、证书链、受信任证书，密码保护基于 PKCS#12 标准（更强），跨平台/跨语言兼容性好，是行业标准。差异：兼容性（JKS 仅 Java，PKCS12 通用）、安全性（PKCS12 密码保护更强）、包含内容（PKCS12 可含证书链）。Java 9+ 默认推荐 PKCS12（KeyStore.getInstance("PKCS12")），旧 JKS 用于兼容。工程应用：SSL/TLS 证书、私钥一般用 PKCS12 或 JKS 导入；keytool 生成/导入密钥库；Spring Boot 配置 server.ssl.key-store 指向 .p12 或 .jks。选型：现代项目优先 PKCS12（标准、安全、兼容），迁移旧 JKS 用 keytool -importkeystore。注意密钥库密码与密钥密码的保护，不应硬编码。

本题考察密钥库格式。核心是"JKS 仅 Java 且弱、PKCS12 标准兼容性强"。回答应点出推荐 PKCS12。

• PKI 的组成（CA、证书、信任链）
• X.509 证书结构
• 证书链验证

PKI（Public Key Infrastructure）是管理公钥、证书的体系，包含 CA（证书颁发机构）、RA（注册机构）、证书库、以及信任链。X.509 是证书的标准格式，包含：版本、序列号、签名算法、签发者（Issuer）、有效期（Validity）、主体（Subject）、公钥信息、扩展（如 SAN、KeyUsage）、以及 CA 对证书的签名。证书链验证流程：从目标证书（如服务器证书）开始，用上级（Intermediate）CA 的公钥验证其签名，再验证上级证书的签名，逐级回溯到根 CA（自签名受信任根），直到信任锚点（Trust Anchor）；验证内容：证书签名有效、有效期未过期、未吊销（CRL/OCSP）、KeyUsage 与 EKU 匹配、证书链完整、以及主机名验证（对 SSL 需校验 SAN/CN 与域名匹配）。Java 中 KeyStore 存受信任根，TrustManager/CertPathValidator 负责链验证。PKI 是 HTTPS/TLS 信任的基础，保障"公钥确实属于声称的主体"。注意：信任链验证依赖预置的根 CA 列表，以及证书吊销检查。

本题考察 PKI 与证书链。核心是"CA 层次 + 逐级签名验证 + 有效期/吊销/主机名". 回答应点出验证流程。

• 握手流程差异
• 性能与安全
• 密码套件

TLS 1.2 与 1.3 的主要差异：握手流程——TLS 1.2 需要 2 次往返（RTT，ClientHello→ServerHello→密钥交换→Finished），TLS 1.3 缩短为 1 次往返（1-RTT），并支持 0-RTT（重连时无需往返即可发数据，但需防重放）；密码套件——TLS 1.3 移除了不安全的算法（RSA 密钥交换、CBC、SHA-1 等），只保留 AEAD 加密（AES-GCM、ChaCha20-Poly1305）与基于 DHE/ECDHE 的前向保密，密码套件结构简化（不再含公钥算法与 MAC 算法）；密钥交换——TLS 1.3 强制前向保密（Ephemeral ECDHE），废除 RSA 密钥交换；会话恢复——TLS 1.3 用 PSK（预共享密钥）恢复会话，比 1.2 的 Session ID/Ticket 更高效；握手握手消息——TLS 1.3 合并了一些消息（如 ServerHello 后直接发送证书与密钥），并使用 key_share 提前发送密钥材料。安全性上 TLS 1.3 更强（默认前向保密、无弱算法、更抗降级）。工程上：现代系统应启用 TLS 1.3，禁用 TLS 1.0/1.1 及弱密码套件；Java 可通过 SSLContext/SSLParameters 配置协议版本与密码套件。

本题考察 TLS 1.2/1.3 差异。核心是"1.3 更少 RTT、强制前向保密、仅 AEAD 套件"。回答应点出握手与密码套件差异。

• 图片验证码的局限
• 无感验证（行为分析/设备信任）
• 演进趋势

人机验证从图形验证码演进到无感验证是为了平衡"安全性"与"体验"。早期图片验证码（数字/字母）通过人类识别对抗自动化，但存在可被 OCR/机器学习破解、用户体验差、对无障碍不友好等局限。演进方向：一是滑块验证/拼图验证——要求用户拖动滑块，加入轨迹行为分析，抗自动化更强；二是行为分析——采集鼠标轨迹、点击间隔、键盘节奏、触控行为等，通过模型判断是否人机（如无感验证码、reCAPTCHA 的隐形验证）；三是设备信任——基于设备指纹、历史行为、IP 信誉、Cookie 建立设备信任度，对可信设备/环境直接放行（无感），对可疑设备才升级验证（渐进式挑战）；四是双因素/多因素——高风险操作升级为短信/OTP/生物识别。整体趋势是从"被动挑战"到"主动分析 + 风险分级"：低风险用户无感通过，高风险用户渐进式验证。工程上：接入第三方（reCAPTCHA、腾讯云/阿里云验证码）或自建行为分析模型，结合设备指纹与风控策略，实现"无感为主、挑战为辅"的体验与安全平衡。

本题考察人机验证演进。核心是"从挑战式到无感行为分析 + 设备信任 + 风险分级"。回答应点出演进趋势。

• SM2/SM3/SM4 各自定位
• 国密合规场景
• Java 实现（BouncyCastle）

国密算法是中国密码标准，用于金融、政务、等保合规场景。SM2——椭圆曲线非对称算法，用于签名、密钥交换、加密（对标 ECC/ECDSA）；SM3——密码哈希算法，256 位输出（对标 SHA-256），用于完整性校验、HMAC、签名中的哈希；SM4——对称分组加密（128 位密钥、128 位块），用于数据加密（对标 AES），支持 ECB/CBC/CTR/GCM 等模式。工程应用：金融/政务系统在受信环境中使用国密套件（SSL 国密套件、数据加密、签名验签、数字证书）；合规要求用国密算法替换 RSA/AES/SHA-256。Java 实现：JDK 默认不含国密算法（SM2/SM3/SM4），需依赖 BouncyCastle（bcprov）注册 Provider 后使用——Cipher.getInstance("SM4/CBC/PKCS7Padding")、MessageDigest.getInstance("SM3")、KeyPairGenerator.getInstance("SM2")、Signature.getInstance("SM2withSM3")。也可用国密网关/HSM 硬件。注意：国密算法需在合规环境下使用，且生态系统（如 TLS 国密套件 SM2-SM3-SM4）支持有限，需配套 CA 与证书。工程上：数据加密用 SM4，签名用 SM2+SM3，哈希用 SM3，密钥管理用 KMS/HSM。

本题考察国密算法应用。核心是"SM2 非对称、SM3 哈希、SM4 对称，Java 用 BouncyCastle 实现"。回答应点出定位与实现。

• KDF 的概念
• 各 KDF 的参数与抗暴力
• 密码哈希 vs 密钥派生

KDF（Key Derivation Function）从密码、盐等输入派生密钥或哈希，广泛用于密码哈希与密钥派生。四种：PBKDF2——基于 PRF（如 HMAC-SHA256）迭代，参数为迭代次数、盐、输出长度，抗 GPU 靠迭代次数，但对内存无要求（GPU 可并行）；bcrypt——基于 Blowfish，内置盐，有 cost 参数，抗 GPU 靠迭代次数，但受限 72 字节密码；scrypt——除迭代外还要求大内存（memory-hard），提高并行攻击成本，抗 GPU 更强；argon2——密码哈希竞赛（PHC）获胜者，有 memory（内存）、iterations（迭代）、parallelism（并行度）参数，是 memory-hard 的现代标准，抗 GPU/ASIC 最强，推荐用于新系统。用途：密码存储用 bcrypt/scrypt/argon2（memory-hard 抗暴力）；密钥派生（如从密码派生加密密钥）用 PBKDF2/HKDF/Argon2。差异核心：内存强度（memory-hard）——scrypt/argon2 通过内存占用提升攻击成本，远超纯迭代的 PBKDF2/bcrypt。选型：新系统优先 Argon2（或 bcrypt 兼容性好），旧系统迁移 PBKDF2/bcrypt。

本题考察 KDF 与密码哈希。核心是"memory-hard 的 scrypt/argon2 抗 GPU 更强，argon2 是现代标准"。回答应点出参数与差异。

• KMS 与 Vault 的作用
• 密钥的集中存储与轮换
• 与应用的集成

密钥管理（KMS/Vault）用于集中、安全地管理应用的密钥（加密密钥、签名密钥、client secret 等），避免硬编码在代码/配置中。KMS（如 AWS KMS、阿里云 KMS、华为云 KMS）——云厂商的密钥管理服务，提供密钥的创建、存储、轮换、加密/解密/签名 API，密钥由 HSM 保护，应用通过 API 调用使用密钥（密钥不落应用）；Vault（HashiCorp Vault）——开源密钥管理工具，支持动态密钥、租约、加密即服务（Transit）、PKI 等，可集中管理 secret 并支持访问控制。工程实现：应用启动时从 KMS/Vault 获取密钥（或通过 SDK/API），密钥以环境变量/配置中心引用（如 vault:... 前缀供 Spring 加载）；密钥不写入代码仓库（用 .gitignore、Secret 管理）；集成方式：Spring Cloud Vault（spring-cloud-starter-vault）、云 KMS 的 SDK、Spring 的 EncryptablePropertySource（Jasypt）解密。密钥轮换：KMS/Vault 支持自动或手动轮换，应用需支持新旧密钥并存（按版本引用）。优点：集中管理、审计、自动轮换、硬件保护。原则：密钥不出 KMS/Vault 的受控环境，应用只引用不持有。

本题考察密钥管理。核心是"KMS/Vault 集中管理、应用引用不持有、支持轮换"。回答应点出集成方式。

• HMAC-SHA256 接口签名
• 重放攻击防护
• nonce/timestamp/有效期

接口签名用于确认请求真实性（防篡改、防伪造）。实现：客户端用共享密钥对"请求参数 + 时间戳 + 随机 nonce"按约定排序拼接后做 HMAC-SHA256，得到签名，随请求携带；服务端用相同密钥重算签名并比对，若一致则请求未被篡改且来自持密钥方。重放攻击防护三要素：timestamp——请求带时间戳，服务端校验与当前时间的偏差（如 ±5 分钟），过期请求拒绝；nonce——每次请求生成唯一随机数，服务端把已用 nonce 缓存（Redis SETNX，TTL 与有效期一致），重复使用同一 nonce 的请求被判定为重放并拒绝；签名有效期——通过 timestamp 窗口限制签名有效期，配合 nonce 防重放。综合流程：校验 timestamp 是否在窗口内 → 校验 nonce 是否已使用（未使用则记录）→ 重算 HMAC 比对签名。工程上：密钥由服务端与客户端共享（或客户端用私钥签、服务端公钥验——非对称），nonce 用 Redis 去重，签名用规范库（如 HmacUtils/Mac）。注意：签名只防"外部篡改/伪造"，仍需配合 HTTPS 防转录与防重放。

本题考察接口签名与防重放。核心是"HMAC-SHA256 签名 + timestamp 窗口 + nonce 去重"。回答应点出防重放三要素。

• 二次认证（2FA）机制
• 风险分级策略
• 渐进式认证

敏感操作（转账、改密、删除、提现）需二次认证（2FA）提升安全性。机制：OTP（一次性密码）——短信/邮件/认证器（TOTP）发送一次性验证码，用户输入后校验；扫码确认——App 内扫码或推送确认（如支付宝/微信），或 TOTP 扫描二维码绑定后生成动态码；还有生物识别、硬件 key 等。风险分级（低/中/高）策略：系统根据操作敏感度与用户行为环境评估风险等级——低风险（登录、浏览）直接放行；中风险（交易、改资料）要求常规校验（如验证码、短信）；高风险（大额转账、改密、解绑）要求二次认证（2FA）+ 风控规则（如额度、设备校验、人工审核）。渐进式认证：同一会话内风险等级随操作提升而升级认证强度；风险可结合设备指纹、IP、历史行为、金额阈值动态确定。工程上：2FA 用 Redis 存 OTP 状态（一次性、限时、限次数），TOTP 用 HmacOTP/TOTP 库；风险分级用规则引擎 + 风控模型；高风险操作记录审计并支持熔断。设计原则是"按风险动态增强认证，平衡安全与体验"。

本题考察二次认证与风险分级。核心是"OTP/扫码 2FA + 低中高风险分级 + 渐进式认证"。回答应点出分级与动态增强。

• 数字签名原理（私钥签、公钥验）
• RSA 与 ECDSA 签名
• 密钥对与流程

数字签名用于保证数据的完整性与不可否认性（来源认证）。原理：签名方用私钥对数据（或其哈希）签名，验证方用公钥验证——私钥签名、公钥验证，只有私钥持有者能生成有效签名，因此能证明数据来自签名者且未被篡改。流程：签名方对数据做哈希（如 SHA-256），用私钥对哈希签名得到签名值；验证方对收到的数据做相同哈希，用公钥验证签名是否匹配。RSA 签名（如 RSASSA-PKCS1-v1_5、PSS）——基于 RSA 私钥，签名与验证性能较慢，密钥较大；ECDSA 签名——基于椭圆曲线，密钥短、签名性能好，广泛用于现代系统（如 TLS、JWT ES256）。Java 中 Signature.getInstance("SHA256withRSA")/"SHA256withECDSA"，sign()/verify()。注意：签名与加密方向相反（签名用私钥、加密用公钥）；签名前需对数据哈希，避免对任意数据签名的风险；非对称签名适合完整性+认证，不能替代加密。证书链也基于签名——CA 用私钥对证书签名，验证方用 CA 公钥验证。

本题考察数字签名原理。核心是"私钥签名、公钥验证、哈希+签名"。回答应点出 RSA 与 ECDSA 差异。

• HMAC 的原理（密钥+哈希）
• 完整性保护
• 与数字签名/哈希的区别

HMAC（Hash-based Message Authentication Code）是基于密钥的哈希消息认证码，HMAC(key, message) 用共享密钥和哈希函数（如 SHA-256）计算一个认证标签，用于验证消息完整性与来源认证（持密钥者）。原理：把密钥与消息通过特定方式（inner/outer padding + 哈希）组合计算，即使消息被篡改，标签也会变化；且没有密钥无法伪造标签。与哈希的区别：普通哈希（如 SHA-256）无密钥，只能防意外损坏，攻击者能轻易重算篡改后的哈希；HMAC 带共享密钥，能防恶意篡改（无密钥无法伪造）。与数字签名（RSA/ECDSA）的区别：HMAC 用共享对称密钥（签发与验证用同一密钥，只能证明"持密钥者"，无法区分具体签名者、不可否认）；数字签名用非对称密钥（私钥签、公钥验，可证明特定签名者、提供不可否认性）。完整性保护应用：HMAC 用于接口签名（防篡改+防重放配合）、JWT 的 HS256、消息传输完整性；数字签名用于需要证明签发者的场景（证书、JWT RS256）。Java 用 Mac.getInstance("HmacSHA256")。

本题考察 HMAC。核心是"带密钥的认证码，防恶意篡改，与签名区别在对称/非对称"。回答应点出 HMAC 与哈希/签名的区别。

• 实时规则引擎
• 离线模型（机器学习）
• 协同与特征

行为风控通过分析用户行为特征识别风险。实时规则：基于频率（请求次数、操作频率）、地理位置（IP 归属地、设备定位）、设备切换（设备指纹变化、新设备登录）等特征，用规则引擎（如 Drools、自研 DSL）实时判定风险，命中规则（如"1 分钟 5 次转账失败"、"异地登录"、"新设备+大额操作"）即拦截或升级验证。离线模型：用机器学习（如 XGBoost、GBDT、深度学习）基于历史数据训练风险模型，对行为特征打分（风险分），离线批量评估或在线推理。协同机制：实时规则保证低延迟、可解释的兜底拦截（适合明确规则、紧急拦截）；离线模型提供综合评分、发现未知模式（适合复杂、模糊风险）；两者结合——先实时规则快速拦截明确风险，对未命中规则的请求用模型评分进行风险分级，结合设备/IP/行为特征做动态决策（放行/挑战/拦截）。特征共享：实时与离线共用特征（设备指纹、IP、频率、行为序列）。工程上：实时规则存于配置/规则引擎（可热更新），模型定期训练并发布，在线推理用特征服务；A/B 检验规则效果。整体是"规则快、模型准、协同分级"。

本题考察实时规则与离线模型协同。核心是"实时规则快速可解释、离线模型综合评分、协同分级决策"。回答应点出协同机制。

• ZKP 的原理
• 工程应用（区块链、隐私）
• 落地难点

零知识证明（ZKP）允许证明者向验证者证明"某个陈述为真"，而不泄露任何额外信息（除了该陈述为真的事实）。核心特性：完备性（真陈述可证明）、可靠性（假陈述无法证明）、零知识（验证者不获得额外信息）。工程应用现状：区块链——zk-SNARKs/zk-STARKs 用于隐私交易（如 Zcash）、Layer2 扩容（zk-rollup）、隐私计算；身份认证——证明"我拥有某凭证/满足某条件"而不泄露具体内容；隐私保护——在不暴露数据的前提下证明数据满足条件。落地难点：计算与证明开销（生成证明成本高、依赖椭圆曲线/多项式承诺等复杂密码学）、可信设置（部分 SNARK 需要可信初始化，存在安全假设）、工程复杂度（算法与电路实现难度大）、通用性受限（针对特定陈述需设计电路）。Java 生态：ZKP 库与工具相对有限（如 zk 库、以太坊相关），生产落地多集中在区块链/金融领域。整体：ZKP 技术路线明确但工程化仍在演进，适合特定隐私/扩容场景，通用业务落地成本较高。

本题考察 ZKP 工程现状。核心是"原理 + 区块链/隐私应用 + 计算/可信设置/复杂度难点"。回答应点出落地现状。

• 规则热更新机制
• 灰度发布与 A/B 测试
• 规则版本管理

风控规则需要快速迭代，热更新与灰度发布是关键。规则热更新：把规则从代码中剥离，存于配置中心（如 Nacos/Apollo）或数据库，规则引擎（如 Drools、自研 DSL）运行时加载，支持规则变更无需重启服务即时生效；需保证规则版本管理、原子切换、异常回滚。灰度发布：新规则先在小流量/白名单用户上生效，验证效果后再全量。A/B 测试规则效果：把流量按 hash 分流到 A（旧规则）与 B（新规则）两组，对比两组的指标（如拦截率、误杀率、转化率、投诉率），评估新规则是否更优、是否需调整阈值，再决定放量或回滚。实现要点：规则引擎支持按版本/条件加载；灰度开关（流量比例、用户维度白名单）配置化；指标采集埋点（拦截、放行、误伤、业务指标）；A/B 分组打标（用户/请求 hash 到组）；监控与告警。工程上：用配置中心分发规则版本，规则引擎缓存并支持热加载，A/B 实验平台管理分层实验，全量前充分验证。目标是"快速迭代 + 可控风险"。

本题考察规则热更新与灰度。核心是"规则配置化热加载 + 流量分流 A/B 对比效果 + 可控放量"。回答应点出实现要点。

• 布隆过滤器原理
• 黑名单/设备指纹的快速判断
• 误判率控制

布隆过滤器（Bloom Filter）是一种空间高效的集合成员判断数据结构，用 k 个哈希函数映射到位数组，查询"是否存在"可能误判存在（假阳性）但不会误判不存在（无假阴性）。风控场景：用于黑名单/设备指纹的快速判定——判断一个设备指纹/手机号/IP 是否在黑名单中，用布隆过滤器在内存中快速过滤，避免每次都查数据库/Redis 大表，极大提升查询性能。误判率控制：误判率由位数组大小 m、哈希函数个数 k、元素数量 n 决定（p ≈ (1-e^(-kn/m))^k）；可通过增大 m、优化 k、预估 n 来降低误判率；业务上误判（把非黑名单判定为黑名单）会导致误伤，因此常采用两级过滤：布隆过滤器做快速粗筛（可能误判），命中后二次精确验证（查真实黑名单库/Redis 确认），避免误伤；或用计数型布隆过滤器支持删除。规则引擎则负责把命中结果与上下文（频率、设备）组合成决策。要点：布隆过滤器"宁放过不误伤精确"的策略——粗筛命中后必须精确复核，消除假阳性。

本题考察布隆过滤器在风控的应用。核心是"布隆过滤器快速判断 + 假阳性需二次精确验证"。回答应点出误判率控制。

• JEP 470/JEP 524 的内容
• PEM Encodings 能力
• 预览边界与影响

JEP 470 与 JEP 524 是 JDK 中关于 PEM 编码支持的改进（PEM Encodings）。JEP 470（PEM Encodings）为 JDK 的 PKCS8EncodedKeySpec/X509EncodedKeySpec 等提供新的 PEM 编码/解码 API，使 Java 能直接处理 PEM 格式的密钥（-----BEGIN PRIVATE KEY----- 等）与证书，而不必依赖 BouncyCastle 等第三方库。JEP 524 进一步扩展/完善 PEM Encodings 能力（如支持更多 PEM 类型、更完善的 API）。预览边界：这些 JEP 以预览特性（Preview） 形式在 JDK 发布，需在编译/运行时启用 --enable-preview 才能使用；API 可能在未来版本变更，不保证兼容；生产环境默认不启用预览（需显式打开）。工程影响：若项目需要 PEM 解析，可关注并谨慎使用预览 API；正式依赖应等特性稳定（非预览）后再采用，或继续使用 BouncyCastle。预览边界意味着"功能可用但不稳定、需手动开启"。注意：JEP 编号与版本以官方 JDK 发布为准，此处指 PEM 相关预览特性。

本题考察 JDK PEM 预览特性。核心是"PEM 编码 API 以预览特性发布，需 --enable-preview，API 可能不稳定"。回答应点出预览边界。

• 审计日志的字段设计
• 可追溯性（操作人/时间/设备/结果）
• 审计合规与不可篡改

业务安全事件的审计日志用于事后追溯与合规，需记录完整上下文。关键字段：操作主体（操作人 userid/username、角色、租户）、操作时间（时间戳、时区）、设备/环境（设备指纹、IP、User-Agent、浏览器/OS、地理位置）、操作对象（资源类型、资源 ID、操作前值/操作后值）、操作结果（成功/失败、错误码、影响行数）、行为上下文（请求 ID、会话 ID、来源页、操作类型/动作）、安全上下文（当时的风险等级、二次认证结果）。设计要点：一是结构化——用 JSON 或字段化存储便于查询；二是不可篡改——审计日志建议追加写、权限受限、哈希链或专用审计库，防止被篡改；三是集中存储——上报到日志平台/审计系统（如 ELK、审计数据库），支持检索与告警；四是脱敏——对敏感字段（密码、手机号）脱敏；五是保留与合规——按合规要求保留周期。可追溯性价值：定位异常操作、追责、法律合规、安全事件调查。工程上：用 AOP/拦截器统一记录，异步写审计，结合请求 ID 串联全链路。

本题考察审计日志设计。核心是"记录主体/时间/设备/对象/结果/上下文 + 不可篡改 + 集中存储"。回答应点出字段与可追溯性。