Tencent soter生物认证原理
https://blog.csdn.net/peilong1988/article/details/88253704
一、分析了下腾讯Soter的原理和开源代码。
开源代码：https://github.com/Tencent/soter
三级密钥管理（采用的RSA2048密钥）
ATTK：设备根密钥，在设备出厂前在TEE中生成，公钥通过安全通道传输到腾讯TAM服务器，私钥存储在RPMB
ASK：App Secure Key，应用密钥，在应用启动时生成，每个应用生成一个
AuthKey：Authentication Key，业务密钥，应用内每个业务生成一对
主要流程解析
1、生成ASK
通过Android keystore机制，在TEE中生成ASK公私钥对，公钥结构体使用ATTK签名后导出并上传，私钥加密存储在文件系统中
2、生成AuthKey
与ASK流程基本上一致，在TEE内生成公私钥对，公钥结构体使用ASK签名后导出并上传，私钥加密存储在文件系统中，使用时需要认证生物特征进行授权
3、认证流程
应用通过用户指纹授权后，将请求的挑战因子（challenge）作为签名对象，通过keystore调用指定的AuthKey私钥进行签名，组装的JSON签名结果中包含了挑战因子、用户使用的手指（fid）、其他设备信息及签名值。其中，指纹验证的fid在TEE中自动读取并被组装到报文中，黑客是无法伪造。
转自： https://blog.csdn.net/u014135607/article/details/79874351
TENCENT SOTER之所以能实现支付级别的指纹授权安全性，主要原因有三：
-
所有关键数据存储与操作均根本依赖TEE
-
厂商在设备出厂之前安全环境会专门生成TENCENT SOTER设备根密钥
-
生物授权的实质是密钥签名，TEE级别保证“无授权，不签名”。
Soter 架构
TENCENT SOTER中，一共有三个级别的密钥：ATTK，App Secure Key(ASK)以及AuthKey。这些密钥都是RSA-2048的非对称密钥。
所有的密钥都由TEE（一个独立于Android系统的安全环境，这也是TENCENT SOTER能解决root下手机认证的关键所在）保护安全保存。这也就意味着除了数据所有者之外，没有人可以使用私钥。更重要的是，如果密钥是在TEE中生成的，所有人——包括微信、厂商等——都无法得到密钥私钥。一句话总结，TENCENT SOTER中所有非对称密钥均是在TEE内部生成的，即使设备被root，私钥也不会泄露。
除了密钥之外，TENCENT SOTER所有关键流程，如签名等，均在TEE中进行，这也保证了核心流程不会被恶意应用篡改。
工作流程
ATTK（设备密钥）私钥在设备出厂之前就已经在TEE中生成，公钥被被厂商安全得传输到腾讯的TAM服务器，私钥则在TEE中安全存储。
第三方应用能且只能在TEE中生成唯一ASK（应用密钥）。一旦ASK被成功生成，私钥被存储在TEE中（或者更加准确地说，被TEE中安全密钥加密存储在手机sfs中，等同于存储在TEE中，即使手机被root了也是安全的）。公钥结构体（包含公钥信息以及其他辅助信息）导出的时候会自动带上ATTK对公钥数据的签名。应用开发者将公钥结构体以及ATTK对该结构体的签名通过微信开放平台接口（见接口文档）发送到TAM服务器认证公钥结构体合法性。如果合法，则第三方保存该结构体备用。
对于每一个业务场景，你应该生成一对AuthKey（业务密钥）用于该场景指纹认证。AuthKey的生成过程与ASK类似——在TEE中生成，私钥在TEE中保存，公钥上传到服务器。不同的是，第三方应用应该自己检查AuthKey的合法性（实际上，我们真的不想知道你们的用户做了多少笔支付）。同时，生成AuthKey的时候，需要标记私钥只有在用户指纹授权之后才可以使用（正如Google在标准接口中定义的那样）。
在认证之前，应用需要先向自己的服务器请求一个挑战因子（通常是一个随机串）作为用于签名的对象。用户指纹授权之后，你将可以导出一个JSON结果，其中包含了你刚刚请求的挑战因子、用户使用了哪个手指（fid）以及其他设备信息，和这个JSON结果对应AuthKey的签名。之后，将他们发送到自己的服务器，自己使用之前存储的AuthKey公钥验签就好。其中，fid也是在TEE中自动读取并连同结果一起被签名的，也就是说，黑客是无法伪造。
以上，就是TENCENT SOTER的原理，欢迎留言讨论。
https://cloud.tencent.com/developer/article/1005987
-
信任根的重要性之前已经说明。如果一个系统依赖密钥签名，有一个可以信任的根密钥，才有可能构建安全的信任模型。
-
所有从TEE中出来的敏感数据，就一定要添加上使用可信密钥对其的签名了。
-
有了设备根密钥之后，认证链的构造逻辑就清晰了很多：采用密钥链的形式，用已认证的密钥来认证未认证的密钥就可以了！
准备应用密钥流程示意图
-
应用第一次启动时，或者在第一次使用业务之前，请求生成设备根密钥;
-
密钥生成之后，私钥在被TEE保护，加密存储;
-
公钥和设备ID等相关信息，在TEE内直接被设备密钥私钥签名之后，返回给应用;
-
应用将公钥相关信息和签名传输至应用后台;
-
应用后台通过微信公众平台后台接口，请求验签;
-
TAM使用对应的设备密钥公钥验签，通过之后返回给应用;
-
应用后台存储对应的应用公钥。
注1：自设备出厂即在TEE中存储。每一次SOTER相关操作都会使该值自增，后台存储该放重放因子。如果后台发现本次请求防重放因子比已记录的值小，则可认为是非法请求。
注2：本意为Linux系统中用户ID，在Android系统中，一般而言每一个应用都有一个uid，可用于区分应用以及权限控制。注意，uid不同，对应的应用密钥与业务密钥均不同，后台应将uid与cpu_id一起区分密钥。