Use Nix Security 08 Poster Proposal

7/28/2019 Use Nix Security 08 Poster Proposal

1/5

Handling Identity Agent Compromise in

User-Centric Identity Management Systems

Daisuke Mashima Mustaque AhamadCollege of Computing, Georgia Institute of [email protected] [email protected]

IntroductionThere is considerable interest in secure online and digital identity management because of rampant

theft and misuse of identity credentials. We explore user-centric identity management architecture,

which is the recent trend in this area. In user-centric identity management, users can flexibly choose

what identity information is released to other entities and have more control over the use of their

identity credentials. However, user-centricity requires users to be involved in the loop. In addition,

disclosure of users identity information needs to be under user control, which implies that users

identity credentials, including users private key, are managed in users domain. To satisfy these

requirements without sacrificing usability and security, an approach that relies on locally-installed

agent software on user devices or networked agent trusted by users, has been proposed by a number

of user-centric identity management schemes. For example, Microsofts CardSpace [1] utilizes client-

side software to achieve user control and an identity credential is provided by online identity providers

selected by a user. In Sxip [2], Homesite can be considered as a networked agent mentioned earlier.

The hybrid approach, which uses both of local agent and networked agent, such as Georgia InstituteTechnologys GUIDE-ME [3], is also proposed, and it can enable users to exercise more flexible

control over the usage of their online identity. Therefore, we are envisioning that such identity agents

will play a major role in future user-centric identity management.

The nature of locally-installed and networked identity agents, also called Local IdA and Remote IdAin this paper, will make them potential targets of attack and theft. The compromise of such agents

could lead to serious consequences, including breach of authentication and authorization in a systemwhere access to services must only provided to legitimate users. The Local IdA runs on a device

carried by a user which can be misplaced, lost or stolen. More specifically, storing private keys of

users on users devices would make them more prone to identity theft. Regarding networked agents,

even though we assume that they are operated by a third party trusted by users, it could becompromised. If users identity credentials are stored on them, it would lead to identity misuse.

Clearly, we must deal with the problem of compromised identity agents by revoking potentially stolen

credentials and regenerating new ones for the legitimate users. We explore a solution that has severalnice properties. In our proposed scheme, loss of a user device hosting Local IdA or compromise of a

Remote IdA does not mean that an adversary can impersonate the legitimate user without being

detected. Second, the private key of a user can be mostly off-line and thereby the risk of compromise

of the users key is minimized. Thirdly, revocation of potentially stolen credentials and recovery ofLocal IdA and Remote IdA can be done easily and immediately. Fourthly, identity related transactions

involving identity agents can be monitored by another networked entity that is chosen by a user when

the user intends to be monitored. Lastly, only a primitive storage token, such as a normal USB drive,

is required at the user side additionally.

In this paper, we will outline the basic concept of our approach that prevents identity misuse and

handles compromised identity agents, which relies on a threshold signature scheme [4]. We also

include brief evaluation of our scheme.


2/5

Assumptions and ScopeWe are focusing on an identity management system architecture in which knowledge of users private

keys is verified by relying parties that utilize identity information. We assume digitally signed

messages sent to relying parties or signature on a onetime challenge generated by relying parties isused for such verification. Because the number of identity management architectures that satisfy this

assumption is increasing, including Microsofts CardSpace, Credenticas U-Prove [5], Georgia TechsGUIDE-ME, and so on, we expect that our approach can be widely implemented.

Another assumption we base on is that non-malicious relying parties do not accept identity credentials

until validity of signature presented by legitimate identity owner is verified. In some architecture, it

would be possible for relying parties to accept identity credentials without verifying the signature, butwe assume that relying parties reject identity credentials that are not accompanied by valid user

signature. We believe this assumption practically holds because following the correct protocol is

beneficial for relying parties for the sake of their own credibility and reputation.

Under these two assumptions, identity misuse can happen only when a legitimate users private key is

