Abstract: Securely storing data includes encrypting the data using a random key to provide obfuscated data, scrambling the obfuscated data to provide scrambled obfuscated data, generating a scramble schema indicating how to unscramble the scrambled obfuscated data, encrypting the scrambled obfuscated data to provide encrypted scrambled obfuscated data, splitting the scramble schema, and distributing separate portions of the scramble schema and separate portions of the encrypted scrambled obfuscated data to separate entities. The data may be private key data. Securely storing data may also include concatenating the random key on to the obfuscated data prior to scrambling the obfuscated data, wherein the random key is scrambled together with the obfuscated data. Scrambling the obfuscated data may use a Fisher Yates Shuffle mechanism. Securely storing data may also include generating and distributing a symmetric authentication key that is used to authenticate a first entity to a second entity.

Abstract: Securely storing data includes encrypting the data using a random key to provide obfuscated data, scrambling the obfuscated data to provide scrambled obfuscated data, generating a scramble schema indicating how to unscramble the scrambled obfuscated data, encrypting the scrambled obfuscated data to provide encrypted scrambled obfuscated data, splitting the scramble schema, and distributing separate portions of the scramble schema and separate portions of the encrypted scrambled obfuscated data to separate entities. The data may be private key data. Securely storing data may also include concatenating the random key on to the obfuscated data prior to scrambling the obfuscated data, wherein the random key is scrambled together with the obfuscated data. Scrambling the obfuscated data may use a Fisher Yates Shuffle mechanism. Securely storing data may also include generating and distributing a symmetric authentication key that is used to authenticate a first entity to a second entity.

Abstract: Customizing an application on a mobile device includes storing at least a portion of customization data in a customization server that is independent of the mobile device, a user of the mobile device accessing the customization server independently of the mobile device, receiving authorization data from the customization server that enables the mobile device to securely receive customization data from the customization server, and the mobile device using the authorization data to cause the customization server to provide the customization data to the mobile device. The authorization data may be provided by postal message, email message, an SMS text message, and/or a visual code provided on a screen of a computer used to access the customization server. The user may use a computer to provide credential information to access the customization server. Customizing the application may allow the mobile device to access a user service on behalf of the user.

Abstract: Customizing an application on a mobile device includes storing at least a portion of customization data in a customization server that is independent of the mobile device, a user of the mobile device accessing the customization server independently of the mobile device, receiving authorization data from the customization server that enables the mobile device to securely receive customization data from the customization server, and the mobile device using the authorization data to cause the customization server to provide the customization data to the mobile device. The authorization data may be provided by postal message, email message, an SMS text message, and/or a visual code provided on a screen of a computer used to access the customization server. The user may use a computer to provide credential information to access the customization server. Customizing the application may allow the mobile device to access a user service on behalf of the user.

Abstract: Confirming user consent includes prompting the user to tap a card a card reader or a computing device and confirming consent in response to the user taping the card. The user may be prompted for a response in a plurality of possible responses and only a particular one of the possible responses may require taping the card. The user may consent to installation of software on the computing device. The user may be logged in to the computing device. A login ID for the user may be cached and/or may be accessed in connection with the user tapping the card. Confirming user consent may also include obtaining a pairing code for accessing the card and confirming consent in response to the user taping the card and the pairing code allowing access to the card. The pairing code may be cached in the card reader or the computing device.

Abstract: A method of device authentication comprises receiving a password into an application of a user device; transmitting verification information of the password from the application to an authentication device; verifying, by the authentication device, validity of the password using the verification information; granting, by the authentication device, access by the user device to a secure resource when the password is valid; sending no indication of an invalid password to the user device when the authentication device determines the password is invalid; and blocking access of the user device to the secure resource when a predetermined number of passwords are determined to be invalid by the authentication device.

Abstract: Methods, devices, and systems are provided for approving a transaction through an exchange of presented user contextual approval information and approval decryption. The user contextual approval information is generated by a user during a transaction, cryptographically signed, and provided to a transaction server. The user contextual data uniquely describes the transaction to the user and can be employed to aid a user in approving or validating the transaction in a subsequent approval action. In particular, a transaction may present the contextual approval information to a user in the form of an approval challenge message. The approval challenge message may be sent to a known user device via the transaction server in the form of a text or multi-media message. The user may respond to the message with an approval or denial response.

Abstract: Securely storing data includes encrypting the data using a random key to provide obfuscated data, scrambling the obfuscated data to provide scrambled obfuscated data, generating a scramble schema indicating how to unscramble the scrambled obfuscated data, encrypting the scrambled obfuscated data to provide encrypted scrambled obfuscated data, splitting the scramble schema, and distributing separate portions of the scramble schema and separate portions of the encrypted scrambled obfuscated data to separate entities. The data may be private key data. Securely storing data may also include concatenating the random key on to the obfuscated data prior to scrambling the obfuscated data, wherein the random key is scrambled together with the obfuscated data. Scrambling the obfuscated data may use a Fisher Yates Shuffle mechanism. Securely storing data may also include generating and distributing a symmetric authentication key that is used to authenticate a first entity to a second entity.

