I've previously written about innovative approaches to strong identity management which we're investigating.
SAFE-BioPharma has implemented a thoughtful two factor authentication solution that leverages mobile devices and is provisionally certified as a trust framework provider for NIST level of assurance 2 and 3 by the General Service's Administration FICAM program. Their solution is cross certified with the Federal Bridge Certificate authority. Thus, their credentials are trusted in both the Public Key Infrastructure (PKI) and non-PKI sectors for authentication to any Federal application or infrastructure.
Here's how credentials are issued per Richard Furr, Head of Global Regulatory Affairs, Policy and Compliance, SAFE-BioPharma Association:
The applicant is nominated for a credential by a sponsoring SAFE-BioPharma member. It is important to note here that SAFE-BioPharma is a member driven non-profit association and only members of the association can nominate applicants for credentials. Applicants must be employees or business partners of that member. Membership in SAFE-BioPharma is limited to entities that operate in the biopharmaceutical or healthcare delivery sectors.
The nomination is made on-line by a specially trained member of the member staff who enters specific data, I.e, at least name and business e-mail address, into the registration authority system (UIS) that Verizon Business operates as a contracted infrastructure provider for SAFE-BioPharma.
The UIS generates an email to the applicant address which contains a link to the UIS and a one time password to allow the applicant to access the UIS.
The applicant completes a user profile including other information, e.g., address, telephone, last 4 digits of their social security number, date of birth, medical license number if they have one, that the UIS uses to build out their identity.
Based on the data entered by the applicant the UIS develops their identity and through a contracted data source (LexisNexis) the applicant is presented with five multiple questions to which only they should know the correct answers. The applicant has 2 minutes to answer 4 of the 5 questions correctly. If they fail the first time they are presented another 5 questions. If they answer 4 correctly their identity is confirmed and they can complete the registration process. If they fail a second time they are rolled over to a manual notary process.
Once the identity is confirmed, the applicant creates an account with the UIS Identity Broker by creating a strong user name and password according to the parameters of the system. Then, the applicant registers one or more devices that are capable of receiving a cryptographically generated one-time password, e.g., smartphone (Android or iPhone), SMS capable cell phone, iPad, other mobile tablet, landline phone capable of receiving interactive voice response, other token (RSA, OAuth, etc,) or other types of devices that can receive the One Time Password (OTP) .
Upon completion of these steps the system also generates an X.509 certificate that is downloaded to a cloud-based FIPS 140-2, level 3 certified hardware security module. This certificate is the applicant's digital signing certificate. It can be accessed using the 2-factor non-PKI credential that was just generated. Upon completion of these steps the applicant digitally signs their Subscriber agreement and is ready to go. The entire process takes about 10 minutes. It is also important to note that the last 4 of the social security number and date of birth are deleted after the initial registration process so they are never kept in the system.
Here's how actual authentication works:
1. The use accesses an application or portal via the internet.
2. The accessed application or portal displays a login dialog that asks for the user name and password.
3. The user enters their user name and password and selects the pre-registered device to which they wish their OTP to be sent. This is the first factor of the 2-factor authentication – something the user knows. The app or portal also generates a SAML2 request to the identity broker.
4. The identity broker verifies that the Account is valid and uses a cryptographic algorithm to generate the OTP and send it to the selected device.
5. The app/portal displays a dialog for the user to enter their OTP. The user has 5 minutes to enter the OTP. When they do, the identity broker verifies the OTP as being the one that was generated and this completes the second factor – something the user has – in this case the pre-registered device that received the OTP. Based on this successful completion, the identity broker generates a SAML2 response to the app/portal verifying the identity.
If the user needs to digitally sign a document, such as an e-prescription, they can do so using this same process to authenticate to their X.509 certificate in the cloud. It appears that the DEA will accept this process as part of the final rule for e-prescribing controlled substances.
Since the credentials are FICAM certified, it seems reasonable that such an approach meets all compliance criteria that require strong authentication for securing protected healthcare information.
Subscribe to:
Post Comments (Atom)
2 comments:
Two factor is more secure but not a panacea. Isn't the process you describe vulnerable to a common type of attack on 2F systems? The two factors appear to be entered into and transmitted from one machine. If the machine used to access the app/portal is compromised the attacker just piggybacks onto the user's online session. They don't need to steal your credentials to access the app/portal; they just need to compromise a machine. This type of authentication hasn't prevented malware like Zeus stealing hundreds of millions of dollars from bank accounts every year.
Also see Bruce Schneier's "The Failure of Two-Factor Authentication" from March 2005:
http://www.schneier.com/blog/archives/2005/03/the_failure_of.html
In 2006 he writes "The solution is not to better authenticate the person, but to authenticate the transaction":
http://www.schneier.com/blog/archives/2006/11/fighting_fraudu.html
Post a Comment