SYSTEMS AND METHODS FOR ENHANCED MOBILE DEVICE AUTHENTICATION

Systems and methods for enhanced mobile device authentication are disclosed. Systems and methods for enhanced mobile authentication are disclosed. In one embodiment, method for electronic device authentication may include (1) a server comprising at least one computer processor communicating a one-time passcode to an electronic device over a first communication channel; (2) the server receiving, from the electronic device over a second communication channel the one-time passcode encrypted with a private key associated with the electronic device; (3) the server decrypting the one-time passcode using a public key; (4) the server validating the one-time passcode; (5) the server generating a device identifier for the electronic device; and (6) the server persisting an association between the device identifier and the electronic device.

BACKGROUND OF THE INVENTION

Banks seek to authenticate customers more effectively and with the best customer possible experience. The mobile device offers huge potential in that it is personal, near ubiquitous, usually with the owner, and increasingly used for banking activity.

SUMMARY OF THE INVENTION

Systems and methods for enhanced mobile authentication are disclosed. In one embodiment, method for electronic device authentication may include (1) a server comprising at least one computer processor communicating a one-time passcode to an electronic device over a first communication channel; (2) the server receiving, from the electronic device over a second communication channel the one-time passcode encrypted with a private key associated with the electronic device; (3) the server decrypting the one-time passcode using a public key; (4) the server validating the one-time passcode; (5) the server generating a device identifier for the electronic device; and (6) the server persisting an association between the device identifier and the electronic device.

In one embodiment, the method may further include the server receiving, from the electronic device over the second communication channel, a password; and the server persisting the password.

In one embodiment, the device identifier may include a universally unique identifier.

In one embodiment, the method may further include the server receiving from the electronic device over the second communication channel, a public key paired with the private key.

In one embodiment, the method may further include the server receiving, from the electronic device over the second communication channel, an application specific verification key; and the server decrypting the application specific verification key. The step of persisting the association between the device identifier and the electronic device further comprises storing an indication that the application specific verification key was valid.

In one embodiment, the application specific verification key may be calculated according to the following equation:

In one embodiment, the method may further include the server receiving, from the electronic device over the second communication channel, device fingerprint data for the electronic device.

In one embodiment, the method may further include the server communicating, over the second communication channel, the device identifier to the electronic device.

According to another embodiment, a method for electronic device authentication may include (1) an application executed by an electronic device comprising at least one computer processor receiving, over a first communication channel, a one-time passcode from a server; (2) the application encrypting the one-time passcode with a private key; (3) the application communicating, over a second communication channel, the one-time passcode encrypted with the private key to the server; (4) the application receiving, from the server, a device identifier for the electronic device; and (5) the application persisting the device identifier.

In one embodiment, the method may further include the application generating an application specific verification key; and the application communicating, over the second communication channel, the application specific verification key to the server; wherein the application specific verification key may be calculated according to the following equation:

In one embodiment, the device identifier may include a universally unique identifier.

In one embodiment, the method may further include the application generating a public key and private key pair; and the application persisting the private key in one of a secure element of the electronic device or in a secure storage element of one of the application and an operating system executed by the electronic device.

In one embodiment, the method may further include the application communicating, over the second communication channel, device fingerprint data for the electronic device to the server.

A system for electronic device authentication may include an electronic device comprising at least one electronic device computer processor, a memory, and an interface; an authentication server comprising at least one server computer processor; a first communication channel between the electronic device and the server; and a second communication channel between the electronic device and the server. The authentication server may generate a one-time passcode and communicates the one-time passcode to the over the first communication channel. The application may encrypt the one-time passcode with a private key and communicates, over the second communication channel, the one-time passcode encrypted with the private key to the authentication server. The authentication server may decrypt the one-time passcode using a public key, and may validate the one-time passcode. It may also generate a device identifier for the electronic device and persist an association between the device identifier and the electronic device. It may then communicate, over the second communication channel, the device identifier for the electronic device to the application. The application may then persist the device identifier.

In one embodiment, the application may generate an application specific verification key, and communicates the application specific verification key to the authentication server over the second communication channel; wherein the application specific verification key may be calculated according to the following equation:

In one embodiment, the authentication server may decrypt the application specific verification key and stores an indication that the application specific verification key was valid.

In one embodiment, the authentication server may receive, from the electronic device over the second communication channel, a password, and may persist the password.

In one embodiment, the device identifier may be a universally unique identifier.

In one embodiment, the authentication server may receive, from the application, an identification of the first communication channel for receiving the one-time passcode.

In one embodiment, the authentication server may receive from the electronic device over the second communication channel, device fingerprint data for the electronic device.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Several embodiments of the present invention and their advantages may be understood by referring to FIGS. 1-5.

