InsightFace Server 信任密钥体系用 Ed25519 公钥离线校验 MODEL.LICENSE 模型授权【免费下载链接】insightfaceState-of-the-art 2D and 3D Face Analysis Project项目地址: https://gitcode.com/GitHub_Trending/in/insightface本文围绕 InsightFace Server 后端中的可信模型授权公钥server/backend/insightface_server/licensing/trusted_keys/展开这个目录存放的是 InsightFace 签发的 Ed25519 公钥用于在完全离线的环境下校验每个模型包附带的MODEL.LICENSE签名文件。读完本文你将理解该公钥的密钥指纹如何本地复核、验证器如何从该目录加载并匹配密钥、MODEL.LICENSE的完整字段结构与签名流程以及公钥入库、私钥隔离这一安全边界在源码、测试与容器构建中是如何被强制落地的。这个目录里有什么trusted_keys目录只承担一件事保存 InsightFace 模型授权体系的可信公钥。按 trusted_keys/README.md 的说明insightface-model-license-public-ed25519.pem是当前生效Status: active的 InsightFace Ed25519 公钥专门用于离线验证MODEL.LICENSE文件该密钥激活日期为 2026-07-22公钥 DER 编码的 SHA-256 指纹为afa29e9508d9ae7a1308974a8f044a49e1d2c8ed7dba6f2a02f66ce0c450181d。公钥文件本体是一个标准的 PEM 封装的 Ed25519 SubjectPublicKeyInfo-----BEGIN PUBLIC KEY----- MCowBQYDK2VwAyEAJyP2ZksitIXEOZX1cOauRUbsnmNvNmEAA5aXvcNUsA8 -----END PUBLIC KEY-----对应的仓库路径为 insightface-model-license-public-ed25519.pem。MCowBQYDK2Vw这一 DER 前缀是 Ed25519 公钥1 字节参数长度 32 字节原始密钥在 SubjectPublicKeyInfo 中的固定编码特征因此该指纹实际唯一标识的就是那 32 字节原始公钥。如何本地复核公钥指纹README 给出的 SHA-256 指纹是对公钥DER 编码计算的。只要机器上有 OpenSSL就可以不依赖任何 Python 依赖复算它openssl pkey -in server/backend/insightface_server/licensing/trusted_keys/insightface-model-license-public-ed25519.pem \ -pubin -outform DER | sha256sum在本文撰写时按此命令对仓库内文件实际执行输出与 README 完全一致afa29e9508d9ae7a1308974a8f044a49e1d2c8ed7dba6f2a02f66ce0c450181d这就是运维场景下确认我拿到的公钥就是发布方声明的那把的标准做法。由于验证是纯本地密码学运算Ed25519 验签不需要网络、时间戳服务或证书链InsightFace Server 可以在 air-gapped无外网环境中完成模型授权校验这也是 README 强调 verify MODEL.LICENSE files offline 的设计意图。验证器如何加载 trusted_keys公钥目录的消费方是 licensing/model_license.py 中的_trusted_keys()函数。它实现了验证器与密钥目录之间的约定默认目录未显式传入目录时使用Path(__file__).with_name(trusted_keys)即与本模块同级的trusted_keys目录——因此打包安装insightface_server时密钥必须随 wheel 一起分发加载规则对目录下所有*.pem文件按文件名排序逐个用cryptography的serialization.load_pem_public_key解析类型强校验解析出的密钥若不是Ed25519PublicKey实例直接抛出ModelLicenseError防止混入其他算法的公钥空目录即失败一个.pem都没有时抛出 No trusted InsightFace model-license keys found验证器不会降级为跳过签名校验。一个细节值得关注glob(*.pem)之后还有一道if not path.name.startswith(.)过滤。其动机来自 tests/unit/test_model_license.py 中的test_trusted_keys_ignore_macos_appledouble_filesmacOS 压缩包会附带._xxx前缀的 AppleDouble 元数据文件若不过滤这类文件若以.pem结尾就会被当作密钥加载并在解析阶段炸掉验证流程。该测试把真实仓库公钥复制进临时目录、再塞入一个伪 AppleDouble 文件断言_trusted_keys只识别出 1 把密钥。verify_model_license()在签名验证阶段把目录里的所有公钥都作为候选for key in keys: try: key.verify(signature, signed) break except InvalidSignature: continue else: raise ModelLicenseError(Model license signature verification failed)从源码结构看这是为密钥轮换预留的新旧两把公钥可以短暂同时存在于此目录旧密钥签发的存量MODEL.LICENSE仍能被新代码验证直到存量授权过期或续签后移除旧公钥即可。MODEL.LICENSE 的字段结构与签名方式trusted_keys 目录是验签的一端另一端是被验签的MODEL.LICENSE。model_license.py 定义的格式LICENSE_VERSION 1如下字段必填约束license_version是必须等于 1license_id是非空字符串≤256 字符issuer是必须精确等于InsightFacemodel_id是正则^[A-Za-z0-9][A-Za-z0-9._-]{0,127}$且必须与当前加载的模型 ID 一致grant是non-commercial或commercial之一valid_from是UTC 时间戳ISO 8601以Z结尾signature是64 字节 Ed25519 签名base64url 编码无填充customer/reference/valid_until否字符串≤256 字符valid_until若存在必须晚于valid_from业务规则上还有两条硬约束grant为commercial时必须提供customer字段否则视为商业授权无法落实到具体客户直接拒绝JSON 解析启用_reject_duplicate_keys重复字段名会直接报错避免后值覆盖前值的 JSON 注入。签名对象不是原始文件字节而是规范化的字段集合canonical_license_bytes()剔除外signature字段后用 RFC 8785JCSJSON Canonicalization Scheme序列化再签名。这保证了字段顺序、空白差异不影响验签同时任何对已签字段如把non-commercial篡改为commercial的改动都会导致签名失败。仓库自带 4 份由该公钥体系签发的默认授权例如 defaults/buffalo_l/MODEL.LICENSE{ license_version: 1, license_id: buffalo_l-public-v1, issuer: InsightFace, model_id: buffalo_l, grant: non-commercial, valid_from: 2021-09-22T00:00:00Z, signature: mkF_zjs_gw5lzWlN6DXlBWPY6ZK7diTGoSORdp33ISLegqxSrL930a--bHEGOOiUO4n-W9kX5qQc6kbEkGnUBQ }同级的antelopev2、buffalo_m、buffalo_sc三份默认授权位于 licensing/defaults 目录下。测试test_bundled_public_license_verifies_with_active_public_key正是用仓库内置的这份buffalo_l授权 trusted_keys目录中的公钥完成一次真实验签断言issuer InsightFace且grant non-commercial——它同时验证了内置授权与内置公钥确实配对这一发布一致性。值得强调的一个设计决策见 model_license.py 顶部 docstring授权只绑定逻辑model_id不绑定 ONNX 文件摘要。这意味着运维方可以把同一模型转成 FP16、INT8、优化后的 ONNX 甚至 TensorRT 引擎而无需重新申请授权models/packages.py 的模块注释对同一策略做了呼应。从 CLI 到模型安装的完整校验链trusted_keys最终服务于 InsightFace Server 的模型安装与运行前检查。整条链路如下安装时models/packages.py 的install_package()在解包模型文件的同时写入MODEL.LICENSE取自 defaults 目录 中对应模型的内置授权随后调用verify_model_license(license_path, expected_model_idpackage.name)_ensure_model_license()对已存在的授权同样先验签再复用防止安装目录中的授权文件被中途替换。许可证确认models_cli.py 在安装前打印license_notice()Non-commercial research use only 等提示非交互环境必须显式传--accept-license否则直接报错避免无人值守安装绕过授权确认。离线复核verify子命令调用verify_installed()内部再次执行verify_model_license()通过_print_verified_license()打印LICENSE VERIFIED、Issuer、License ID、Model ID、Grant 等public_summary()字段供脚本化巡检使用。测试 tests/unit/test_model_license.py 用临时生成的 Ed25519 私钥构造授权系统性地覆盖了篡改场景把grant改成commercial会触发 signature verification failedmodel_id与期望不符会触发 not the active modelissuer非 InsightFace 会被拒绝valid_until早于当前时间会判定过期commercial授权缺customer被拒。这些用例就是trusted_keys这套机制防什么的精确清单。公钥入库、私钥隔离的安全边界README 最后一段定义了该目录的边界纪律只有公钥可以进入这里签发用的私钥必须留在仓库根目录、被 Git 忽略的.private/license-issuer/中且绝不允许进入源码归档或容器镜像。这条策略不是文档口号而是被容器契约测试强制执行的tests/docker/test_container_contract.py 断言仓库根.dockerignore包含.private/与**/*.pem注意后者意味着除后端包内随源码发布的 trusted_keys 公钥外任何散落的 PEM 都不会进镜像——这里的取舍是私钥从不落库而公钥必须随insightface_server包发布以保证离线可验签.gitignore包含.private/。因此在密钥轮换时的安全动作是新公钥提交进trusted_keys并更新 README 的激活日期与 DER SHA-256 指纹旧公钥在存量授权过渡期结束后移除而签发侧永远只操作.private/license-issuer/下的私钥。小结trusted_keys/是 InsightFace Server 离线模型授权体系的信任根一把或多把轮换中的Ed25519 公钥 README 中可复核的 DER SHA-256 指纹即可在无网络环境下判定MODEL.LICENSE是否由 InsightFace 合法签发公钥指纹可用一行 OpenSSL 命令本地复算与 README 声明值afa29e…181d一致验证器对该目录的读取规则仅*.pem、忽略._元数据文件、类型强校验、空目录即失败由 model_license.py 实现并有对应单元测试私钥与公钥的物理隔离.private/license-issuer/vstrusted_keys/由.gitignore、.dockerignore及容器契约测试共同保证该机制只校验授权的合法性与有效期签名、issuer、model_id 作用域、grant、时间窗具体商业/非商业使用条款见 LICENSING.md。【免费下载链接】insightfaceState-of-the-art 2D and 3D Face Analysis Project项目地址: https://gitcode.com/GitHub_Trending/in/insightface创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考