JP2010537270A - Virtual token for implicit self-installing security environment - Google Patents

Abstract

  A virtual token for use in a virtual computer environment that implements the secure cryptographic capabilities of hardware security tokens within a computer without requiring custom installation or administrative privileges. The hardware security token has a virtual environment and an automatic installer for the virtual token. When plugged into a computer, the hardware security token automatically performs dynamic installation as needed, providing secure cryptographic services to standard application programs already installed on the computer. After the session is complete and the security token is removed from the computer, the virtual environment is hosted implicitly to the user, without any user attention, and without any changes to the computer operating system. It is effectively uninstalled from the computer.

Description

  The present invention relates to computer security tokens, and more particularly to virtual tokens for self-installing client environments that are transparent to the user.

  As used herein, the term “security token” is for individuals who have and protect sensitive and sensitive information and provide security-related services, including but not limited to privacy, access control, authentication, and data protection. Means a portable electronic device. The term “hardware security token” is sometimes used to emphasize the implementation of a security token as a physical device. The term “access” is used herein to enter and / or change to enter a restricted physical location or to engage in restricted data or information, computer facilities, or restricted communications. Means permission. The term “authentication” here means the establishment and verification of identity (identity) and includes (but is not limited to) the identity of the user of the security token. Sensitive sensitive information contained by security tokens includes (but is not limited to) usernames, passwords, account numbers, access codes, digital certificates, encryption / decryption keys, security policies, and the like. Sensitive sensitive data capabilities included by the security token include digital signature creation and verification, challenge response capability, username and / or password and / or personal identification number (PIN) presentation, one-time password generation, data authentication / verification Capabilities (including but not limited to) capabilities, confidential data storage, and encryption / decryption / hashing capabilities. Sensitive sensitive data information contained within a security token is typically protected by using smart card chip technology. A properly constructed smart card can constitute a security token.

One of the principal places for the use of security tokens is in personal computers, especially those connected to insecure public networks such as the Internet. Specific uses of security tokens on personal computers include (but are not limited to):
Virtual private network (VPN), access to a secure virtual network within a public network;
• access to bank accounts or other sensitive data through public networks; and • signing, encryption, verification, and / or decryption of emails or other documents sent over public networks.
In all these cases, personal computers rely on security tokens to perform certain cryptographic services. By sending data to a security token for encryption, decryption, hashing, signing, verification, etc., sensitive cryptographic data is (not necessarily secure and sensitive cryptographic data is subject to loss or loss of confidentiality) Instead of being sent to a personal computer, it is securely maintained in a security token.

  However, in order to use a security token that provides cryptographic services, the personal computer needs to have some data processing capability, which is embodied in an environment commonly referred to as a “client environment” for the security token. It has become. A layer diagram of a typical prior art client environment 100 for a security token or smart card is shown in FIG.

  FIG. 1 illustrates a cryptographic service from a security token or smart card (including, as a non-limiting example: the digital signature of an email message with the user's private key; and access to a restricted WEB site on the Internet ) A typical user application program 101 (including, by way of non-limiting example, the following: an email client such as Microsoft's “Outlook” ®); and Mozilla's “Firefox” ”(A registered web browser) The application program 101 communicates with a cryptographic service provider (CSP) layer 103 to gain access to cryptography and other security services. The CSP layer 103 communicates sequentially with various lower level drivers such as the smart card driver 105, the hardware token driver 109, or the chip smart card interface device driver (CCID) 113, and the smart card 107, the hardware token 111, Or access each physical device such as a USB smart card device 115 (such as a smart card reader or USB security token). As a non-limiting example of a typical prior art additional device connection, the application program 101 includes: a physical removable mass storage device 119 (such as a flash memory unit) via a mass storage device driver 117; and a human interface device driver 121. Via this, a human interface device 123 (such as a keyboard) can also be accessed. Both mass storage device driver 117 and human interface device driver 121 are typically standard software components in modern personal computer operating systems.

  If the user wants to adopt his own personal computer as a client for the security token, the above environment is usually installed on the personal computer, so that when the security token is plugged into the computer, the desired The application program has encrypted access to the security token. In particular, the CSP 103 and smart card driver 105 and, if necessary, the hardware token driver 109 must be installed. This is a mode for personal computer operation that is currently employed by users of security tokens. Unfortunately, however, installing the CSP 103 on a computer usually requires special administrator rights. This is because the installation can make permanent changes to the computer's operating system.

  However, because security tokens are portable, there are frequent opportunities for users to desire to adopt their own security tokens at different locations using different personal computers that dominate client application programs temporarily. However, in such cases, the user faces the problem of installing the client environment on a new host computer. Installing such an environment on a computer is not only a time consuming and annoying operation, but as indicated, the user also needs to carry around the installation media, and the user has administrative privileges. It is necessary to have. Further, the host computer owner or administrator may not want the client environment to remain on the computer after the user completes temporary access. Therefore, the user will have to uninstall the client environment. However, despite such removal, changes to the host computer operating system may remain.

  Therefore, it is necessary to have a security token in the client environment on the host computer that does not require the user to actively install and uninstall (it does not require administrator rights and does not change the operating system) Is widely recognized, and such would be a great advantage. This object is met by the present invention.

  The present invention is a virtual token for use within a virtual environment and does not require a user to install or uninstall a client environment on a host computer. In an embodiment of the present invention, including a hardware security token that automatically performs a virtual token installation in a virtual environment on the host computer and does not require administrator privileges, implicitly to the user, and The installation is effectively uninstalled when the session is completed, and the hardware security token is removed from the computer.

  Therefore, according to the present invention, a virtual token for providing a security service to an application program executed in a virtual environment in a computer operating system is provided, and the virtual environment is a virtual cryptographic service provider for providing the application program. The virtual token includes: (a) an interface to the virtual cryptographic service provider layer; (b) a protocol formatter for formatting data received from the interface and formatting data sent to the interface And (c) includes a hardware security token that is constructed to interface with the computer and provide security services through a protocol formatter.