Embodiments of the present disclosure relate to enhancing the security of electronic devices, and, in particular, mobile electronic devices. Embodiments disclosed herein may provide for three levels of “trust”: (1) trust that the device is secure; (2) trust that the communication channel between the device and an application executed by the device is secure; and (3) trust that the user operating the device is the individual that is associated with the device. To achieve these levels of trust, (1) the inherent security of the device may be tested, (2) the ownership of the device may be established through enrollment controls, (3) cryptographic keys and/or tokens that are a unique function of the application, the device, and the user identity may be deployed. The unique binding among the application, the device, and the user identity may be exploited to strengthen and simplify the authentication from the device. Moreover, a token encrypted with a unique cryptographic key may be used to pass to other channels and may act as a strong identifier.

In one embodiment, the token may be encrypted using a cryptographic key to act as a proxy for the customer's identity. For example, the encrypted token may support a number of different customer experiences or use cases, such as being able to use the mobile device to authenticate the customer to, for example, an ATM.

As another example, a token may be provided to the customer when the customer uses an application on the mobile device to authenticate a customer to a customer service representative. In one embodiment, customer data (e.g., account information, potential reasons for contacting the customer service representative, etc.) may be associated with the token and may be provided to the customer service representative.

The disclosure of U.S. patent application Ser. No. 13/644,326 is hereby incorporated by reference in its entirety.

In addition, a one-time Application Source Validation Key, or ASVK, may be used to verify that the application, program, or other software, is from a trusted source. For example, because mobile applications may leverage standard HTTPs internet connectivity to communicate secure requests to the server, even with mutual authentication, it cannot be definitively determined whether the application or software is authentic or otherwise sanctioned. Thus, it may be difficult to distinguish the application or software from impostor apps or scripts running on a server.

In one embodiment, a cryptographic key and/or a token may be deployed to an electronic device (e.g., a mobile electronic device, an Internet of Things appliance, a desktop computer, a workstation, etc.) during a registration process for the application, program, or software. In one embodiment, signed, sanctioned applications or software may be distributed with a protected cryptographic functionality to support application source verification. The cryptographic function, which may be protected by application-level white box cryptography, may be called to encrypt a one-time passcode (OTP,) known environmental parameters and generate a one-time challenge/response. For example, in one embodiment, an ASVK encrypted cipher may be calculated as follows:

Other calculations for determining ASVK may be used as is necessary and/or desired.

In one embodiment, the static data may include an algorithm that may be shared by both the server and the electronic device. In one embodiment, only a sanctioned application, program, or software, properly provisioned with the protected cryptographic functionality, may create a valid ASVK. The ASVK may be used to verify that the source of mobile web service APIs is genuinely a sanctioned native application.

In another embodiment, a mobile electronic device may be used to continuously authenticate the user. At the manufacturer's device level, a variety of user data can be collected to create an association between the electronic device and its regular authorized user. As reliance on electronic devices to identify users grows, a set of controls may be used mitigate fraudulent usage.

In one embodiment, servers and virtual machines deployed within the enterprise, private and public cloud infrastructure may be used for continuous authentication.

In one embodiment, devices may leverage sensors, monitors, etc. to establish probabilistic behavior patterns. This may include, for example, biometric data, user movement data, user geolocation data, etc. In combination with machine learning, these patterns may be associated with the notion of a “regular,” or registered, authorized device user.

Applications that may be deployed to the devices may associate an application level identity token with the device's “regular” authorized user. Subsequent application authentication requests will leverage this relationship to assert the application identity is the device's “regular” authorized user.

In one embodiment, the exchange of Personally Identifiable Information (“PII”) may not be required. Instead, an anonymous token that correlates back to the identity may be shared between the electronic device and the authentication server.

In one embodiment, if an irregular behavior, or pattern of behaviors, are sensed, the authentication may be terminated.

Referring to Figure, 1, a system for enhanced mobile device authentication according to one embodiment is disclosed. System 100 may include user 110, electronic device 120, remote server/device 150, and authentication server 160. In one embodiment, electronic device 120 may be any suitable electronic device, including workstations, desktop computers, notebook computers, tablet computers, smart phones, Internet of Things (IoT) appliances, etc. In one embodiment, electronic device 120 may provide a secure storage area, such as in a secure element.

Electronic device 120 may execute application 140, which may be any application, computer program, or software. In one embodiment, application 130 may authenticate a user.

In one embodiment, application 140 may provide user 110 with access to sensitive, confidential, or otherwise restricted information and/or resources. In another embodiment, application 140 may provide user 110 with the ability to conduct transactions with sensitive, confidential, or otherwise restricted information and/or resources.

