A method comprises establishing a network connection between the first processing device and the second processing device for transfer of data associated with a software authenticator from the first processing device to the second processing device, encrypting the software authenticator data with encryption that is separate from encryption used for the network connection, and transferring the encrypted software authenticator data from the first processing device to the second processing device. Another method comprises establishing the network connection between the first processing device and the second processing device for transfer of the software authenticator data, receiving encrypted data from the first processing device, wherein the encrypted data has encryption that is separate from encryption used for the network connection, decrypting the encrypted data to obtain data associated with a software authenticator and importing the software authenticator data into a software authenticator stored in a memory of the second processing device.
|
1. A method comprising:
establishing a network connection between a first processing device and a second processing device for transfer of software authenticator data from the first processing device to the second processing device, the software authenticator data comprising a seed value utilized by a first software authenticator provisioned on the first processing device to generate one or more passcodes;
encrypting the software authenticator data;
transferring the encrypted software authenticator data from the first processing device to the second processing device, the software authenticator data being configured to provision a second software authenticator on the second processing device;
initiating re-seeding of the second software authenticator responsive to a successful provisioning of the second software authenticator on the second processing device;
receiving, at the first processing device from the second processing device, a confirmation indicating a successful transfer of the software authenticator data; and
removing the first software authenticator from the first processing device responsive to receipt of the confirmation;
wherein initiating re-seeding of the second software authenticator comprises registering the second processing device with a software authenticator management server;
wherein registering the second processing device causes the software authenticator management server to generate a code which is sent to the second processing device; and
wherein the code is configured to enable re-seeding of the second software authenticator.
9. A non-transitory processor-readable storage medium having instruction code embodied therein which when executed by a first processing device causes the first processing device:
to establish a network connection with a second processing device for transfer of software authenticator data from the first processing device to the second processing device, the software authenticator data comprising a seed value utilized by a first software authenticator provisioned on the first processing device to generate one or more passcodes;
to encrypt the software authenticator data;
to transfer the encrypted software authenticator data to the second processing device, the software authenticator data being configured to provision a second software authenticator on the second processing device;
to initiate re-seeding of the second software authenticator responsive to a successful provisioning of the second software authenticator on the second processing device;
to receive, from the second processing device, a confirmation indicating a successful transfer of the software authenticator data; and
to remove the first software authenticator from the first processing device responsive to receipt of the confirmation;
wherein initiating re-seeding of the second software authenticator comprises registering the second processing device with a software authenticator management server;
wherein registering the second processing device causes the software authenticator management server to generate a code which is sent to the second processing device; and
wherein the code is configured to enable re-seeding of the second software authenticator.
14. A method comprising:
establishing a network connection between a first processing device and a second processing device for transfer of software authenticator data from the first processing device to the second processing device, the software authenticator data comprising a seed value utilized by a first software authenticator provisioned on the first processing device to generate one or more passcodes;
receiving encrypted data from the first processing device;
decrypting the encrypted data to obtain the software authenticator data;
importing the software authenticator data into a second software authenticator stored in a memory of the second processing device;
provisioning the second software authenticator on the second processing device utilizing the software authenticator data;
re-seeding the second software authenticator responsive to a successful provisioning of the second software authenticator on the second processing device; and
sending a confirmation from the second processing device to the first processing device indicating a successful transfer of the software authenticator data;
wherein receipt of the confirmation causes removal of the first software authenticator from the first processing device;
wherein re-seeding of the second software authenticator is initiated responsive to registering the second processing device with a software authenticator management server;
wherein registering the second processing device causes the software authenticator management server to generate a code which is sent to the second processing device; and
wherein the code is configured to enable re-seeding of the second software authenticator.
20. A non-transitory processor-readable storage medium having instruction code embodied therein which when executed by a second processing device causes the second processing device:
to establish a network connection with a first processing device for transfer of software authenticator data from the first processing device to the second processing device, the software authenticator data comprising a seed value utilized by a first software authenticator provisioned on the first processing device to generate one or more passcodes;
to receive encrypted data from the first processing device;
to decrypt the encrypted data to obtain the software authenticator data;
to import the software authenticator data into a second software authenticator stored in a memory of the second processing device;
to provision the second software authenticator on the second processing device utilizing the software authenticator data;
to re-seed the second software authenticator responsive to a successful provisioning of the second software authenticator on the second processing device; and
to send a confirmation from the second processing device to the first processing device indicating a successful transfer of the software authenticator data;
wherein receipt of the confirmation causes removal of the first software authenticator from the first processing device;
wherein re-seeding of the second software authenticator is initiated responsive to registering the second processing device with a software authenticator management server;
wherein registering the second processing device causes the software authenticator management server to generate a code which is sent to the second processing device; and
wherein the code is configured to enable re-seeding of the second software authenticator.
10. An apparatus comprising:
a first processing device comprising:
network interface circuitry;
a memory configured to store data associated with a first software authenticator provisioned on the first processing device; and
a processor coupled to the memory;
the first processing device under control of the processor being configured to:
establish a network connection via the network interface circuitry between the first processing device and a second processing device for transfer of software authenticator data from the first processing device to the second processing device, the software authenticator data comprising a seed value utilized by the first software authenticator provisioned on the first processing device to generate one or more passcodes;
encrypt the software authenticator data;
transfer the encrypted software authenticator data to the second processing device, the software authenticator data being configured to provision a second software authenticator on the second processing device;
initiate re-seeding of the second software authenticator responsive to a successful provisioning of the second software authenticator on the second processing device;
receive, from the second processing device, a confirmation indicating a successful transfer of the software authenticator data; and
remove the first software authenticator from the first processing device responsive to receipt of the confirmation;
wherein initiating re-seeding of the second software authenticator comprises registering the second processing device with a software authenticator management server;
wherein registering the second processing device causes the software authenticator management server to generate a code which is sent to the second processing device; and
wherein the code is configured to enable re-seeding of the second software authenticator.
21. An apparatus comprising:
a first processing device comprising:
network interface circuitry;
a memory configured to store data associated with a first software authenticator; and
a processor coupled to the memory;
the first processing device under control of the processor being configured to:
establish a network connection via the network interface circuitry between the first processing device and a second processing device for transfer of data associated with a software authenticator from the second processing device to the first processing device, the software authenticator data comprising a seed value utilized by a second software authenticator provisioned on the second processing device to generate one or more passcodes;
receive encrypted data from the second processing device;
decrypt the encrypted data to obtain the software authenticator data;
import the software authenticator data into the first software authenticator stored in the memory;
provision the first software authenticator on the first processing device utilizing the software authenticator data;
re-seed the second software authenticator responsive to a successful provisioning of the second software authenticator on the second processing device; and
send a confirmation from the second processing device to the first processing device indicating a successful transfer of the software authenticator data;
wherein receipt of the confirmation causes removal of the first software authenticator from the first processing device;
wherein re-seeding of the second software authenticator is initiated responsive to registering the second processing device with a software authenticator management server;
wherein registering the second processing device causes the software authenticator management server to generate a code which is sent to the second processing device; and
wherein the code is configured to enable re-seeding of the second software authenticator.
2. The method of
3. The method of
retrieving the software authenticator data from a memory of the first processing device;
serializing the software authenticator data; and
encrypting the software authenticator data with a key derived from a user-specified password.
4. The method of
5. The method of
6. The method of
7. The method of
8. The method of
11. The apparatus of
12. The apparatus of
13. The apparatus of
15. The method of
deriving a key from a user-specified password;
decrypting the encrypted data using the key; and
de-serializing the decrypted data.
16. The method of
17. The method of
18. The method of
generating a new passcode utilizing the seed value transferred from the first processing device; and
sending the new passcode to an authentication manager, wherein the new passcode triggers a silent alarm function in the authentication manager and wherein the authentication manager associates a new seed value with the second software authenticator responsive to matching the new passcode to a derived seed value stored in the authentication manager.
19. The method of
22. The apparatus of
23. The apparatus of
24. The apparatus of
25. The apparatus of
|
The field relates generally to cryptography, and more particularly to software authenticators implemented in processing devices.
One-time passcode (OTP) authentication tokens may be implemented in hardware and software. Hardware authentication tokens are typically implemented as small, hand-held devices that display a series of passcodes over time. A user equipped with such an authentication token reads the currently displayed passcode and enters it into a computer or other element of an authentication system as part of an authentication operation. This type of dynamic passcode arrangement offers a significant security improvement over authentication based on a static password. Software authentication tokens, or software authenticators, can be implemented in the form of software installed on a processing device such as a computer, mobile phone, tablet, etc.
Conventional authentication tokens include both time-synchronous and event-synchronous tokens.
In a typical time-synchronous token, the displayed passcodes are based on a secret value and the time of day. A verifier with access to the secret value and a time of day clock can verify that a given presented passcode is valid.
One particular example of a time-synchronous authentication token is the RSA SecurID® user authentication token, commercially available from RSA, The Security Division of EMC Corporation, of Bedford, Mass., U.S.A.
Event-synchronous tokens generate passcodes in response to a designated event, such as a user pressing a button on the token. Each time the button is pressed, a new passcode is generated based on a secret value and an event counter. A verifier with access to the secret value and the current event count can verify that a given presented passcode is valid.
Other known types of authentication tokens include hybrid time-synchronous and event-synchronous tokens.
Passcodes can be communicated directly from the authentication token to a computer or other element of an authentication system, instead of being displayed to the user. For example, a wired connection such as a universal serial bus (USB) interface may be used for this purpose. Wireless authentication tokens are also known. In authentication tokens of this type, the passcodes are wirelessly communicated to a computer or other element of an authentication system. These wired or wireless arrangements, also referred to herein as connected tokens, save the user the trouble of reading the passcode from the display and manually entering it into the computer.
Hardware and software authentication tokens and other types of OTP devices are typically programmed with a random seed or other type of key that is also stored in a token record file. The record file is loaded into an authentication server, such that the server can create matching passcodes for the authentication token based on the key and the current time or current event count.
Illustrative embodiments of the present invention provide techniques for secure transfer of software authenticator data between processing devices.
In one embodiment, a method comprises establishing a network connection between the first processing device and the second processing device for transfer of data associated with a software authenticator from the first processing device to the second processing device, encrypting the software authenticator data with encryption that is separate from encryption used for the network connection and transferring the encrypted software authenticator data from the first processing device to the second processing device.
In another embodiment, a method comprises establishing a network connection between a first processing device and a second processing device for transfer of data associated with a software authenticator from the first processing device to the second processing device, receiving encrypted data from the first processing device, wherein the encrypted data has encryption that is separate from encryption used for the network connection, decrypting the encrypted data to obtain data associated with a software authenticator and importing the software authenticator data into a software authenticator stored in a memory of the second processing device.
These and other features and advantages of embodiments of the present invention will become more readily apparent from the accompanying drawings and the following detailed description.
Illustrative embodiments of the present invention will be described herein with reference to exemplary communication systems and associated processing devices, networks, servers, etc. It is to be appreciated, however, that the invention is not restricted to use with the particular illustrative system and device configurations shown. Accordingly, the term “communication system” as used herein is intended to be broadly construed, so as to encompass, for example, systems in which multiple processing devices communicate with one another over a network.
The term “passcode” as used herein is intended to include authentication information such as OTPs, or more generally any other information that may be utilized for cryptographic authentication purposes. Although the illustrative embodiments will be described below primarily in the context of OTPs, it is to be appreciated that the invention is more broadly applicable to any other type of passcode.
As will be described, the present invention in one or more illustrative embodiments provides techniques for facilitating secure transfer of software authenticators between processing devices.
Today, users often replace processing devices such as mobile phones, tablets, laptops, etc. frequently. New devices are released every few months, and some users will upgrade their devices to remain at the cutting edge. In addition, typical subscription plans for mobile phones are 2-year plans, where users are eligible for a free or discounted upgrade at or around the end of the 2-year plan. Thus, even users who do not upgrade devices every few months or every year will typically upgrade devices such as mobile phones every two years. Thus, many users will end up replacing devices before software authenticators expire. For example, the RSA SecurID® authenticator typically has a lifetime of 10 years.
Software authenticators may employ mechanisms which ensure that a given user's authenticator is installed and running on the device it is intended for. For example, a user may register their mobile phone for use with a particular software authenticator. To prevent security breaches, software authenticators such as the RSA SecurID® authenticator will ensure that the authenticator is installed on the correct registered device.
In conventional devices, transfer of a software authenticator to a new device is complicated and may be vulnerable to attack. OTP generation in software authenticators typically requires an application which includes a seed, a serial number, a display interval, display digits, and other meta-data. Software authenticators can be distributed to end-users by an authenticator management server administrator using one of a number of methods. In one method, the software authenticator is distributed using a certificate file such as the SDTID file used for RSA SecurID® Software Authenticators. In other methods, the software authenticator may be distributed using a Compressed Token Format (CTF) string or dynamic seed provisioning. An example of dynamic seed provisioning is the Cryptographic Token Key Initialization Protocol (CT-KIP).
To transfer a software authenticator, a user must contact an information technology (IT) help desk, authenticator management server administrator or some other entity associated with the software authenticator to re-issue the software authenticator to a new device or to issue a new authenticator for the new device. By way of example, a user wishing to transfer a software authenticator may be forced to perform a number of tasks. A user may request a transfer by placing a support call to an IT help desk. The user may then be required to install a software authenticator application on the new device and email a device binding identification to the IT help desk. The authenticator or authenticator data can be bound to the device identification and e-mailed or otherwise sent to the end-user. The e-mail or other communication may embody the authenticator or contain links which initiate dynamic seed provisioning for the authenticator. The end-user follows the instructions in the e-mail or other communication to import and provision or re-provision the software authenticator.
Such techniques for transferring and re-provisioning software authenticators can have significant drawbacks. For example, the IT help desk or other support resource may have limited hours, or have significant wait times. Thus, a user may be inconvenienced when attempting to transfer and re-provision a software authenticator. Such techniques may also require significant costs for the software authenticator issuer. In addition, such techniques may expose sensitive and secure data to attack. For example, if provisioning of authenticators is done via e-mail, the e-mail may contain all of the data pertaining to a user's authenticator. Thus, if a user's e-mail account becomes compromised, the software authenticator may also be compromised. A user may also forward the e-mail to others, running the risk of releasing data which should not be exposed to third parties.
Accordingly, embodiments of the invention provide techniques which give end-users a self-service option for transferring software authenticators that is more convenient, less expensive and simpler than conventional transfer and re-provisioning techniques. Embodiments of the invention provide methods for end-users to directly transfer authenticator data in a secure manner from one device to another wirelessly.
While embodiments of the invention described below may refer to a software authenticator which comprises a time-synchronous token such as the RSA SecurID® token, it is important to note that embodiments of the invention are not limited solely to use with time-synchronous tokens. Instead, embodiments of invention may be utilized with event-synchronous authentication tokens, challenge-response tokens, hash-chain tokens, or hybrid tokens that incorporate multiple such capabilities, such as hybrid time-synchronous and event-synchronous tokens. A given software authentication token may be a connected token or a disconnected token, or one capable of operating in both connected and disconnected modes.
In addition, while various embodiments are described below with respect to transfer of a single software authenticator, embodiments of the invention may be utilized to transfer multiple software authenticators, either serially or in parallel with one another.
The source mobile device 102 comprises network interface circuitry 120, a processor 122, a memory 124 and a cryptographic module 126 comprising an authenticator data encryption module 128. The target mobile device 104 comprises network interface circuitry 140, a processor 142, a memory 144 and a cryptographic module 146 comprising an authenticator data decryption module 148.
The processors 122 and 142 may comprise microprocessors, microcontrollers, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other types of processing circuitry, as well as portions or combinations of such circuitry elements.
Each of the memories 124 and 144 may comprise random access memory (RAM), read-only memory (ROM), a hard disk drive (HDD), flash memory or other types of memory, in any combination. The memories 124 and 144 may be viewed as examples of what are more generally referred to herein as “computer program products” storing executable program code.
The network interface circuitries 120 and 140 allow the source mobile device 102 and the target mobile device 104, respectively, to communicate over the network 106 with one another and with other devices, servers, etc. not shown in
The source mobile device 102 implements a cryptographic module 126 comprising an authenticator data encryption module 128. As will be described in further detail below, the cryptographic module 126 may embody a software authenticator application, token or software authenticator instance. The authenticator data encryption module 128 allows for encrypting authenticator data required to transfer and re-provision a software authenticator.
The target mobile device 104 implements a cryptographic module 146 comprising an authenticator data decryption module 148. As will be described in further detail below, the cryptographic module 146 may embody a software authenticator application, token or software authenticator instance. The authenticator data decryption module 148 allows for decrypting authenticator data received in a software authenticator transfer used for re-provisioning the software authenticator.
While
The source mobile device 102 and the target mobile device 104 may include additional components not specifically illustrated in
For security reasons, the network 106 may be a short range or private network type. For example, many processing devices including cellular phones come equipped with Bluetooth network interface circuitry. As another example, near field communication (NFC) network interface circuitry is equipped in many newer processing devices such as cellular phones. The network 106, however, may be another network type such as a WiFi or WiMAX network, a cellular network, a telephone or cable network, a local area network (LAN), a wide area network (WAN) a global computer network such as the Internet, or various portions or combinations of these and other types of networks.
It is to be appreciated that the particular set of elements shown in
As mentioned previously, various elements of system 100 such as the source mobile device 102 and the target mobile device 104, their associated functional modules such as the cryptographic modules 126 and 146, respectively, and other elements may be implemented at least in part in the form of software. Such software is stored and executed utilizing respective memory and processor elements of at least one processing device. The system 100 may include additional or alternative processing platforms, as well as numerous distinct processing platforms in any combination, with each such platform comprising one or more computers, servers, storage devices or other types of processing devices.
Such processing platforms may include cloud infrastructure comprising virtual machines (VMs) and one or more associated hypervisors. An example of a commercially available hypervisor platform that may be used to implement portions of the communication system 100 is the VMware® vSphere™ which may have an associated virtual infrastructure management system such as the VMware® vCenter™. The underlying physical machines may comprise one or more distributed processing platforms that include storage products, such as VNX and Symmetrix VMAX, both commercially available from EMC Corporation of Hopkinton, Mass. A variety of other storage products may be utilized to implement at least a portion of the system 100.
As described above, a software authenticator may include various data such as a seed, a serial number, etc. In some instances, a software authenticator application or token may be installed on both the first processing device and the second processing device, while only the first processing device has the data such as the seed and serial number required for the software authenticator to operate. In such instances, transfer of the software authenticator only requires transfer of the seed, serial number or other data associated with the software authenticator without transferring an entire software authenticator application or token. In other embodiments, the second processing device may receive the entire software authenticator application or token from the first processing device.
The methodology 200 continues with establishing 204 a network connection between the first processing device and the second processing device. As discussed above, for improved security some embodiments of the invention may establish a short range or private network connection such as a Bluetooth or NFC connection between the first and second processing devices. In other embodiments, various other network connections, including combinations of network connections, may be established.
The software authenticator data is encrypted 206 with encryption that is separate from encryption used for the network connection. The authenticator data encryption module 128 may be used to encrypt 206 the software authenticator data. Many network types provide for some type or layer of encryption to be applied to data which is transmitted over the network. For example, Bluetooth connections use shared-key authentication, strong encryption algorithms and can operate in various security modes. However, Bluetooth and other wireless network connections can introduce security vulnerabilities depending on how they are implemented and used in particular devices. This can lead to a compromise of device or software authenticator data, or render the transfer of software authenticator data susceptible to eavesdropping which is a serious concern when sensitive data such as the software authenticator data is being transmitted between devices.
To ensure secure transfer of the software authenticator data, embodiments of the invention encrypt the software authenticator data with encryption that is separate from the encryption used for the network connection. In some embodiments, portions of the authenticator data may also be separately encrypted. For example, if transfer of a given software authenticator requires transfer of both a seed value and a serial number, the seed value and the serial number may be encrypted with encryption separate from one another and separate from encryption used for the network connection. The encrypted software authenticator data is transferred 208 from the first processing device to the second processing device.
The first and second processing devices may exchange a binding identification to ensure that the software authenticator data is installed only on the correct or authorized device. In some embodiments, this binding identification can be used in the encryption of the software authenticator data or may be encrypted along with the software authenticator data, or otherwise folded into the encryption used for the software authenticator data.
The encryption used to encrypt that software authenticator data may be implemented using a number of conventional techniques and processes, such as those disclosed in A. J. Menezes et al., Handbook of Applied Cryptography, CRC Press, 1997, which is incorporated by reference herein. These conventional processes, being well known to those skilled in the art, will not be described in further detail herein, although embodiments of the invention may incorporate aspects of such processes.
It is important to note that although methodologies 200 and 300 describe the first processing device initiating the transfer of the software authenticator data, embodiments of the invention are not limited solely to this arrangement. For example, in some embodiments the second processing device may initiate the transfer of the software authenticator data, or the first and second processing devices may both initiate a transfer of the software authenticator data. In addition, while embodiments are described with respect to a network connection established for the transfer of software authenticator data, the network connection need not be used solely for the transfer of software authenticator data. In addition, establishing a network connection for the transfer of software authenticator data between the first and second processing devices does not require setting up a new network connection. Instead, embodiments of the invention may use one or more existing network connections between the first and second processing devices for transfer of the software authenticator data.
Methodology 300 continues with receiving 304 encrypted data from the first processing device. As described above, this encrypted data has encryption that is separate from encryption used for the network connection. The encrypted data is decrypted 306 to obtain the software authenticator data. The authenticator data decryption module 148 may be used to perform the decryption 306. The software authenticator data is then imported 308 or provisioned into a software authenticator stored in a memory of the second processing device. As discussed above, in some embodiments the software authenticator data may comprise a seed value, the seed value and a serial number, or some other data associated with a software authenticator. The software authenticator data may also comprise the software authenticator application itself. The memory of the second processing device may be the memory 144 in
In addition, although
In step 3, the iOS mobile application 402 retrieves authenticator data from the SecurID® software development kit (SDK) 423 for RSA SecurID® authentication tokens, serializes the software authenticator data and encrypts it for transport. The SecurID® SDK 423 is suitably modified for implementing embodiments of the invention. It is important to note, however, that other SDKs, tools and information may be used for other types of software authenticators. The SecurID® SDK 423 is modified to be capable of serializing the software authenticator data. In some embodiments of the invention, the software authenticator data is serialized to JavaScript Object Notation (JSON). The software authenticator data may be encrypted using a key derived from a user-specified password or custom key derivation function (KDF). The iOS mobile application 402 may require the user to specify a strong password for encryption and decryption of the software authenticator data. Other encryption methods and algorithms may also be used for encrypting the software authenticator data in various other embodiments of the invention.
The software authenticator data is transferred from the old device to the new device in step 4. Next, the iOS mobile application 404 decrypts and de-serializes the received software authenticator data, again using a suitably modified version of a SecurID® SDK 443 in step 5. The iOS mobile application 404 uses the decrypted software authenticator data to import or provision a software authenticator into an authenticator memory 445 in step 6. The iOS mobile application 404 will then confirm that the software authenticator was successfully transferred in step 7. It is important to note that more than one software authenticator may be transferred between devices. As such, the confirmation in step 7 can specify a particular software authenticator or authenticators which were successfully transferred.
On receipt of the confirmation from the iOS mobile application 404, the iOS mobile application 402 running on the old device will remove the authenticators which were successfully transferred from the authenticator memory 425 in step 8. Various processes and protocols may be used in the iOS mobile application 402 running on the old device, and more generally the source processing devices described herein, for removing authenticators after successful transfer of the software authenticator or authenticators. This eliminates multiple copies of the software authenticator or authenticators on different devices.
In some embodiments, once a software authenticator is successfully transferred and imported to the target processing device, the software authenticator may be re-seeded using a specific key derivation algorithm known by the target processing device and an authentication manager. This re-seeding may comprise application of a silent alarm function in a software authenticator, such that the re-seeding event is seamless to the end-user. After the software authenticator is transferred to the target processing device, an end-user will attempt to authenticate to some entity using the software authenticator. As an example, the software authenticator may generate an OTP using the software authenticator as usual. In the case of a time-based software authenticator token, the authentication manager will perform its normal OTP time-based matching. Since the software authenticator is re-seeded, this will fail and a silent alarm is triggered.
The authentication manager, in response to the silent alarm, attempts to locate an OTP match with a derived seed. Assuming the software authenticator was successfully transferred and has not been tampered with or otherwise compromised, the authentication manager will find the derived seed which matches the re-seeded software authenticator and associate the new seed with the particular software authenticator. In some embodiments, this may involve caching the new seed. As a result, the source processing device and/or any other device which has an old copy of the software authenticator is rendered useless since these devices have not been re-seeded.
In other embodiments, approaches other than the silent alarm/re-seeding protocol described above may be used. For example, in some embodiments the software authenticator may be configured to allow the end-user to register new devices. For example, the software authenticator on a source processing device, a target processing device, or some other processing device may be configured to allow an end-user to register the target processing device before, during or after transfer of the software authenticator data. The target processing device may be registered with an authenticator management server, an IT help desk, or other entity associated with the software authenticator. Registering the target processing device can cause such entities to generate a special code, key, command or other instruction which is sent to the target processing device. This special code, key, command or other instruction can cause the software authenticator on the target processing device to re-seed, thus rendering old copies of the software authenticator useless. Use of a special code, key, command or other instruction can minimize exposure of the authenticator data in comparison to techniques wherein the software authenticator data is sent in an e-mail from an IT help desk, an SDTID file, etc.
In various embodiments of the invention described above, techniques are described which allow a user to transfer software authenticators in a manner which does not require the user to contact an IT help desk, an authenticator management server administrator or other entity associated with the software authenticator. As such, embodiments of the invention permit end-users to self-service their software authenticators in a seamless manner. Embodiments of the invention, however, are not limited to arrangements wherein the user cannot contact an IT help desk, authenticator management server administrator or other entity associated with the software authenticator. Instead, in some embodiments of the invention processing devices may communicate with such entities as part of the software authenticator transfer process.
The particular processing operations and other system functionality described in conjunction with the flow diagrams of
It is to be appreciated that the software authenticator transfer functionality such as that described in conjunction with the flow diagrams of
The foregoing examples are intended to illustrate aspects of certain embodiments of the present invention and should not be viewed as limiting in any way. Other embodiments can be configured that utilize different software authenticator transfer techniques.
It should again be emphasized that the above-described embodiments of the invention are presented for purposes of illustration only. Many variations and other alternative embodiments may be used. For example, the techniques are applicable to a wide variety of other types of processing devices and software authenticators.
As another example, in some embodiments of the invention, the communication system 100 in
Also, the particular configuration of communication system and processing device elements shown in
Patent | Priority | Assignee | Title |
11366905, | Jul 04 2016 | SEW-EURODRIVE GMBH & CO KG | Security device and method for operating a system |
11805112, | Feb 08 2021 | Cisco Technology, Inc.; Cisco Technology, Inc | Enhanced multi-factor authentication based on physical and logical proximity to trusted devices and users |
11863549, | Feb 08 2021 | Cisco Technology, Inc.; Cisco Technology, Inc | Adjusting security policies based on endpoint locations |
Patent | Priority | Assignee | Title |
4800590, | Jan 14 1985 | HIGGINS, WILLIS E | Computer key and computer lock system |
6237095, | Sep 29 1995 | Maxim Integrated Products, Inc | Apparatus for transfer of secure information between a data carrying module and an electronic device |
6985583, | May 04 1999 | EMC IP HOLDING COMPANY LLC | System and method for authentication seed distribution |
8219817, | Jul 11 2006 | Dialogic Corporation | System and method for authentication of transformed documents |
8233841, | Jan 30 2008 | PayPal, Inc | Near field communication initialization |
8307410, | Aug 12 2008 | MasterCard International Incorporated | Systems, methods, and computer readable media for providing for secure offline data transfer between wireless smart devices |
8327429, | Aug 22 2008 | Citibank, N.A. | Systems and methods for providing security token authentication |
8392702, | Jul 27 2007 | Google Technology Holdings LLC | Token-based management system for PKI personalization process |
8595810, | Jan 13 2013 | OPTIMA DIRECT, LLC | Method for automatically updating application access security |
8745710, | Jun 25 2012 | Amazon Technologies, Inc | Automated secret renegotiation |
20010002485, | |||
20020143855, | |||
20030115467, | |||
20040088347, | |||
20040117623, | |||
20050021982, | |||
20050136964, | |||
20050160269, | |||
20060059346, | |||
20060208066, | |||
20070230694, | |||
20070234064, | |||
20080010449, | |||
20090300738, | |||
20100024004, | |||
20100199336, | |||
20100257578, | |||
20110016320, | |||
20120124651, | |||
20120174198, | |||
20120278241, | |||
20130061055, | |||
20130091544, | |||
20140201536, |
Date | Maintenance Fee Events |
Jul 22 2019 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Jul 20 2023 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Date | Maintenance Schedule |
Feb 23 2019 | 4 years fee payment window open |
Aug 23 2019 | 6 months grace period start (w surcharge) |
Feb 23 2020 | patent expiry (for year 4) |
Feb 23 2022 | 2 years to revive unintentionally abandoned end. (for year 4) |
Feb 23 2023 | 8 years fee payment window open |
Aug 23 2023 | 6 months grace period start (w surcharge) |
Feb 23 2024 | patent expiry (for year 8) |
Feb 23 2026 | 2 years to revive unintentionally abandoned end. (for year 8) |
Feb 23 2027 | 12 years fee payment window open |
Aug 23 2027 | 6 months grace period start (w surcharge) |
Feb 23 2028 | patent expiry (for year 12) |
Feb 23 2030 | 2 years to revive unintentionally abandoned end. (for year 12) |