指纹支付相关的细节处理

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

 

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

一. AuthToken 处理

AuthToken process

1.AuthToken 格式及定义(CA侧要跟TA侧相同)

    AuthToken format

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