In one embodiment, application 140 may be provided by a financial services provider, such as a financial institution, a payment processor, an investment manager, etc.

In one embodiment, application 140 may be a mobile wallet.

In one embodiment, application 140 and/or the operating system executed by electronic device 120 may include secure storage.

In one embodiment, electronic device 120 may be provided with cryptographic key 125 and token 130. Cryptographic key 125 and/or token 130 may serve to “bind” user 110, application 130, and device 120 to each other. In one embodiment, token 130 that may be encrypted with cryptographic key 125 may be used to authenticate user 110, device 120 and/or application 140 to remote server or device 140.

Any suitable type, format, size, etc. of cryptographic key may be used as is necessary and/or desired.

In one embodiment, cryptographic key 125 may comprise an ASVK.

In one embodiment, remote server/device 150 may be an ATM.

Authentication server 160 may authenticate user 110 and/or electronic device 120. In one embodiment, authentication server 160 may be separate from remote server/device 150. In another embodiment, the functionality of authentication sever 160 may be partially or wholly incorporated into remote server/device 150.

Referring to FIG. 2, a method for strong registration is disclosed according to one embodiment.

In step 205, a one-time passcode, or password, may be received by, for example, an application executed by an electronic device. In one embodiment, the one-time passcode may be provided by the server, and may be considered to be a “challenge” in a challenge/response authentication protocol.

In one embodiment, the one-time passcode may be received on an out-of-band network (e.g., SMS, email, etc.).

In step 210, a crypto key exchange may be performed. In one embodiment, the application may generate public and private keys, and may exchange public keys with the authentication server.

In one embodiment, the private key may be persisted in the secure element of the electronic device or in a secure storage element of the application or operating system. In one embodiment, the manner of storage may depend on whether the user may be authenticated to the electronic device using, for example, biometrics. For example, if the electronic device can receive biometrics, and the user is authenticated, the private key may be stored in the electronic device's secure element. If the electronic device is not biometric-enabled, the private key may be stored in the secure storage element of the application or operating system.

In step 215, the one-time passcode may be digitally signed or encrypted using, for example, the private key. The encrypted one-time passcode may be considered to be a “response” in the challenge/response authentication protocol.

In step 220, the encrypted one-time passcode may be communicated to the authentication server. In one embodiment, additional data, such as device fingerprint data, malware data, username, and password, etc. may also be communicated as is necessary and/or desired.

In one embodiment, device fingerprint data may include, for example, operating system data (e.g., operating system version number, etc.), browser data (e.g., browser, version, etc.), locale data (e.g., country, language, etc.), hardware/system data (e.g., operating system, screen resolution, screen aspect ratio, manufacturer, serial number, SIM card, jailbreak information, etc.), settings data, cookie data, mobile application data, etc. It may further collect data from a mobile wallet application, such as user id and password. Other device data may be used as is necessary and/or desired.

In step 225, an authentication server may decrypt the one-time passcode, and, in step 230, the authentication server may determine whether or not the one-time passcode is valid. If it is not, the process may be stopped in step 235. In one embodiment, error messages, warnings, etc. may be provided as is necessary and/or desired.

In step 240, a device identifier may be generated by the authentication server. In one embodiment, the device identifier may be a variant of universally unique identifier (UUID) that may be created based on, for example, the RFC 4122 UUID namespace specification. In one embodiment, the device identifier may be persisted at the authentication server.

In step 245, the device identifier and the electronic device may be may be persisted at, for example, the authentication server. Other information may be persisted as is necessary and/or desired.

In one embodiment, the device identifier may be communicated to the electronic device and persisted at the electronic device.

In step 250, the user may enter a password, and the password may be received and persisted at the authentication server. The user may also provide contact information which may also be persisted in storage at the authentication authority.

Referring to FIG. 3, an enrollment process is disclosed according to one embodiment.

In step 305, a user may download a software application or program onto his or her electronic device. In one embodiment, the software application may be downloaded from an app store or similar location.

In step 310, the application may perform an integrity check on the electronic device. In one embodiment, the application may check to see if there is malware on the electronic device, if the electronic device has been “rooted,” whether the application is an authorized application, etc. In one embodiment, this may include updating malware detection software.

In one embodiment, any checks that may verify the integrity of the electronic device and/or the operating system executed thereby may be performed as is necessary and/or desired.

In step 315, device profiling data may be collected. In one embodiment, this data may be used to determine whether the electronic device has previously been involved with, or associated with, fraud. In one embodiment, the application may provide electronic device data (e.g., serial number, MAC address, etc.) to an authenticating entity, which may compare the electronic device data to that in a blacklist, a white list, etc.

In step 320, the user may be prompted for user information, such as a user name, account number, date of birth, etc., and may enter such information.