Furthermore, according to the present invention, there is also provided a security token for providing a security service to an application program in a virtual environment in a computer operating system, the security token including: (a) interactive data An interface to a computer for exchanging data with each other; (b) a virtual environment loader constructed to load a virtual environment into an operating system, the virtual environment being a virtual cryptographic service provider layer And (c) an installation script for installing a virtual token in a virtual environment, the virtual token including: (d) an interface to the virtual cryptographic service provider layer For communicating with an application program; and (e) a protocol formatter for formatting data received from and sent to a bidirectional data interface. .
The present invention will now be described by way of example only with reference to the accompanying drawings.

FIG. 1 shows a layer of a typical prior art client environment for a smart card or secure hardware token. FIG. 2 is a diagram illustrating layers of a virtual client environment having virtual tokens according to an embodiment of the present invention. FIG. 3 conceptually illustrates protocol formatter wrapping and unwrapping employed by an embodiment of the present invention. FIG. 4 conceptually illustrates implicit self-installation of a security environment in a computer with a security token according to an embodiment of the present invention.

  The principles and operation of a virtual token in a virtual client environment implicitly self-installed by a hardware security token according to embodiments of the present invention will be understood by referring to the drawings and the accompanying description.

The virtual token term “virtual token” refers herein to executable software for a computer that provides the same security-related services to application programs that would be provided by a hardware security token. In an embodiment of the present invention, the virtual token communicates with and operates in conjunction with an external hardware security token to provide services.

  FIG. 2 illustrates the level of the virtual client environment 203 within the computer operating system 201 of the host computer. A virtual token 205 according to an embodiment of the present invention has an interface 207 to a virtual CSP layer 206 that is installed and executed within the virtual environment 203 (as will be shown in more detail below).

  The application program 204 is a normal version of an application program intended for the computer operating system 201 and has not been specifically modified in relation to accessibility to security services provided by external services or devices. In that respect, the application program 204 is considered “standard”. In a non-limiting example, the application program 204 is a standard web browser without any customized features or changes, such as Microsoft's "Internet Explorer" (registered trademark) or Mozilla's "Firefox" (registered trademark). It is. The application program 204 accesses the virtual CSP layer 206 via the interface 202. From the standpoint of the application program 204, the access to the virtual CSP layer 206 is performed in exactly the same manner as the previously described application program 101 accesses the CSP layer 103 (FIG. 1). However, the difference with respect to the CSP layer 206 is that installing the CSP layer 206 in the virtual environment 203 does not require administrator rights or other special arrangements. As long as the operating system 201 is involved, the virtual environment 203 is just another application program, and the CSP layer 206 therein is just a part. Accordingly, the operating system 201 does not impose any authority restrictions on the installation of the CSP layer 206. Thus, the CSP layer 206 can be loaded automatically while loading the virtual environment 203.

  Virtual environments for computers are known in the prior art and are available through sources such as: Ceedo Technologies, Rosh-Hayin, Israel; InstallFree, Stamford, CT; MokaFive, Redwood City, CA; Sun Microsystems, Santa Clara, CA (“Virx”; Lauderdale FL (“XenDesktop”).

  The virtual token 205 converts the data to the outside in the wrap operation 211 and converts the data to the inside in the unwrap operation 227, and converts the data to the protocol formatter 209 via the interface 213. Communicate. In this way, the virtual token 205 communicates with the outside via the compatible device driver 215 of the operating system 201. As a non-limiting embodiment of the present invention, the protocol formatter 209 formats outgoing data for and receives incoming data for a mass storage device driver, which typically is a user. Is included in or pre-installed in modern operating systems as a native device driver that does not require installation by That is, in this non-limiting embodiment, device driver 215 is a mass storage device driver. In a preferred embodiment of the present invention, device driver 215 is such a pre-installed or native device driver, and non-limiting examples thereof include not only the mass storage device driver described above, but also a keyboard. Also includes human interface device drivers such as drivers. In other embodiments of the present invention, the device driver 215 is more specialized. Non-limiting examples of more specialized device drivers include device drivers for various types of dedicated smart card readers known in the prior art.

  Also included but not shown in FIG. 2 is a physical data connection between the computer operating system 201 and the external user security token 221. Examples of such physical data connections include: pluggable connection devices such as USB connection devices; radio frequency (RF) data links such as proximity RF, Bluetooth®, and the like; and ISO 7816 smart card connection devices (But not limited to).

  The device driver 215 has an interface 217 that enables data communication with a compatible external user security token 221. In a preferred embodiment of the present invention, the security token 221 is adaptable to a computer's pre-installed or native device driver (as discussed above) and includes a protocol formatter 219 thereon. In a non-limiting embodiment of the present invention, protocol formatter 219 formats the data for adaptation to a mass storage device or a human interface device. The protocol formatter 219 converts the data from the interface 217 to the security token format through the unwrap operation 223 and converts the data from the security token format to the interface format through the wrap operation 225. In another embodiment of the invention, protocol formatter 219 is included as part of the smart card reader interface.

Wrapping and Unwrapping Protocol Format The wrapping and unwrapping operations discussed here will now be readily apparent with reference to FIG. The data item 301 is formatted in the first protocol P1. Data item 301 can be any data associated with protocol P1 and can be defined for use with protocol P1. This includes, but is not limited to: commands; messages; notifications; requests; responses; data arguments; In the wrapping operation 305, the data item 301 is taken into the format 303 of the second protocol P2. Thereby, a data item 307 compliant with the protocol P2 standard is formed and can be transmitted, received and handled by hardware and software conforming to data in the P2 format. Finally, in the unwrapping operation 311, the original data item 301 is extracted and the format 303 to P2 is discarded. Protocol formatting in this order is a well-known prior art that allows data in one format (eg P1) to be handled by devices and software that do not recognize P1, but instead function via P2. To.

  In the general case of cryptographic protocols, “wrapping”, encryption commands, requests, responses, parameters and data are encrypted inputs, as non-limiting examples, mass storage access commands, requests, responses, parameters and It needs to be reformatted so that it is clear that it is data. In a specific instance of this non-limiting example, an encryption command that digitally signs a portion of the plaintext using the security token's private key is wrapped (reformatted) and the plaintext is written to a specific location in mass storage Such a “write” command is used. In this case, the specific location of the mass storage does not actually exist in the mass storage device (security token), but instead wraps the digital signature in plaintext using the user's private key (only the security token has) As a command, the security token can interpret this location. This command is passed by the operating system 201 from the virtual token 205 in the virtual environment 203 to the security token 221 through the mass storage driver as it is, and whether this command is a legitimate mass storage device for the operating system 201. looks like. When the command is received by the protocol formatter 219 of the security token 205 (a non-limiting example of this is a mass storage device interface), the protocol formatter 219 recognizes that the location specified in the command does not exist and accurately Interpret the command as a wrapped command. Then, the protocol formatter 219 unwraps the command by reformatting it into a corresponding encryption command, and causes the user security token 221 to have a plaintext digital signature. To return the signed plaintext to the virtual token 205, the protocol formatter 219 wraps the signed plaintext and returns the data to the virtual token 205 through a mass storage device interface for subsequent unwrapping. Thus, the virtual token 205 receives the signed plaintext, which is passed to the virtual CSP layer 206 and from there to the application program 204 in the virtual environment 203 of the host computer.

Virtual Token Operation In practice, the virtual token 205 operates as follows:
When the application program 204 requires a security token service (data encryption as a non-limiting example thereof), the service from the virtual token 205 in its standard way through the virtual CSP layer 206 via the interface 207. Request. In an embodiment of the present invention, the virtual token 205 translates the incoming request into a format compatible with the external user security token 221 and wraps the translated request via the protocol formatter 209 in the wrapping operation 211.

  Thereafter, the wrapped and translated request of the application program 204 is sent to the device driver 215 via the interface 213 and from there to the protocol formatter 219 via the interface 217. The protocol formatter then unwraps the translated request from the application program 204 via an unwrapping operation 223. The user security token 221 then receives the translated request and provides the requested service. In the non-limiting example described above, this is a request to encrypt the data, so the security token 221 encrypts the data as requested. The response from the security token 221 (encrypted data) is wrapped in a format compatible with the device driver 215 by the protocol formatter 219 via the wrapping operation 225, and the device driver 215 responds with a response wrapped through the interface 217. Is received and a wrapped response is made to the protocol formatter 209 via the interface 213. The protocol formatter 209 then unwraps the wrapped response via the unwrapping operation 227 and presents the response to the virtual token 205, which sends the response to the application program 204.

  Therefore, although the service is actually executed by the external user security token 221, the application program 204 acquires a necessary service from the virtual token 205. In this way, services are provided securely. As a non-limiting example of data encryption, for example, the encryption key is always held in the user security token 221 and is thus protected from disclosure or unauthorized use.

Hardware security built to automatically install the virtual environment 203 along with the virtual token 205 in the operating system 201 (discussed previously and shown in FIG. 2) within the implicit self-install security environment computer 409 The token 401 is conceptually shown in FIG. As already mentioned, the installation is implicit for the user in that the user does not have to perform any special installation or other actions. According to an embodiment of the present invention, the security token 401 is plugged into the appropriate port of the computer 409 (in a non-limiting example, by simply linking the security token 401 to the computer 409 via their bidirectional data interface. The automatic installation is initiated without further user involvement or notification. Similarly, in an embodiment of the present invention, when the user disconnects the security token 401 from the computer 409 (as a non-limiting example, by ejecting or withdrawing), the virtual environment 203 and all of its components and content are Uninstallation is performed implicitly from the computer 409 without any notice or attention to the user. Furthermore, these processes do not result in any changes to the operating system 201 being made.

  Security token 401 includes smart card chip 403, flash memory 405, and controller 407 for these interfaces to computer 409. According to an embodiment of the present invention, the security token 401 has a bidirectional data interface to the computer 409 so that data can be exchanged between them. It is on this bidirectional data interface that the security token 401 communicates with the virtual token 205 via the device driver 215. In a preferred but non-limiting embodiment of the present invention, the security token 401 (as shown in FIG. 4) is a USB security token with a USB connection device 408 for this bi-directional data interface. Other embodiments of the invention feature other bidirectional data interfaces.

  As described above, the automatic installation is executed by the virtual environment loader 411 that is executable software stored in the security token 401 and executed on the computer 409. According to the embodiment of the present invention, the standard application program 415 already loaded on the computer 409 is activated as the application program 204. The application program 204 interfaces to the virtual token 205 via the virtual CSP layer 206 as previously discussed.

  In one embodiment of the invention, the virtual environment 203 and all of its components (including the virtual token 205) are loaded from the flash memory 405 into the computer operating system 201. In another embodiment of the present invention, the virtual environment 203 and all of its components (including the virtual token 205) are passed through a computer network, such as the Internet 427 according to the URL or IP address 425 contained within the security token 401, Downloaded to the computer operating system 201. The URL and the IP address are resources on the computer network that can download the virtual environment 203. According to yet another embodiment of the invention, some portions of the virtual environment 203 are downloaded from the computer network and the remaining portions are loaded from the flash memory 405. In the preferred embodiment of the present invention, all virtual environments 203 (including the virtual CSP layer 206) are downloaded from the computer network and only the virtual token 205 is loaded from the flash memory 405.

  According to the embodiment of the present invention, the virtual environment loader 411 has a short installation script 412. In some embodiments, security token 401 pretends to be a mass storage device such as a CD-ROM. As a result, when plugged into the computer's USB port, it appears to the computer as if a mass storage device with automatic playback capability, such as a CD-ROM, is currently connected. When the automatic playback function is automatically activated by the computer operating system, the installation script 412 is executed.

Variations for different existing computer configurations Preferably, the existing configuration of the computer 409 is taken into account for optimal effect.

  According to an embodiment of the present invention, when the installation script 412 is executed, the script first checks whether public key infrastructure (PKI) client middleware (CSP and smart card driver) is already installed on the computer 409. To do. In that case, the computer 409 has already been constructed to interface to a security token as a cryptographic service provider, and the security token 401 can be used as a smart card device with cryptographic functionality to the PKI client middleware. The process is substantially complete at this point, simply signaling its presence. All that remains is to launch the user application program 415 for the security token 401. In the embodiment of the present invention, the application program 415 is also automatically activated by the installation script 412. In some cases, the application program 415 may need to be built according to user preferences (eg, loading a user's “favorites” for an Internet browser).

  However, in another embodiment of the present invention, if no public key infrastructure client middleware is present, the install script 412 checks whether the CCID is already installed on the computer 409. If so, the computer 409 has already been constructed to interface with the security token 401 (shown as a USB device in FIG. 4), and the security token 401 performs processing to emulate the mass storage device. And installs its own PKI virtual client environment. However, due to the presence of the CCID on the computer 409, this installation is relatively simple and only requires the user application program 415 and the virtual CSP layer 206. The virtual CSP layer 206 interfaces with the CCID to access the security token 401 directly.

  According to yet another embodiment of the present invention, if the CCID does not exist on the computer 409, the computer 409 cannot access the security token 401 as a normal smart card device. In this case, the installation script 412 installs the complete virtual client environment 203 as described above.

  Although the invention has been described with respect to a limited number of embodiments, it will be understood that many variations, modifications, and other applications of the invention are possible.

Claims (6)

A virtual token for providing a security service to an application program executed in a virtual environment in a computer operating system, the virtual environment having a virtual cryptographic service provider layer for providing the application program The virtual token comprises:
An interface to the virtual cryptographic service provider layer;
A protocol formatter for formatting data received from the interface and for formatting data sent to the interface; and, coupled to the computer, constructed to provide the security service through the protocol formatter. Hardware security token. The virtual token of claim 1, wherein the protocol formatter is: a mass storage device;
・ Human interface devices;
A virtual token that conforms to a device driver selected from the group consisting of The virtual talk of claim 1, wherein the security service is selected from the group consisting of:
·privacy;
·access control;
・ Authentication / confirmation;
・ Data protection;
Encryption / decryption / hashing;
・ Digital signature creation / verification;
・ Digital certificate creation / verification;
・ Challenge / Response;
・ User name / password / PIN (personal identification number) / access code display;
・ One-time password generation;
-Sensitive data storage. A security token for providing a security service to an application program in a computer operating system, the security token comprising:
A bidirectional data interface to the computer for exchanging data;
A virtual environment loader constructed to load a virtual environment into the operating system, the virtual environment including a virtual cryptographic service provider layer; and, for installing a virtual token in the virtual environment An installation script, where the virtual token includes:
• an interface to the virtual cryptographic service provider layer for communicating with the application program; and • formatting data received from the bidirectional data interface and formatting data sent to the bidirectional data interface. Protocol formatter for.   The security token according to claim 4, further comprising a flash memory, wherein at least the loading portion of the virtual environment is performed through loading from the flash memory. The security token according to claim 4, wherein:
A URL of a resource on the computer network; and security, further comprising at least one of an IP address of the resource on the computer network, wherein at least the loading portion of the virtual environment is performed through a download from the resource token.

Images