指纹支付相关的细节处理

https://blog.csdn.net/g241893312/article/details/79629503

 

指纹支付相关的细节处理(以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

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

4. 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 还有支付厂商的事情。