In step 325, the entered data and device profiling data may be provided to the authenticating entity, which may perform a device profiling check for fraud.

In step 330, the authenticating entity may identify the user in its database(s). If the user is not found, a message may be displayed in step 335. In one embodiment, the process may be stopped.

If the user is found, in step 340, an optional carrier check may be performed. For example, if the electronic device is operating on a carrier network, a carrier check may be performed in conjunction with a third party mobile network operator (i.e., a carrier) to corroborate that the user data on record both within, for example, a financial institution as well as the carrier, matches. An unsuccessful carrier check may indicate fraud, and in step 345, a message indicating such may be displayed. In one embodiment, the process may be stopped.

If the carrier check is verified, in step 350, a user may be created, and, in step 355, the user may select one or more one-time passcode contacts (e.g., email, SMS, etc.).

Referring to FIG. 4, a method for strong registration is disclosed according to one embodiment. In one embodiment, cryptographic key exchange using crypto-authentication protocols may be used among the electronic device, the application executed by the device, and the authentication server.

In step 405, an electronic device may receive a one-time passcode. In one embodiment, the one-time passcode may be received, for example, via an out-of-band communication channel (e.g., SMS, email, etc.). In one embodiment, the out-of-band communication channel may be the one that the user selected during registration.

In step 410, a crypto key exchange may be performed. This may be similar to step 210, above.

In step 415, the one-time passcode may be encrypted using, for example, the private key. This may be similar to step 215, above.

In step 420, the application specific verification key may be derived. In one embodiment, the AVSK may be derived using the algorithm, above. Other suitable algorithms may be used as is necessary and/or desired.

In step 425, the ASVK and the encrypted one-time passcode may be communicated to the authentication server. In one embodiment, additional data, such as device fingerprint data, malware data, username, and password, etc. may also be communicated as is necessary and/or desired. In one embodiment, some or all of the additional data may be encrypted.

In step 430, the authentication server may decrypt the one-time passcode and, in step 435, may determine if the one-time passcode is valid. If it is not, in step 440, the process may end.

If the one-time passcode is valid, in step 445, the AVSK may be decrypted, and in step 450, a device identifier may be generated. This may be similar to step 240, above.

In step 455, the device identifier may be persisted in storage, for example, at the authentication authority. In addition, a Boolean value (e.g., true or false) indicating whether the application source verification process succeeded or failed may also be persisted at the authentication server. Other information may be persisted as is necessary and/or desired.

In one embodiment, the device identifier may be communicated to the electronic device and persisted at the electronic device.

In step 460, the user may then create a password, and may provide contact information. This may be similar to step 250, above.

Referring to FIG. 5, a method for strong authentication is disclosed according to another embodiment.

In step 505, a user may select a login method, such as userid/password, biometric, etc. If, in step 510, the user does not select a biometric login, the application may receive the user's credentials. If the user selects biometric login, in step 520, the application may receive biometrics from the user.

In step 525, the deviceID may be retrieved from, for example, the device's secure element and, in step 530, the deviceID may be encrypted with, for example, a private key from the device's secure element, or from a secure storage element of the application or operating system.

In one embodiment, as part of this process, a one-time passcode may be received, and an ASVK may be generated and communicated to the authentication server.

In step 535, the electronic device's profile may be verified. If it cannot be verified, in step 555, the process may stop. In one embodiment, this may include checking to see if the electronic device is a familiar electronic device (e.g., a returning electronic device) based on fingerprint data, cookies, etc. In one embodiment a check may be made to determine if the electronic device acting suspiciously (e.g., associated with many accounts, resetting passwords on multiple accounts), known to have been associate with fraud, etc.

In step 540, the user's credentials (e.g., username/password, authentication token, biometrics, etc.) may be checked for validity. If the user's credentials cannot be verified, in step 545, the process may stop.

In step 545, the authentication server may decrypt the deviceID, and, in step 550, access may be granted and logged.

The processing machine used to implement the invention may utilize a suitable operating system. Thus, embodiments of the invention may include a processing machine running the iOS operating system, the OS X operating system, the Android operating system, the Microsoft Windows™ operating systems, the Unix operating system, the Linux operating system, the Xenix operating system, the IBM AIX™ operating system, the Hewlett-Packard UX™ operating system, the Novell Netware™ operating system, the Sun Microsystems Solaris™ operating system, the OS/2™ operating system, the BeOS™ operating system, the Macintosh operating system, the Apache operating system, an OpenStep™ operating system or another operating system or platform.

PROM, an EPROM, a wire, a cable, a fiber, a communications channel, a satellite transmission, a memory card, a SIM card, or other remote transmission, as well as any other medium or source of data that may be read by the processors of the invention.