compromised. Thereafter, we will mainly discuss the protection of user private keys tied to identity

credentials.

Basic ApproachThe one major problem of identity management systems in the scope of this paper is that if a users

device hosting the Local IdA is compromised or physically stolen, an adversary can have full

capability to use legitimate users identity information because he can initiate transactions and also

provide valid user signature. It is possible to store the private key on Remote IdA running on a trusted

third party, but we can not completely eliminate the possibility that the agent is compromised. Thus, to

mitigate such threats, it is necessary to eliminate the single point of attack that could give an adversary

full privilege to utilize stolen identity credentials. In other words, under our assumptions, keeping

users private key in an off-line safe place as long as possible is highly effective. Another issue is the

revocation of compromised identity credentials. To disable compromised agents, the revocation of

users private key is required. However, this could take a long time to propagate revocationinformation to relying parties because such a process needs to depend on a certification authority (CA)

that certifies the users public key. It is desirable that user can revoke it without involving the CA.

Furthermore, the systems should have some support to help the legitimate user to recognize the

problem in case the compromise of agent happens.

Based on these observations, we propose a scheme based on thresholds signature. This scheme

enables us to split a users private key into more than one parts, which are called key shares. Each key

share is used to make a partial signature, also called a signature share, on an arbitrary data, and

signature shares more than a pre-defined threshold can be combined into a valid signature that can be

verified by using users public key. For example, under 2-3 threshold signature scheme, 2 signature

shares are enough to generate a complete signature, but less than 2 signature shares can not be

combined into a valid signature.

The figures below illustrate our approach in a simple setting involving only Local IdA on users

device. Note that we add a storage token, for example an inexpensive USB drive, and online trusted

entity called a monitoring agent, each of which holds one distinct key share, to the underlying

architecture. The monitoring agent is considered to be run on a trusted third party. Here, we use 2-3

threshold signature scheme, but note that the number of total key shares and threshold value vary

depending on underlying system architecture.


3/5

Figure 1: Proposed Architecture with storage token

Figure 2: Proposed Architecture without storage token


4/5

As shown in the figures, one key share is stored on Local IdA, a second one is stored on a newly-

introduced monitoring agent, and the third is stored in a users storage token. If a user provides a

storage token (Figure 1) that contains one key share, the local IdA can generate two partial signatures.

Then, it can combine them into one valid signature that can be verified by a relying party. In this case,

the relying party does not have any necessity to contact the monitoring agent. On the other hand, if a

storage token is not provided (Figure 2), the local agent can create only one signature share and send it

along with identity credential. In this case, the relying party can not verify the validity of usersignature, and is then must contact the online monitoring agent. The monitoring agent can make

another signature share and combine them into a complete signature so that the relying party can

verify them with the users public key. The benefits of our approach are discussed in the next section.

Brief Evaluation

SecurityIn our proposing architecture, users private key is only used to generate key shares. This means that it

can be mostly stored in an off-line safe, say a CD-R media. Additionally, the compromise of any

single entity that is assigned a key share does not end up in successful impersonation and identity

misuse by an adversary. Note that even using normal USB drive without encryption capability as astorage token does not jeopardize the security of the system. This feature enables our idea to be

implemented with minimum extra cost.

In case a users device is stolen or compromised, the identity thief can not do anything without being

monitored by a monitoring agent because Local IdA has only one key share, which is insufficient to

convince relying parties. The monitoring agent can have anomalous usage detection functionality

which can not only report the suspicious usage (we use an independent channel for communication

between this agent and a user) but also block the transaction. Once a legitimate user recognize the

problem, the compromised Local IdA can be revoked by re-generating key shares from an original

private key and re-distributing new key shares to a storage token, newly configured user device with

new Local IdA, and the monitoring agent. If users storage token is compromised, an adversary can

use it along with publicly available Local IdA module, assuming it is available online. However, justlike the previous situation, the monitoring agent is involved in a transaction. The compromise of

