Patent Application
20080089520
In the following detailed description, presently preferred embodiments of the invention are further described with reference to the following figures:
a: A schematic presentation of the second part of the steps performed for a retrieval and an online validation of the inner signature of the user mapping information, according to one embodiment;
b: A schematic presentation of an offline validation of the inner signature of the user mapping information, according to one embodiment;
While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and are herein described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended claims.
It is apparent that that the concept of mapping user ids with an identity management system could be extended to more than the two domains 10, 20 shown in the simplified
If the user identity database 50 is tampered with, a user id of the first domain 10 may no longer be assigned to the correct user id of the second domain 20. As a result, operations could be performed in the second domain 20 under a false identity, without the user 1 being aware of.
To address this problem, some embodiments allow for verification of the mapping information for both the user 1 and the application 30. In one embodiment, a trust centre (PKI, Public Key infrastructure) may be used. However, this is not essential to the invention. In order to assure the integrity of the mapping data stored in the user identity database 50, each user may first agree to the user mapping by signing his mapping data with his private key in step 100 shown in
The mapping data and the signature value may be sent in step 110 to the identity management system 40 for storing. To increase the security, a SSL communication (secure socket layer) may be used. In a next step 120, the identity management system 40 may again sign the received information with its own private key and may store, in step 130, the two-fold signed mapping information in the user identity database 50.
At any point later in time, the application 30 can perform the required user mapping by performing the following validation steps: At first, the two-fold signed mapping information may be obtained from the identity management system in steps 150 and 151 (cf.
In the next step 170, the method may verify that the authenticated user 1 has defined and agreed to the mapping by validating the inner signature. If the application 30 is in possession of the user's certificate, it can perform the validation offline by checking that the authenticated user's credentials 80 match the certificate credentials 81 as well as the information from the user mapping data 82 (cf.
Alternatively it can use an online validation with the trust centre (PKI) 70, as schematically shown in
If a password is needed to access the second domain 20, it is not sufficient to assure its integrity in the user mapping database 50. On the contrary, it may not only be protected against tampering but also may be kept in a truly secure and encrypted manner, which is, for example, not the case in prior art systems such as Kerberos. Otherwise, there would be a security gap that could be exploited in a malicious attack (e.g. to commit fraud or steal identity). As noted previously, in prior art systems the user has typically no control over how the password is stored or used. Therefore, he is required to give absolute trust to the system that stores and uses his password.
As shown in
When the password 210 is required by the application 30 (e.g. in order to access the resources in domain 20), then the application 30 may first execute all the steps to obtain the validated user mapping information as described previously. In order to decrypt the encrypted password, the application 30 may then perform the following steps (cf.
In step 310, the first part 221 of the encrypted password key 220 may be sent to the user 1. The user 1 can decrypt the part 221 of the key 220 by using his private key. It is to be noted that neither the password 210, nor the complete key 220 to decrypt the password 210 travels on a communication channel during this step.
The application 30 may take, in step 320, the second half 222 of the encrypted encryption key 220 and send it to the trust centre (PKI) 70 for decryption. The dashed lines in
As a result, the password 210 is under the user's control and can be decrypted without exposing the user's private key. Tampering with the password 210 is no longer possible nor is passing around the password 210 without the user's knowledge and permission. Malicious attacks are therefore better defended, since the complete key 220 required to unlock the password 210 is never transmitted as a whole (e.g. on a single communication path).
The described method can be effectively used in all systems where personal and sensitive data is stored and should be revealed only at the time where all participating parties (user and application) agree. Further, if the encryption key 220 is divided into more than two parts, there could be more parties required to agree before an encrypted encryption key for the encrypted personal and sensitive data can be fully assembled from its various decrypted parts. In fact, this feature may allow for any number of participants. Accordingly, in a scenario like a bank—when private data needs to be protected—a normal transaction might only require two keys, but for ‘higher risk’ transactions, the data could be additionally protected with a third key (for example of an additional supervisor) to unlock the information. It is to be noted that it is easy to change the number of keys required.
An additional security feature (not shown) for providing even more protection against malicious attacks can be realized by providing the application itself with additional credentials, which are also verified, for example by the identity mapping system 40 and/or the trust centre (PKI) 70. This overcomes a remaining security problem, where, if by some means (e.g. Trojan horse), the application is replaced. Since the application may be activated by a user running with administrative privileges, also a (secretly) replaced application would have these privileges. However, in case of an additional verification of a certificate/identity of the application by the trust center (PKI) and/or the IMS, there would be a considerable hurdle for any faked or malicious application to overcome. This feature may be particularly important to financial companies such as banks which create an application once and then have a widely replicated distribution. In such a situation one could envisage a malicious attack on the application at a number of stages in its production, distribution and installation stages. In addition, companies and organizations who provide operating system software, such as Windows or Linux, might well find a use for such a feature in protecting critical access to parts of their O/S as well as critical files. Users of such operating systems might also get added protection to their own files and discs.
Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.
| Number | Date | Country | Kind |
|---|---|---|---|
| 06 021 701.5 | Oct 2006 | EP | regional |
