指纹支付相关的细节处理(以QSEE为例)

一. AuthToken 处理

1.AuthToken 格式及定义（CA侧要跟TA侧相同）

AuthToken format

    typedef struct __attribute__((__packed__)) {        uint8_t version;  // Current version is 0        uint64_t challenge;        uint64_t user_id;             // secure user ID, not Android user ID        uint64_t authenticator_id;    // secure authenticator ID        uint32_t authenticator_type;  // hw_authenticator_type_t, in network order        uint64_t timestamp;           // in network order        uint8_t hmac[32];    }   hw_auth_token_t;        Version ：此token的版本号        Challenge：就是前面调用preEnroll的到的64位随机数，防止此次enroll被第三方假冒        User SID ： 安全性id，不是android user id        Athenticator ID： 用于标明不同的认证权限        Authenticator Type：0x00表示Gatekeeper，0x01表示Fingerprint        Timestamp：最近一次开机时间戳        AuthToken HMAC key： 用一个特殊的key和SHA-256算法去计算前面一堆参数后，得到的一个 hmac值，保证前面参数的合法性和安全性。

2.从Keymaster TA 与Auth Token key

Fingerprint HAL Open时,Fingerprint HAL(以后简称HAL)向Keymaster发送KEYMASTER_GET_AUTH_TOKEN_KEY 命令，并得到返回的加密key。
HAL向指纹TA(以后简称TA)发送命令，以内存数据共享方式，向TA传输从Keymater 获取到的加密key.
TA 使用qsee_decapsulate_inter_app_message()方法，通过加密key 来获取Keymaster TA的解密key

TA在authenticate时候，自己创建Token 并调用QSEE的qsee_hmac()方法，使用QSEE_HMAC_SHA256 类型算法来加密token ,并共享给其他TA (Keymaster TA,Gatekeeper TA ,还有bio TA)

retval = QSEEcom_start_app(&keymaster_handle,                        OXI_KEYMASTER_APP_PATH,                        OXI_KEYMASTER_APP_NAME,                        shared_buffer_zise);km_get_auth_token_req_t* command = (km_get_auth_token_req_t*)    keymaster_handle->ion_sbuffer;uint32_t command_length = QSEECOM_ALIGN(sizeof(km_get_auth_token_req_t*));km_get_auth_token_rsp_t* response = (km_get_auth_token_rsp_t*)    (keymaster_handle->ion_sbuffer+command_length);command->cmd_id = KEYMASTER_GET_AUTH_TOKEN_KEY;command->auth_type = HW_AUTH_FINGERPRINT;uint32_t response_length = shared_buffer_zise-command_length;retval = QSEEcom_send_cmd(keymaster_handle,                        command,                        command_length,                        response,                        response_length);

二. Fingerprint HAL 跟Fingerprint TA 细节处理

1.pre_enroll()方法：

TA侧创建challenge并保存，TA把此challenge回传给HAL,在pre_enroll 方法里面，直接return 这个challeng值

2.enroll(…,const hw_auth_token_t *hat,…)方法：

enroll 的时候，系统会传一个token给Fingerprint HAL，HAL层需要把此token传给TA侧,TA做如下相关处理：

1).TA侧会对token里面的challenge跟在pre_enroll时候，TA保存的challenge 的值做对比。

2).TA侧会，根据从keymaster TA得到的加密key,用qsee_hmac()方法，使用QSEE_HMAC_SHA256类型的HMAC 加密，比较两个hmac 数组内容是否一致,
如果不一致，则中断enroll进程，直接return掉。