monitoring agent does not matter because it only has one key share, and an adversary can not

impersonate a user or misuse his/her credential by using it.

Basically, the revocation of Local IdA, a users storage token, and a monitoring agent can be done

without involving a CA that certifies the users public key as long as only one of them is

compromised. This feature shortens the window of vulnerability because updating key shares can bedone immediately whenever the user needs while asking a CA to revoke the certificate takes much

longer time. It is also possible to renew key shares proactively.

User controllable Identity-Usage Monitoring

The monitoring agent is contacted by relying parties with whom the user is talking for completion ofsignature verification. From our assumption, relying parties are motivated to contact the monitoring

agent and do not skip this process. Thus, implementing a monitoring and anomaly detection feature

here is very effective. Even if an adversary would attempt to impersonate a legitimate user with a

compromised device and Local IdA, it will be detected by the monitoring agent.

For the sake of privacy, a user should be able to exercise control over this monitoring feature. In our

architecture, as shown in Figure 1, a user can physically exclude a monitoring agent from identity-related transactions by using a storage token, and identity usage is completely hidden from the


5/5

monitoring agent. On the other hand, when a user does not have the token or wants the transaction to

be monitored, the relying party must contact the monitoring agent. This satisfies the requirements of

user-centric monitoring discussed in our previous work [6].

System Availability and RecoveryFinally, we conclude the evaluation by discussing system availability. We added two new entities to

the underlying architecture. However, none of them is a single point of failure that makes the entire

service unavailable. Even when a users storage token is lost or unavailable, a user can continue using

a service with a monitoring agent. The user loses the ability of not being monitored, but the service

itself continues working. If the monitoring agent is unavailable, the user can exclude the unavailable

agent from a transaction by using a storage token. In addition, the user can recover the disabled entity

by re-generating and re-distributing new key shares to new entities.

The user can continue to use a system when the local device is lost even before re-generating key

shares by downloading a publicly available Local IdA module and using it along with a key share in

the storage token. Since a user might not have an immediate access to the master private key, this

feature would be helpful. Note that, in this case, the users transaction will be monitored anyway,

which is, however, desirable because of the lost user device.

ConclusionIn this paper, we proposed a way to enable users to have more flexible and robust control over identity

agents, including immediate revocation and a user-controlled monitoring feature, by introducing a

storage token and a trusted online monitoring agent. The novelty of our work includes the integration

of threshold signature scheme into identity management area as well as showing a way to implement

user-centric identity usage monitoring based on it. Also, we presented a way to utilize a hardware

token to provide the capability of revocation, recovery, and user-controllable identity usage

monitoring in addition to a second factor of authentication. In addition, though this paper focused on

the setting involving only Local IdA, our architecture fits well not only in identity management

architecture involving Remote IdA but also hybrid setting like GUIDE-ME. We have actually

integrated this idea into GUIDE-ME identity management architecture. As future work, by using thisprototypical implementation, we will conduct a detailed threat analysis and evaluation and furtherimprove our approach.

Reference[1] David Chappel. Introducing Windows CardSpace,

http://msdn.microsoft.com/library/enus/dnlong/html/IntroInfoCard.asp.[2] Tewfiq El Maliki et al., A Survey of User-centric Identity Management Technologies, in

SECUREWARE 2007, 2007.

[3] GUIDE-ME: Georgia Tech User-Centric Identity Management Environment,

http://isis.poly.edu/disw07/presentations/Ahamad%20Poly%20Talk.ppt

[4] V. Shoup. Practical Threshold Signatures, in Proc . of EUROCRYPTO 2000, 2000[5] Credentica U-Prove Technology, http://www.credentica.com/u-prove_sdk.html

[6] Daisuke Mashima and Mustaque Ahamad. Towards User-centricu Identity Usage Monitoring System,

in ICIMP 2008, 2008

Documents

Use Nix Security 08 Poster Proposal