[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [pkcs11] Strong User authentication - Discussion thread
Hi Mike We use the context in the extended login to provide a struct pointer with function pointers inside of that. That’s worked for both an RSA based and biometric
based additional login mechanism for us. Here’s a snippet of code from my test mechanism provider – I’ve not included most of the RSA credential provider because it’s long – what’s there should be enough to provide an idea of how it works. The biometric
credential provider enum { BIOMETRIC_AUTH_CRED = 0, RSA_AUTH_CRED }; typedef CK_ULONG (*auth_func_ptr)(CK_VOID_PTR cred, CK_NOTIFY callback); typedef struct { CK_ULONG cred_type; /* Which type of auth is this? */ auth_func_ptr auth_func; /* Callback to do the actual auth */ } auth_cred_t; static CK_ULONG biometric_auth(CK_VOID_PTR cred, CK_NOTIFY callback); static CK_ULONG rsa_auth(CK_VOID_PTR cred, CK_NOTIFY callback); static auth_cred_t auth_creds[] = { { BIOMETRIC_AUTH_CRED, biometric_auth }, { RSA_AUTH_CRED, rsa_auth } }; static CK_ULONG rsa_auth(CK_VOID_PTR cred, CK_NOTIFY callback) {
CK_EXTENDED_LOGIN *login = (CK_EXTENDED_LOGIN *)cred; if(!login || !callback) return CKR_DEVICE_ERROR; printf("RSA authorization provider invoked\n"); /* Generate an RSA challenge for the user */ […] /* Send out the challenge */ callback(session, CKN_EXT_LOGIN_WRITE, (CK_VOID_PTR)login); /* Read back the response */ callback(session, CKN_EXT_LOGIN_READ, (CK_VOID_PTR)login); […] /*Verify the response */ […] } static CK_ULONG biometric_auth(CK_VOID_PTR cred, CK_NOTIFY callback) { if(!cred || !callback) return CKR_DEVICE_ERROR; printf("Biometric authorization provider invoked\n"); [….] return CKR_OK; } CK_ULONG sw_extended_login(CK_EXTENDED_LOGIN *ext_login) { CK_NOTIFY callback; CK_RV rv = CKR_OK; int i; if(!ext_login) return CKR_ARGUMENTS_BAD; /* Get the callback function */ if((rv = sw_get_session_callback((CK_SESSION_HANDLE)ext_login->context, &callback)) != CKR_OK) return rv;
/*
* Given the choice of auth creds now available, * pick from the order available */ for(i = 0; i < sizeof(auth_creds) / sizeof(auth_cred_t); i++) { switch(auth_creds[i].cred_type) { case RSA_AUTH_CRED: case BIOMETRIC_AUTH_CRED: auth_creds[auth_creds[i].cred_type].auth_func(ext_login, callback); break; default: rv = CKR_DEVICE_ERROR; } } return rv; } My intention in doing it this was way to provide some means to preserve as much backward compatibility as possible and to allow people to arbitrarily define
the “strong auth” mechanisms as they saw fit, while trying to keep the interface consistent. Given that the callback is just a means to move data in and out, and the token is free to do whatever it needs with said data, it should be able to accommodate
pretty much anything. Thoughts? --Chris From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org]
On Behalf Of Michael StJohns For the purposes of this discussion, I'm considering strong authentication as authentication that's resistant or immune to replay attacks and to attacks based on the capture of the login interaction. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]