//核对传递下来的token->challenge与之前preEnroll阶段保存的g_challenge是否相同if (token && token->challenge == g_challenge) {    g_user_id = token->user_id;} else {    LOGE(LOG_TAG "[%s] invalid or null auth token", __func__);}//检测token版本是否相同if (token && token->version != cmd->data.enroll.system_auth_token_version) {    LOGE(LOG_TAG "[%s] invalid hat version code detected", __func__);    err = ERROR_INVALID_HAT_VERSION;    break;}//检测authenticator_type版本是否相同if (token && (token->authenticator_type & GF_HW_AUTH_FINGERPRINT)) {    LOGE(LOG_TAG "[%s] invalid challenge detected", __func__);    err = ERROR_INVALID_CHALLENGE;    break;}/*token中，除了hmac之外的数据取出来，然后拿这部分数据用key和相应加密算法生成hmac*/cpl_memcpy(&hat, token, sizeof(gf_hw_auth_token_t));cpl_memset(&(hat.hmac), 0, hmac_len);generate_hmac(&hat);/*比对新生成的hmac和之前上层传递下来token中自带的hmac是否相同，如果相同则认为没本次enroll合法，接下来IC就会切换到一种采图的工作模式*/if (0 != cpl_memcmp(hat.hmac, token->hmac, hmac_len)) {    LOGE(LOG_TAG "[%s] token authenticate failed", __func__);    err = ERROR_UNTRUSTED_ENROLL;    break;}

3.user_id问题：

user_id是在enroll的时候系统传给fingerprint HAL层的，HAL层需要把这个值传到fingerprint TA中与指纹模板进行绑定,enroll时候系统传进来的user_id
是多少，则authenticate 成功后回传给系统的user_id就应该是多少。

1).user_id 在 enroll 完成后生成指纹模板时，与指纹模板绑定。
2)在指纹匹配成功后，获取user_id，把此值赋值给TA创建的Token中的user_id元素。

3).TA会对Token 进行HMA 算法加密。

4).TA会把包含user_id 的Token 传给fingerprint Hal,由Hal 回调给系统。

4.authenticator_id问题:

在enroll 成功完成之后，需要根据生成指纹模板的数据库id 来生成authenticator_id，此来生成authenticator_id 会在两个地方使用;

1).此值需要回传给fingerprint Hal，在get_authenticator_id()方法里面，直接返回。

2).在指纹匹配成功后,在TA创建Token，把此值赋值给Token中的authenticator_id元素。

3).TA会对Token 进行HMA 算法加密。

4).TA会把包含authenticator_id 的Token 传给fingerprint Hal,由Hal 回调给系统。

5.operation_id问题：

这个值很重要，因为支付的bio接口会用到此值，使用步骤如下：

1).authenticate(…, uint64_t operation_id,…)的时候，系统会把这个值传递给fingerprint HAL, Hal 层需要传递此值到fingerprint TA;

2).在指纹匹配成功后，在TA创建Token，把此值赋值给Token中的challenge元素。

3).TA会对Token 进行HMAC算法加密

4)调用bio接口set_auth_result(),把此operation_id 传给bio 接口。

    int32_t set_auth_result(boolean result, uint64_t finger_id, uint64_t operation_id){ int32_t status = 0; bio_result bio_res; BIO_ERROR_CODE bio_err; bio_res.method = BIO_FINGERPRINT_MATCHING; bio_res.result = result; bio_res.user_id = BIO_NA; if (bio_res.result) {      bio_res.user_entity_id = finger_id;      bio_res.transaction_id = operation_id;//session_id } else {      bio_res.user_entity_id = BIO_NA;      bio_res.transaction_id = BIO_NA; } if ((bio_err = bio_set_auth_result(&bio_res, NULL)) != BIO_NO_ERROR) {      status = -1; } return status;}

三. 支付宝、微信支付

支付这块，需要实现两个接口，一个是指纹list接口，一个是匹配成功的接口。

1).指纹list 接口，需要在初始化，指纹模板增、更新、删除的时候调用，具体需要参照代码

2).匹配成功的接口(上面的set_auth_result就是)，需要在指纹匹配成功之后，在TA进行Token HMAC 加密之后调用

这个两个接口最终都是调用bio API 的bio_set_auth_result() 方法。我们指纹厂商，只需要实现前面的细节，跟上面两个接口即可，剩下的都是平台，TEE 还有支付厂商的事情。

指纹支付相关的细节处理