Abstract: A GUI to configure user access to a secure device. For signals received by a secure device from a user device, the GUI enables a user to intuitively configure a range of signal strength of such signals required to allow user devices access to the secure device or an application residing thereon. The GUI may present a distance range icon that visually presents a range of signal strength as a distance, each point along the length corresponding to a signal strength value. The GUI may include a control for controlling the distance range icon, and may present a user device icon for a user device currently within the signal reception range of the secure device. The user device icon may be presented in spatial relation to the distance range icon, thereby visually informing a user of the relative distance of the user device from the secure device.

Abstract: Securely storing data includes encrypting the data using a random key to provide obfuscated data, scrambling the obfuscated data to provide scrambled obfuscated data, generating a scramble schema indicating how to unscramble the scrambled obfuscated data, encrypting the scrambled obfuscated data to provide encrypted scrambled obfuscated data, splitting the scramble schema, and distributing separate portions of the scramble schema and separate portions of the encrypted scrambled obfuscated data to separate entities. The data may be private key data. Securely storing data may also include concatenating the random key on to the obfuscated data prior to scrambling the obfuscated data, wherein the random key is scrambled together with the obfuscated data. Scrambling the obfuscated data may use a Fisher Yates Shuffle mechanism. Securely storing data may also include generating and distributing a symmetric authentication key that is used to authenticate a first entity to a second entity.

Abstract: Methods, devices, and systems are provided for approving a transaction through an exchange of presented user contextual approval information and approval decryption. The user contextual approval information is generated by a user during a transaction, cryptographically signed, and provided to a transaction server. The user contextual data uniquely describes the transaction to the user and can be employed to aid a user in approving or validating the transaction in a subsequent approval action. In particular, a transaction may present the contextual approval information to a user in the form of an approval challenge message. The approval challenge message may be sent to a known user device via the transaction server in the form of a text or multi-media message. The user may respond to the message with an approval or denial response.

Abstract: Methods, devices, and systems are provided for approving a transaction through an exchange of presented user contextual approval information and approval decryption. The user contextual approval information is generated by a user during a transaction, cryptographically signed, and provided to a transaction server. The user contextual data uniquely describes the transaction to the user and can be employed to aid a user in approving or validating the transaction in a subsequent approval action. In particular, a transaction may present the contextual approval information to a user in the form of an approval challenge message. The approval challenge message may be sent to a known user device via the transaction server in the form of a text or multi-media message. The user may respond to the message with an approval or denial response.

Abstract: Customizing an application on a mobile device includes storing at least a portion of customization data in a customization server that is independent of the mobile device, a user of the mobile device accessing the customization server independently of the mobile device, receiving authorization data from the customization server that enables the mobile device to securely receive customization data from the customization server, and the mobile device using the authorization data to cause the customization server to provide the customization data to the mobile device. The authorization data may be provided by postal message, email message, an SMS text message, and/or a visual code provided on a screen of a computer used to access the customization server. The user may use a computer to provide credential information to access the customization server. Customizing the application may allow the mobile device to access a user service on behalf of the user.

Abstract: Methods, devices, and systems are provided for approving a transaction through an exchange of presented user contextual approval information and approval decryption. The user contextual approval information is generated by a user during a transaction, cryptographically signed, and provided to a transaction server. The user contextual data uniquely describes the transaction to the user and can be employed to aid a user in approving or validating the transaction in a subsequent approval action. In particular, a transaction may present the contextual approval information to a user in the form of an approval challenge message. The approval challenge message may be sent to a known user device via the transaction server in the form of a text or multi-media message. The user may respond to the message with an approval or denial response.

Abstract: A system and method are provided to access a secure host device using a personal security device (PSD). A user's PSD may hold a credential of a requesting component of the secure host device. The credential may only be readable from the PSD when a secure channel is established therewith. The establishment of a secure channel with the PSD may require access to keys. The secure host device may contain a SAM capable of securely storing and operating keys. The SMA may contain the relevant keys to support establishment of a secure channel with the personal security device and release a credential to its requesting component. These criteria may achieve the secure release of the credential from the PSD to the requesting component of the secure host device to achieve access by the user when the PSD is presented in the non-contract field of a card reader monitored by the secure host device.

Abstract: Confirming user consent includes prompting the user to tap a card a card reader or a computing device and confirming consent in response to the user taping the card. The user may be prompted for a response in a plurality of possible responses and only a particular one of the possible responses may require taping the card. The user may consent to installation of software on the computing device. The user may be logged in to the computing device. A login ID for the user may be cached and/or may be accessed in connection with the user tapping the card. Confirming user consent may also include obtaining a pairing code for accessing the card and confirming consent in response to the user taping the card and the pairing code allowing access to the card. The pairing code may be cached in the card reader or the computing device.

Abstract: Providing access to a protected resource includes obtaining a first authentication factor for a user that is accessing the resource using a computing device, prompting the user to provide a second authentication factor, accessing the second authentication factor using a pairing code, determining if the second authentication factor is bound to the computing device, and allowing the user to access the protected resource in response to the first and second authentication factors being valid and the second authentication factor being bound to the computing device. The user may be prompted to tap a card to provide the second authentication factor. The first authentication factor may be a login id and password combination. The login id and password may be cached in the computing device. The second authentication factor may be a security card. Information on the security card may be encrypted and may be accessible using a pairing code.