U.S. patent application number 14/900453 was filed with the patent office on 2016-06-02 for a computer implemented method to improve security in authentication/authorization systems and computer programs products thereof.
This patent application is currently assigned to TELEFONICA DIGITAL ESPANA, S.L.U.. The applicant listed for this patent is TELEFONICA DIGITAL ESPANA, S.L.U.. Invention is credited to Jose Maria ALONSO CEBRIAN, David BARROSO BERRUETA, Antonio GUZMAN SACRISTAN, Jose Maria PALAZON ROMERO.
Application Number | 20160156598 14/900453 |
Document ID | / |
Family ID | 52141125 |
Filed Date | 2016-06-02 |
United States Patent
Application |
20160156598 |
Kind Code |
A1 |
ALONSO CEBRIAN; Jose Maria ;
et al. |
June 2, 2016 |
A COMPUTER IMPLEMENTED METHOD TO IMPROVE SECURITY IN
AUTHENTICATION/AUTHORIZATION SYSTEMS AND COMPUTER PROGRAMS PRODUCTS
THEREOF
Abstract
A computer implemented method and computer program products to
improve security in authentication/authorization systems The
computer implemented method comprising controlling the access to
different resources and actions defined for a user by a first
server, reducing the exposure time at which such operations are
available, establishing a dual channel verification through the use
of a second server and a defining a secure channel for certificate
exchange for authentication. The computer programs implement the
method.
Inventors: |
ALONSO CEBRIAN; Jose Maria;
(Madrid, ES) ; BARROSO BERRUETA; David; (Madrid,
ES) ; PALAZON ROMERO; Jose Maria; (Madrid, ES)
; GUZMAN SACRISTAN; Antonio; (Madrid, ES) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
TELEFONICA DIGITAL ESPANA, S.L.U. |
Madrid |
|
ES |
|
|
Assignee: |
TELEFONICA DIGITAL ESPANA,
S.L.U.
Madrid
ES
|
Family ID: |
52141125 |
Appl. No.: |
14/900453 |
Filed: |
June 23, 2014 |
PCT Filed: |
June 23, 2014 |
PCT NO: |
PCT/EP2014/063188 |
371 Date: |
December 21, 2015 |
Current U.S.
Class: |
713/168 |
Current CPC
Class: |
H04L 63/0428 20130101;
H04L 63/10 20130101; H04L 63/0838 20130101; H04L 63/0861
20130101 |
International
Class: |
H04L 29/06 20060101
H04L029/06 |
Foreign Application Data
Date |
Code |
Application Number |
Jun 24, 2013 |
EP |
13382237.9 |
Oct 9, 2013 |
EP |
13382396.3 |
Oct 9, 2013 |
EP |
13382397.1 |
Oct 9, 2013 |
EP |
13382398.9 |
Claims
1-15. (canceled)
16. A computer implemented method to improve security in
authentication/authorization systems, the method comprising:
receiving, by a first server, from a user via a first dedicated
program, a request to be logged into a service of said first
server; and authenticating, by said first server, credentials
information of said user in order to authorize said service login
request, said credentials information comprising information
validating the identity of the user in the first server, the method
comprising: receiving, by a second server, from a second dedicated
program installed in a computing device of said user, configuration
information that the user has established for the operations
provided by the first server; requesting, by the user, once the
service login request being authorized by the first server, to
perform an operation in the first server; receiving, by the second
server, from the first server, a request about an operation status
associated to what said user has established about said requested
operation in order to assist the first server in authorizing or
rejecting the requested operation; and verifying, by the second
server, said operation status previously established by the user
for said requested operation, and in case said operation status
being established as valid by the user, the second server
generating an extra authentication factor mechanism for reinforcing
authorization of said requested operation, wherein said extra
authentication factor mechanism includes a public/private key
encryption process or the use of a public/private key for
generating a digital signature.
17. The computer implemented method of claim 16, wherein said
request performed by the first server to the second server
comprises a credential exchange between the first server and the
second server in order to provide mutual authentication, and the
method comprising the sending, by the second server, of the result
of said operation status to the first server.
18. The computer implemented method of claim 16, wherein said
operation been reinforced with the use of said extra authentication
factor mechanism including a public/private key for generating a
digital signature by means of performing following actions:
generating and sending, by the second server to the second
dedicated program, a one-time password (OTP) that the user is going
to use for setting up the extra authentication factor mechanism;
recovering, by the second dedicated program, a private key of the
user in order to digitally sign the received OTP, said recovering
been performed after the user having decided to sign the received
OTP within the second dedicated program and having stored said
private key in a software or a hardware mechanism of the computing
device; and sending, by the second dedicated program, the digitally
signed OTP to the second server and the digital signature employed,
the latter verifying integrity of the received digitally signed OTP
with the OTP that the second server generated, and integrity of the
private key that was used to perform said signing of the OTP with
an stored user public key that the second server had.
19. The computer implemented method of claim 18, further
comprising: if the private key used to perform the signing of the
OTP matches the user public key stored in the second server,
sending, by the second server to the first server, the result of
said operation status, performed by the first server, along with
the generated OTP; requesting, by the first server, the OTP to the
user, the latter recovering the OTP through the second dedicated
program and further sending it to the first server; and checking,
by the first server, if the OTP received from the second server and
the OTP received from the user matches.
20. The computer implemented method of claim 16, wherein said
requested operation been reinforced with the use of said extra
authentication factor mechanism including a public/private key
encryption process by means of performing, after having sent, by
the second server, the result of said operation status to the first
server including an OTP used by the user for setting up the extra
authentication factor mechanism, the following actions: requesting,
by the first server to the user through an interface, said OTP used
by the user for setting up the extra authentication factor
mechanism; encrypting, by the second server, the OTP with a public
key of the user and sending the encrypted OTP to the second
dedicated program, said public key been previously stored in the
second server by the user; recovering, by the second dedicated
program, a private key of the user and using the private key of the
user to decrypt the received encrypted OTP, said recovering been
performed after the user having stored the private key in a
software or a hardware mechanism of the computing device; sending,
by the second dedicated program, the decrypted OTP to the user, the
latter sending the decrypted OTP via said interface; and checking,
by the first server, if the OTP received from the user and the OTP
received from second server matches.
21. The computer implemented method of claim 16, wherein said
requested operation been reinforced with the use of said extra
authentication factor mechanism including a public/private key
encryption process performed by to the first server by means of
performing, after the second server having sent the result of said
operation status to the first server, the following actions:
generating, by the first server, an OTP that the user is going to
use for setting up the extra authentication factor mechanism;
encrypting, by the first server, the generated OTP with a public
key of the user and further sending the encrypted OTP to the second
server, said public key been previously stored in the first server
by the user; requesting, by the first server to the user through an
interface, the OTP; sending, by the second server, the encrypted
OTP to the second dedicated program installed in the computing
device of the user; recovering, by the second dedicated program, a
private key of the user and using the private key of the user to
decrypt the received encrypted OTP, said recovering been performed
after the user having stored the private key in a software or a
hardware mechanism of the computing device; sending, by the second
dedicated program, the decrypted OTP to the user, the latter
sending the decrypted OTP via said interface; and checking, by the
first server, if the OTP received from the user and its own
generated OTP matches.
22. The computer implemented method of claim 21, wherein the
requesting of the OTP to the user and the sending of the encrypted
OTP to the second dedicated program are performed at the same
time.
23. The computer implemented method of claim 16, wherein said
requested operation been reinforced with the use of said extra
authentication factor mechanism including a public/private key for
generating a digital signature executed by to the first server by
means of performing, after the second server having sent the result
of said operation status to the first server, the following
actions: generating, by the first server, an OTP that the user is
going to use for setting up the extra authentication factor
mechanism and sending the generated OTP to the second server;
requesting, by the first server to the user through an interface,
the OTP; sending, by the second server, the OTP to the second
dedicated program; recovering, by the second dedicated program, a
private key of the user in order to digitally sign the received
OTP, said recovering been performed after the user having decided
to sign the received OTP within the second dedicated program and
having stored said private key in a software or a hardware
mechanism of the computing device; sending, by the second dedicated
program, the digitally signed OTP and the digital signature
employed for the signing to the second server, the latter
forwarding them to the first server; sending, by the second
dedicated program, the digitally signed OTP to the user, the latter
sending the digitally signed OTP via said interface; and checking,
by the first server, if the digitally signed OTP received from the
user and the digitally signed OTP received from the second server
matches.
24. The computer implemented method of claim 23, wherein the second
dedicated program performs both of said sending's, of the digitally
signed OTP and the digital signature employed for the signing to
the second server and of the digitally signed OTP to the user, at
the same time.
25. The computer implemented method of claim 16, wherein the second
server notifies the user if the request to be logged into a service
of said first server is rejected.
26. The computer implemented method of claim 25, wherein said
notification comprises one of a sending of a Short Message Service
(SMS), a sending of an email, a sending of a message by a
smartphone messenger application, a highlighting or pushing in said
second dedicated program of said user computing device.
27. The computer implemented method of claim 16, wherein said
operation status is set as valid or as invalid a certain period of
time.
28. The computer implemented method of claim 16, wherein the
request to be logged into a service of the first server and/or the
request to perform an operation in the first server are recorded in
order to provide statistics.
29. A computer program product, which includes computer program
code instructions that when executed in a computer implement the
steps of the method of claim 16.
30. The computer program product of claim 29, further including
computer program code instructions that when executed in a computer
implement the following: generating and sending, by the second
server to the second dedicated program, a one-time password (OTP)
that the user is going to use for setting up the extra
authentication factor mechanism; recovering, by the second
dedicated program, a private key of the user in order to digitally
sign the received OTP, said recovering been performed after the
user having decided to sign the received OTP within the second
dedicated program and having stored said private key in a software
or a hardware mechanism of the computing device; and sending, by
the second dedicated program, the digitally signed OTP to the
second server and the digital signature employed, the latter
verifying integrity of the received digitally signed OTP with the
OTP that the second server generated, and integrity of the private
key that was used to perform said signing of the OTP with an stored
user public key that the second server had.
Description
FIELD OF THE ART
[0001] The present invention is directed, in general, to
authentication and authorization systems. In particular, the
invention relates to a computer implemented method and computer
program products to improve security in
authentication/authorization systems in which the access to
different resources and actions defined for a given user are
controlled.
BACKGROUND OF THE INVENTION
[0002] In recent years, web fraud detection market has increased
considerably, so innovation in authentication and authorization
processes has become of great importance.
[0003] The increasing complexity of applications has led to the
adoption of many security techniques increasingly sophisticated.
One of the classifications that can be proposed for the study of
these security techniques allows distinguishing between
authentication solutions and authorization solutions. The
authentication techniques are designed to verify a person is the
one who claims to be. In order to add more reliability in verifying
that actually a person corresponds to the identity that is being
checked, many alternative authentication schemes can be taken or
the number of factors to build this authentication can be
extended.
[0004] There are many solutions designed to strengthen the
authentication processes and, by extension, to fortify the
authorization processes. Once users have been securely identified,
there are authorization schemes that allow flexibility and
robustness in assigning permissions to users to ensure secure
access to system resources. However, there are threats which cannot
yet be thwarted by adopting any of the existing schemes for the
authentication/authorization, or this adoption is too expensive to
afford it. These threats directly affect the way the access to
specific resources is performed. A method to address these threats
involves the designing of brand new security mechanisms. These
mechanisms must guarantee that once the identity of a user has been
verified and the level of authorization to a resource for this user
has been checked, the actions taken by the user of that resource
are not intercepted and modified by any attacker.
[0005] In any authorization model different techniques that
facilitate access to various system resources are included. The
user role information, the access control data provided when the
user is authenticated, are examples of information that can be used
to determine whom to give access to what resources and how this
access has to be guaranteed. Ultimately, determining what should be
accessed by the users, will be specified for each application. For
this reason, sometimes it will be difficult to provide a general
authorization scheme. It will be necessary to define an
application-specific logic to determine what users can access and
how they would perform these accesses. From this idea, there are
many solutions that propose secure and flexible schemes for the
implementation of the authorization. In all these solutions, the
security must be guaranteed by the correct selection of the
authentication mechanism and a correct implementation of the
selected authorization scheme.
[0006] Some of the solutions provide flexibility by defining their
own SDK to encourage the use of their schemes for
authentication/authorization. Today, most of the SDK are based on
concepts introduced by OAuth and do not suppose a risk by
themselves. This applies to Microsoft Live Connect, Facebook PHP
SDK and Windows 8 SDK Authentication Broker. If they exist, the
threats should come from a deficient use of these SDK. In fact,
regardless of threats derived by a poor implementation of the
scheme chosen, most of the threats that can be defined on an
authorization system coincide with the threats defined for
authentication systems. This coincidence has to do with the misuse
of the credentials used to manage permissions granting access to
resources [2], [5].
[0007] In [2] four different levels are defined in terms of the
consequences of authentication and authorization errors and misuse
of credentials. Level 1 is the lowest level (the most insecure) and
level 4 is the highest. [0008] Level 1--An attacker can perform
repeated logon trials by guessing possible values of the token
authenticator. An attacker is also able to replay previously
captured messages (between a legitimate user and a verifier) to
authenticate as that user to the verifier. NIST recommends the
usage of a single or multi-factor authentication with no identity
proof in order to provide protection against these online guessing
and replay attacks. [0009] Level 2--An attacker can listen
passively to the authentication protocol to capture information
which can be used in a subsequent active attack to masquerade as
the user. NIST recommends the usage of single or multi-factor
authentication to provide protection against these eavesdropping
attacks and all the attacks from the level 1. [0010] Level 3--The
attacker positions himself or herself in between the user and
verifier so that he or she can intercept and alter the content of
the authentication protocol messages. The attacker typically
impersonates the verifier to the user and simultaneously
impersonates the user to the verifier. Conducting an active
exchange with both parties simultaneously may allow the attacker to
use authentication messages sent by one legitimate party to
successfully authenticate to the other. NIST recommends the usage
of a multi-factor authentication and wide use of OTP. It also
suggests a token used for authentication to be unlocked by the user
using a password or biometrics. Adopting these solutions provides
protection against verifier impersonation attacks, MitM attacks and
the attacks from level 2. [0011] Level 4--An attacker is able to
insert himself or herself between a user and a verifier subsequent
to a successful authentication exchange between the latter two
parties. The attacker is able to pose as a user to the verifier, or
vice versa, to control session data exchange. On the other hand,
the attacker may compromise or otherwise exploit authentication
tokens and may intercept all input or output communications from
the device (Man-in-the-device (MitD) attacks or Man-in-the-Browser
(MitB) attacks). The attacker can do this infecting the system with
malware. NIST suggests the usage of Multi-factor authentication
with FIPS-140-2 certified tamper-resistant hardware (hardware
tokens) [4] to get protection against these session hijacking
attacks and the attacks from the level 3.
[0012] For the first three levels, attacks and existing solutions
are both focused on the way of verifying the user's identity. At
level 4, NIST proposes the use of solutions against session
hijacking and others attacks over authentication processes. This
session hijacking involves an attacker takes advantage of the
legitimate exchange of credentials that a user makes to comply with
the authentication process. Once this validation is accomplished,
the attacker then intervenes in the communication that takes place.
This type of attack can be implemented in two ways: actively
acting, hijacking the connection and leaving out of it to the
legitimate user, or, remaining hidden and modifying the content of
communication transparently to the user. Whatever the
implementation of this attack, it is important to observe that this
is an attack aimed at breaking the authorization system, leaving
intact, though useless, the authentication system. Although there
are alternatives to proactively protect systems from this threat,
there is no adequate solution to mitigate the effects of the attack
once the device from which the resource access is requested, is
committed.
[0013] NIST suggests employing FIPS-140-2 certified
tamper-resistant hardware (hardware tokens) [4]. Using these
devices provides the users the ability to generate a single use
password (one time password, OTP) to prove their identity to each
transaction. In addition, there are hardware implementations of
these tokens that can generate other OTPs coded to contain
information on how to complete a specific transaction.
[0014] Different criteria can be defined to establish comparison
between authentication/authorization schemes. In [1] the authors
suggest the need to define three criteria in order to perform an
effective comparison. These aspects are: security, usability and
complexity on implementation (deployability). This paper presents
an intensive study to instrument the comparison through the
definition of metrics.
[0015] Following table summarizes the metrics defined for each
criterion.
TABLE-US-00001 Usability Memory-Effortless Scalable-for-Users
Nothing-to-Carry Physical-Effortless Easy-to-Learn Efficient-to-Use
Infrequent-Errors Easy-recovery-from-Loss Deployability Accessible
Negligible-Cost-per-User Server-Compatible Browser-Compatible
Mature Non-Proprietary Security Resilient-to-Physical-Observation
Resilient-to-Targeted-Impersonation Resilient-to-Throttled-Guessing
Resilient-to-Unthrottled-Guessing Resilient-to-Internal-Observation
Resilient-to-Leaks-from-Other-Verifiers Resilient-to-Phishing
Resilient-to-Theft No-Trusted-third-Party
Requiring-Explicit-Consent Unlikable
[0016] In the case of security criterion, the proposed metric set
summarizes all the aspects that are usually estimated in defining a
threat model. In the definition of these models it is necessary to
adopt a number of decisions. And these decisions define the working
scenario. For example in the case of OAuth 2.0 [5] the adopted
assumptions are as follows: [0017] The attacker has full access to
the network between the client and authorization servers and the
client and the resource server, respectively. The attacker may
eavesdrop on any communications between those parties. He is not
assumed to have access to communication between the authorization
server and resource server. [0018] An attacker has unlimited
resources to organize an attack. [0019] Two of the three parties
involved in the OAuth protocol may collude to mount an attack
against the third party. For example, the client and authorization
server may be under control of an attacker and collude to trick a
user to gain access to resources.
[0020] Attending to the metrics introduced above, is possible to
determine that solutions corresponding to the higher security level
(level 4) have poor performance in deployability and usability.
Once the assessment of a system allows to determine in which level
has to be deployed its authentication system, it is needed to
evaluate if the users are authenticated safely and correctly.
Although there are some tools that aid in this task [3], [6],
deploys in the level 4 are difficult to evaluate correctly. In
terms of usability, the use of tampering resistant hardware tokens
goes against the adoption of these solutions by users, and it has
been proved that this situation leads to a misuse of the credential
systems. These tokens are expensive. They are independent devices
that the user has to custody and that can be employed with one
service provider only. If the users have to deal with more than one
service provider that has adopted these tampering resistant
hardware tokens, they have to take into custody as many tokens as
service providers they have.
[0021] Furthermore, in terms of authorization, in [7] the authors
explain that, aside from some security issues of each SDK,
developers who choose to integrate with one of them make
assumptions that can lead to security problems. This is because
SDKs are often not well documented and the security exploits nearly
always stem from attackers who find ways to violate these
assumptions system implementers relied upon.
[0022] Along with these difficulties, other problems must be
considered to understand the constant increase in fraud arising
from the theft of digital identities. For instance, it is not
possible to measure a homogeneous security level in all users'
digital accounts. It is needed a solution that can equalize the
security level of all digital accounts that a user owns. This
solution should extend this security not only to the authentication
processes but also to the resource authorization processes and all
procedures related to such accounts.
[0023] Apart from problems derived from the authorization solutions
adoption, the most extended solution for authentication, the usage
of personal digital certificates, has also many problems that
usually have led to a very poor adoption in most systems,
especially when they have to provide services to a wide number of
clients. For instance, by the user side some of these problems are:
[0024] Valid digital certificate possession. Not all users have to
have a valid digital certificate. And, in addition, this
certificate may not be used in processes related to authentication.
This problem is solved if there is a government program aimed at
issuing digital certificates with the identity of its citizens
(citizen cards, etc. . . . ) [0025] Digital certificate storage by
users. These certificates can be stored in the computer, but this
solution limits its use to a single machine. By other hand, they
can also be stored on a smartcard. In this case, the limitation to
a single computer is beaten to reach all those computers that have
a compatible smartcard reader. [0026] Latency. The processes
associated with the implementations of the authentication
mechanisms cause always an overhead over the time to authenticate a
user. [0027] Secure environment to execute cryptographic procedures
over these digital certificates.
[0028] By the service provider side, the problems rise according
with the cost of maintaining a Public Key Infrastructure (PKI)
infrastructure that always add complexity to the system
functionality. However, regardless of these problems, the use of
the certificates to authenticate a user is a very robust process
that normally involves two steps. First, the issuer entity must
associate a user identity with a public key in a safe way.
Secondly, a mechanism that allows exploiting the use of
cryptographic protocols to verify a user's identity has to be
proposed. These two phases should be performed independently using
trustable channels.
[0029] When the use of these digital certificates is employed to
certify the identity of a user computing mobile device there are
three different possibilities to store the private information of
the certificate and to perform securely the corresponding
cryptographic processes: use a pure-software solution to store the
private key and let the microprocessor of the computing device
perform the cryptographic procedures; use a hardware container
(e.g. the SIM of a mobile phone) to securely store and execute the
cryptographic procedures without using the computation resources
provided by the computing device; or employ a smart-card technology
that relies on an external device to store and execute the
cryptographic procedures, forcing to design and implement a
compatible port to access this device.
[0030] Therefore, a different approach is needed to improve the
overall security in the authentication/authorization systems,
whatever is the scheme or schemes adopted, minimizing the impact on
the usability and deployability of these systems.
REFERENCES
[0031] [1] Bonneau, J., Herley, C., van Oorschot, P. C., &
Stajano, F. (2012, May). The quest to replace passwords: A
framework for comparative evaluation of web authentication schemes.
In Security and Privacy (SP), 2012 IEEE Symposium on (pp. 553-567).
IEEE. [0032] [2] Burr, W. E., Dodson, D. F., & Polk, W. T.
(2006). Electronic authentication guideline. NIST Special
Publication, 800, 63. [0033] [3] Dalton, M., Kozyrakis, C., and
Zeldovich, N., Nemesis: Preventing Authentication & Access
Control Vulnerabilities in Web Application, In Proceedings of the
18th conference on USENIX security symposium, (pp. 267-282) USENIX
Association. [0034] [4] Evans, D., Bond, P., Bement, A., Security
Requirements for Cryptographic Modules, FIPS PUB 140-2--FEDERAL
INFORMATION PROCESSING STANDARDS PUBLICATION. Online Resource:
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
[0035] [5] McGloin M. & Hunt P. (2013, January) OAuth 2.0
Threat Model and Security Considerations. ISSN: 2070-1721. Online
resource: http://tools.ietf.org/pdf/rfc6819.pdf. [0036] [6] Sun,
F., Xu, L., & SU,Z. (2011,August) Static detection of Access
control vulnerability in web applications. In Proceedings of the
20.sup.th USENIX conference on Security (pp. 11-11). USENIX. [0037]
[7] Wang, R., Zhou, Y., Chen, S., Qadeer, S., Evans, D., &
Gurevich, Y. (2013). Explicating SDKs: Uncovering Assumptions
Underlying Secure Authentication and Authorization (Vol. 37).
Microsoft Research Technical Report MSR-TR-2013.
DESCRIPTION OF THE INVENTION
[0038] To achieve the above, the invention provides in a first
aspect a computer implemented method to improve security in
authentication/authorization systems, which comprises: receiving, a
first server, from a user having a computing device, a request to
be logged into a service of said first server; and authenticating,
said first server, credentials information of said user in order to
authorize said service request.
[0039] In a characteristic manner and on contrary of the known
proposals, the computer implemented method of the first aspect
further comprises the use of a second server, in connection with
said user computing device that has installed therein a dedicated
program, for receiving from the first server a first request about
a status associated to said user in order to assist the first
server in authorizing or rejecting the requested service logging,
and in case said requested service logging being authorized, and a
request is done by the user to perform an operation in the first
server, the second server receiving from the first server a second
request about a status that the user has set for said operation and
evaluating said operation status to check if the first server being
allowed to access the user configuration for said operation. In
case the recovered operation status is set as valid, an extra
authentication factor mechanism for reinforcing said operation is
used, said extra authentication factor mechanism including the use
of a public/private key encryption process or the use of a
public/private key for generating a digital signature.
[0040] In accordance with the invention, the first request
performed by the first server comprises: a credential exchange
between the first server and the second server in order to provide
mutual authentication; verification, by the second server, of said
associated status of the user, said associated status been
previously set as valid or as invalid by said user and stored in a
memory of the second server; and the sending, by the second server,
of the associated status of the user to the first server.
[0041] The credentials exchange to secure mutual authentication
between the first server and the second server, is performed,
preferably, via a standard authentication procedure based on
certificates' exchange defining, as a result, a secured channel.
The exchange is performed to verify that both first server and
second server are who they claim to be.
[0042] The second server may notify the user in case said request
to be logged into a service of the first server is rejected. For
instance, by the sending of a Short Message Service (SMS), of an
email, of or a message by a smartphone messenger application, or
just by the highlighting or pushing in said dedicated program of
said user computing device.
[0043] The associated status is set as valid (unlocked) or as
invalid (locked) a certain period of time and can be modifiable by
the user whenever the latter want it. For instance, the user can
plan a locking/unlocking policy to automate the management of their
accounts held with different servers using different criteria:
time, geolocation (different policies for home, work, etc.).
Another possibility for modifying said associated status can be by
delegating the control said user has of their accounts to other
users. This can be done by considering two different options. In
the first one, a parental control mechanism is used so the
children's (original) accounts access control is delegated to the
parent control mechanism. In the second one, a single account
allows multiple locks. In this latter case, the unlock action will
require that multiple users unlock their locks concurrently. In
both cases, the delegation is performed securely maintaining the
privacy of every user unchanged.
[0044] In addition, the request to be logged into a service and/or
the request to perform an operation may be recorded in order to
provide statistics. In this way, the user can obtain system usage
statistics that reflect activity of the system and track the
attempts of impersonation. These statistics inform about when
someone had attempted to access to a service with user's
username.
[0045] In accordance with an embodiment, the solution previously
proposed to provide the extra authentication factor mechanism is
extended with the use of a public/private key for generating a
digital signature by means of: generating and sending, the second
server to the dedicated program, a one-time password (OTP) that the
user is going to use for setting up the extra authentication factor
mechanism; recovering, the dedicated program, a private key of the
user in order to digitally sign the received OTP, said recovering
been performed after the user having decided to sign the received
OTP within the dedicated program and having stored said private key
in a software or a hardware mechanism of the computing device; and
sending, the dedicated program, the digitally signed OTP to the
second server and the digital signature employed, the latter
verifying integrity of the received digitally signed OTP with the
OTP that the second server generated, and integrity of the private
key that was used to perform said signing of the OTP with an stored
user public key that the second server (200) had.
[0046] In addition, if the private key used to perform the signing
of the OTP matches the user public key stored in the second server,
the second server sends to the first server the result of said
operation status request, performed by the first server, along with
the generated OTP; then, the first server request the OTP to the
user, the latter recovering the OTP through the dedicated program
that further sends it to the first server; finally, the first
server checks if the OTP received from the second server and the
OTP received from the user matches.
[0047] In accordance with another embodiment, the solution proposed
to provide the extra authentication factor mechanism is extended by
the usage of a public/private key encryption process. This is
achieved by means of performing, after having sent the second
server the result of said operation status request to the first
server including an OTP used by the user for setting up the extra
authentication factor mechanism, the following actions: requesting,
the first server to the user through an interface, said OTP used by
the user for setting up the extra authentication factor mechanism;
encrypting, the second server, the OTP with a public key of the
user and sending the encrypted OTP to the dedicated program, said
public key been previously stored in the second server by the user;
recovering, the dedicated program, a private key of the user and
using the private key of the user to decrypt the received encrypted
OTP, said recovering been performed after the user having stored
the private key in a software or a hardware mechanism of the
computing device; sending, the dedicated program, the decrypted OTP
to the user, the latter sending the decrypted OTP via said
interface; and checking, the first server, if the OTP received from
the user and the OTP received from second server matches.
[0048] In accordance with another embodiment, the solution proposed
to provide the extra authentication factor mechanism is extended
with the use of a public/private key encryption process. The
public/private key encryption process is performed by the first
server by means of executing, after the second server having sent
the result of said operation status request to the first server,
the following actions: first generates an OTP that the user is
going to use for setting up the extra authentication factor
mechanism; then encrypts the generated OTP with a public key of the
user and further sends the encrypted OTP to the second server, said
public key been previously stored in the first server by the user;
and after that requests to the user through an interface, the OTP;
at that time the second server sends the encrypted OTP to the
dedicated program which recovers a private key of the user and uses
the private key of the user to decrypt the received encrypted OTP,
said recovering been performed after the user having stored the
private key in a software or a hardware mechanism of the computing
device; finally the dedicated program sends the decrypted OTP to
the user that sends the decrypted OTP via said interface to the
first server, so that the first server can check if the OTP
received from the user and its own generated OTP matches.
[0049] The requesting of the OTP to the user and the sending of the
encrypted OTP to the dedicated program in this embodiment are
preferably performed at the same time.
[0050] In accordance with yet another embodiment, the solution
proposed to provide the extra authentication factor mechanism is
extended with the usage of a public/private key for generating a
digital signature by means of performing, after the second server
having sent the result of said operation status request to the
first server, the following actions: first, the first server
generates an OTP that the user is going to use for setting up the
extra authentication factor mechanism and sends the generated OTP
to the second server; after that, the first server requests the
user through an interface the OTP and the second server sends the
OTP to the dedicated program; the dedicated program then recovers a
private key of the user in order to digitally sign the received
OTP, said recovering been performed after the user having decided
to sign the received OTP within the dedicated program and having
stored said private key in a software or a hardware mechanism of
the computing device, and sends the digitally signed OTP and the
digital signature employed for the signing to the second server
which forwards the received information to the first server;
preferably, at the same time of the sending of the digitally signed
OTP and the digital signature employed for the signing to the
second server, the dedicated program also sends the digitally
signed OTP to the user that can then send to the first server the
digitally signed OTP via said interface; finally, the first server
checks if the digitally signed OTP received from the user and the
digitally signed OTP received from the second server matches.
[0051] The subject matter described herein can be implemented in
software in combination with hardware and/or firmware, or a
suitable combination of them. For example, the subject matter
described herein can be implemented in software executed by a
processor.
[0052] According to a second aspect there is provided a computer
program comprising computer program code means adapted to perform
the steps according to the computer implemented method of the first
aspect of the invention when said program is run on a computer, a
digital signal processor, a field-programmable gate array, an
application-specific integrated circuit, a micro-processor, a
micro-controller, or any other form of programmable hardware.
[0053] Embodiments of the invention also comprise a computer
program product including program code means adapted to perform
other embodiments of the invention according to the methods of
claim 3, 4, 5, 6 or 8.
[0054] The present invention allows the user to plan a
locking/unlocking policy to automate the management of accounts
held with different servers using different criteria: time,
geo-localization (different policies for home, work, etc.);
delegate the control of their accounts to other said second server
users; enable monitoring systems that allow users to be warned of
identity theft attempts or untrue user's impersonation in operation
execution requests, providing a course of action to take action to
control the digital identity; establish a second factor for
authentication for verifiers that are not providing it; establish
an account to be blocked or unblocked and change it with immediate
effect by the use of a switch control; fix a schedule to
Valid/Invalid (unlocked/locked) an account or said operation
automatically based on time and date settings. Once a check-status
request is received the second server responds based on the current
state of the scheduler; improve the security level of an account or
said operation by configuring a second factor authentication
integrated with second server; control different actions associated
with an account, authorizing or banning the execution of them in a
compatible manner with the authorization scheme established.
[0055] Furthermore, the invention allows homogenizing the security
level for all the different accounts a user has. It allows offering
a security level comparable with level 4 defined by NIST. And this
is done for different accounts that can be now controlled with only
one device and regardless of the authentication/authorization
scheme defined for every service provider.
[0056] The invention does not propose any new
authentication/authorization scheme. Indeed, the intention is to
complement the existent schemes with an extra security layer.
Although this may limit its usability and deployability, the
invention design is oriented to minimize the impact over these
criteria. As it is stated before, the authentication scheme choice
determinates the security risk that is assumed for an authorization
system. What is proposed here is to reduce the risk taken with the
choice of any authentication/authorization mechanism reducing the
time in which this system is accessible to be broken.
[0057] Assuming that there is a relationship between the success
and failure of an attack on the auth system with the time in which
this system is accessible (exposure time) as conditional
probability (p (SuccessfulAttack I exposed)) is possible
determining that the relative risk (RR) satisfies the following
expression:
RR = p ( SuccessfulAttack exposed ) p ( SuccessfulAttack unexposed
) > 1 Eq . 1 ##EQU00001##
[0058] In this expression it is assumed that the probability of
success of an attack is directly related to the exposure time. That
is, the continuous exposure of a computer system, in this case the
authentication system, increases the likelihood of success of an
attack in contrast with a scenario in which the exposure is
limited. In the same way one can evaluate the following
expression:
p ( successfulAttack exposed ) p ( FailedAttack exposed ) p (
SuccessfulAttack un exposed ) p ( FailedAttack unexposed ) > 1
Eq . 2 ##EQU00002##
[0059] Indicating that there is a greater probability for a
successful attack if exists a continued systems exposure. It is
also possible to estimate the portion of all successful attacks
that could have been avoided if the exposure had been avoided
(Attributable Risk Percent (ARP)). This is calculated with
expression 3.
ARP = RR - 1 RR Eq . 3 ##EQU00003##
[0060] This expression allows assessing the investment required to
enable a solution designed to reduce the time that is accessible
authentication process. The professional experience and technical
knowledge of the documented attack techniques to break
authentication/authorization systems confirm the assumption made
earlier (RR>1).
[0061] This reduction in the exposure time allows mitigating the
effects of most of the threats related with the authentication
phase before a user can access to some privileged resources. This
invention also permits reducing the exposure of particular actions
that can be taken after the login process has been accomplished.
Therefore, this exposure reduction supposes the limitation in the
time in what the action can be executed and the establishment of a
channel that allow to send critical information to assure the
integrity of this action execution.
[0062] The invention encompasses the solutions for the threats
defined by NIST. But, in this case, these solutions are provided to
users through a dedicated program designed to be executed in a
mobile device, which facilitates the interaction with a second
server. In addition, this second server brings privacy in the
communications relative to the control of the user's accounts and
incorporates all the control information that the users have set
about the actions the service providers have offered them.
BRIEF DESCRIPTION OF THE DRAWINGS
[0063] The previous and other advantages and features will be more
deeply understood from the following detailed description of
embodiments, with reference to the attached, which must be
considered in an illustrative and non-limiting manner, in
which:
[0064] FIG. 1 is an illustration of the present invention general
architecture.
[0065] FIG. 2 is a flow diagram illustrating an account pairing
sequence with authorization.
[0066] FIG. 3 is a flow diagram illustrating how a status of a user
account can be checked for authentication.
[0067] FIG. 4 illustrates the embodiment in which the accuracy of
the extra authentication factor solution for a service provider
that does not implement a PKI is increased based on a
public/private key encryption process.
[0068] FIG. 5 illustrates the embodiment in which the accuracy of
the extra authentication factor solution for a service provider
that does not implement a PKI is increased based on digital
cryptographic signature.
[0069] FIG. 6 illustrates the embodiment in which the accuracy of
the extra authentication factor solution for a service provider
that implements a PKI is increased based on a public/private key
encryption process.
[0070] FIG. 7 illustrates the embodiment in which the accuracy of
the extra authentication factor solution for a service provider
that implements a PKI is increased based on digital cryptographic
signature.
DETAILED DESCRIPTION OF SEVERAL EMBODIMENTS
[0071] In reference to FIG. 1 it is showed the general architecture
of the present invention. Concerning FIG. 1, a user computing
device 100 such as a mobile phone, a smartphone, a tablet-PC or a
PDA among any other, is used by said user in order to login into a
dedicated program 102 in communication with a second server 200 and
to manage the status for every first server 300 with which a user
wants to request a service.
[0072] With this new proposal said user 100 can unblock said
operation defined for a particular account created with said first
server 300. As stated below, this action can enhance the control
defined for this account by decision of the first server 300. In
this decision, the first server 300 can choose to incorporate a new
control of security beyond the block/unblock default option or
second authentication factor mechanism. This control of security
consists of to provide a communication channel from the user 100 to
the first server 300, through the second server 200. The first
server 300 can configure the system to ask the user 100 for a
particular information related to said operation to be performed.
This information can be used by the second server 200 to verify if
the user 100 is who actually is demanding said operation and to
confirm if the operation that has arrived to the first server 300
is exactly as the one the user 100 had ordered.
[0073] Assuming that the first server 300 could want to verify the
integrity of the operation, it can be selected what parameters are
critical to ensure the operation integrity. In this case, it is
important that the requested information corresponds univocally
with the operation critical parameter in order to identify it
correctly.
[0074] In this architecture, the user 100, besides having an
account in the second server 200, can have multiple accounts with
different service providers. One of these service providers is the
first server 300. Once the user 100 completes the login process
with these accounts he or she will have access to multiple
operations specific to each service providers. The second server
200 eases how a first server 300 can integrate this control within
the logic of its applications.
[0075] When a first server 300 decides to integrate its services,
it will provide the ability to link their accounts with the
accounts that the user 100 has in the second server 200. When the
user 100 decides to establish this link, she or he starts a pairing
process that ensures complete privacy to the user 100. Once the
pairing process is completed, the user 100 can access the
configuration of the control of the account with the first server
300 from a dedicated program 102 (i.e. a mobile application).
[0076] Every time the settings associated with an account are
changed on said mobile application or dedicated program 102, this
modification is immediately propagated to the second server 200 to
change the status of the account that can be accessed by the first
server 300.
[0077] Second server core implements the main function of the
second server 200: lock or unlock said user account with the first
server 300 and the operations provided by first server 300. In
order to do that, the second server 200 accepts and processes the
check-status requests sent from the first server 300. This second
server 200 also manages all data about the links with said first
server 300 defined by the user 100 and the requests for the pairing
of new locks. The key is the user 100 is never asked for any
private information. Once the user 100 creates his account with
second server 200, he can establish locks with different service
providers, like said first server 300. To activate these locks the
second server 200, according to an embodiment, generates a token. A
unique token and the definition of secured channels are needed to
complete the pairing process between the user 100 and the first
server 300. As result of this pairing process, the cryptographic
token is sent from the second server 200 to the first server 300
who has to store this information with their user's personal data.
Later, this cryptographic token will be used to request the
corresponding lock status. The user 100 can modify the status of
their locks, by the activation or configuration of the different
options that second server 200 provides.
[0078] In case the user 100 has set up a lock with a second (or
extra) authentication factor mechanism over an account or a
particular action, the second server 200 will incorporate all the
needed logic for the generation and communication of the OTP. When
the second server 200 receives a request from the first server 300
asking for the user account status, a second authentication factor
is triggered. An OTP is generated and sent to the user 100. The
same OTP is sent to the first server 300 along with the account
status. If the status is ON and the user 100 has activated the
second factor, the first server 300 should prompt the user to
introduce the OTP to proceed with the operation.
[0079] Now, if the user 100 has set up a lock over a said operation
with an integrity factor to verify that the operation parameters
have not been modified, said second server 200 incorporates the
needed logic to get the critical information from the user 100 and
from the first server 300 and to check if both are equal. The
second server 200 sends the result of the checking as the account
status to the first server 300. In case of mismatching, the first
server 300 can conclude that an intruder can be intercepting the
information from the user 100. The first server 300 can then build
mechanisms to elude the fraud and to raise security alerts.
[0080] In reference to FIG. 2 it is illustrated a pairing process
of the user 100 account of the second server 200 with different
accounts for different first servers 300. In FIG. 2, once a user
100, using for instance the dedicated program 101 such as a
browser, has completed the login process (A-B) with a first server
300 (in this particular case a Bank online, a social network, a
credit card providers, etc.), the user 100 decides to perform said
accounts' pairing process. The user 100 requests the pairing to the
first server 300 (C) using the browser 101. As response, the first
server 300 asks for a pairing token (D). The user 100 then uses the
dedicated program 102 (D') to get this pairing token from the
second server 200, after a previous login process. The second
server 200 generates a token (for instance as an OTP) (E) and sends
it to the user's dedicated program 102 (F). This token can be used
for several pairing processes meanwhile it is valid. The user get
the token (OTP) from the dedicated program 102 and introduces it in
the web page displayed in the browser 101 by the first server 300
(G-G'). The first server 300 then sends the received token to the
second server 200, after a previous credentials exchange (H). If
the first server 300 identity is validated, the second server 200
stores the link between the user 100 and the first server 300 and
generates a new token that identifies this link. This token
(accountID) is sent to the first server 300 (I) and there it is
stored for future communications (J). At last, a pairing
acknowledges is sent to the user's browser 101 (K).
[0081] In reference now to FIG. 3 it is illustrated how a status of
a user account can be checked for authentication. In FIG. 3, a user
100, using for example a browser 101, requests to be logged in a
service (A) of a first server 300 so once user existence has been
validated (B) by said first server 300, the latter demands to the
second server 200 the user account status (C). Then the second
server 200 initializes the credentials exchange before the result
of the account status information is sent (D). With the result
status, the first server 300 makes the decision of allowing or
blocking the user access (E).
[0082] In an embodiment, if the account status is unlocked or valid
but the second authentication factor is on, within the answer of
the status request, the second server 200 sends an OTP to the first
server 300 that has to employ to complete the authentication. The
first server 300 then requests to the user 100 the OTP that is
going to be a temporal second factor (F). Then the second server
200 sends the same OTP to the to the user's dedicated program 102
(G). The user 100 recovers the OTP from the dedicated program 102
and introduces it in the browser 101 (H) and sends it to the first
server 300 (I). The first server 300 can check if the OTP sent
through the browser 101 matches with the one received with the
account status (J). Depending on of the results of this
verification, the first server performs the authentication process
(K) and communicates the result to the user via 101.
[0083] When a first server 300 sends a Status Request, the second
server 200 understands that someone, with the proper service
identification information (i.e. ID and password), is trying to
access to the service. If the account status is set as blocked, or
if this request has come in a moment that is not included in the
interval defined by the user 100, the second server 200 registers
this event as a fake attempt. The second server 200 could send,
according to an embodiment, an alert of this event to the user if
said user has configured it so (for instance by sending a Short
Message Service (SMS), an email, a message by a smartphone
messenger application, by a highlighting or pushing in said
dedicated program 102 of said user computing device 100, etc.) or
just update the statistics for a later revision. Then the second
server 200 returns the status associated with the account as
locked.
[0084] With the aim of improving the security of any
authentication/authorization system, the use of the said second
server 200 is proposed as a new layer that gives the users the
chance of control the access to the resources and procedures
associated with their accounts defined with any first servers.
These resources and procedures are seen as operations which depend
on the main actions defined for an account (i.e. login process).
This dependency is established like a hierarchy where the changes
in the root entries are propagated to their children.
[0085] Moreover, a secure channel for certificate exchange in order
to improve authentication is also proposed. Therefore, instead of
having to configure a process to verify the usage of a digital
certificate by legitimate user (e.g. configuration of a smartcard
reader) for each of the computers from which access is desired,
said user just has to use the dedicated program 102 in
communication with the second server 200 to do it. Two different
scenarios are proposed: first, it is considered a scenario in which
the first server 300 is unable or has decided not to implement a
Public Key Infrastructure (PKI) within its organization. In this
case, the present invention not only provides a solution to unify
the interfaces that the user 100 has to employ to introduce her/his
private key and operate with it. In addition, it releases the first
server 300 from the responsibility of implement and support a PKI.
The second scenario proposed gives response for those service
providers that do not want to rely on a third party to manage their
PKI.
[0086] FIG. 4 illustrates an embodiment in which the accuracy of
the extra authentication factor mechanism is increased based on a
public/private key encryption process to demonstrate that the user,
who is demanding an operation, has one of the next alternatives: a
private key of a digital certificate, an specific computing mobile
device with a private/public system built-in or a physical token
that provides all the necessary to perform cryptographic procedures
in a secure way (e.g. smartcard used as citizen card). The extra
authentication factor mechanism assures that the user who is
demanding the execution of a particular operation is, also, in
possession of the legitimate user's credentials to access to the
second server 200.
[0087] Therefore, once the user 100 has requested an operation (A)
and has exchanged the credentials that authenticate her/him for the
first server 300 (B), the first server 300 determines which ID
allows to identify this operation for this user 100 (C) to the
second server 200 and performs an operation status request to said
second server 200 to retrieve the status that the legitimate user
100 has set, through the second server 200 (D), for said operation.
Then, the second server 200 checks if the first server 300 is
allowed to access to the configuration that the user 100 has
established to the particular operation and recover the status (E)
that can be on or off. This information can, also, indicate if the
corresponding operation is reinforced with said extra
authentication factor. In this embodiment, this extra
authentication factor is, in addition, hardened with the usage of a
digital certificate. So, based on encryption, it validates that the
user 100, who is in possession of the credentials with the second
server 200 and who knows the private key of the legitimate user,
can provide them at the moment when the operation is requested.
[0088] At that time, the second server 200 sends the information
related with the status to the first server 300 (F), where it has
been included the token used as OTP. While the first server 300
requests the OTP to the user 100 (G), the second server 200 uses
the public key information previously stored by the user 100 to
encrypt the OTP (H) and sends it to the user's dedicated program
102 (I). Within the device, and depending of the alternative chosen
to store the user's private key (a pure-software solution, a
hardware container or a smart-card technology) and operate with it,
the solution retrieves this private key (J), decrypts the OTP (K)
and allows the user 100 to enter it in the interface that the first
server 300 has employed for demand this token (L). Once this token
has been sent to the first server 300 (M), it is possible to
determine if it matches with the token received from the second
server 200 (N). If both tokens are the same, then the first server
300 can assume that the user who is demanding an operation could
correspond with the user, who has decrypted the OTP, has sent it
and, consequently, is in possession of the private key of the
digital certificate stored by the second server 200.
[0089] FIG. 5 illustrates an embodiment in which the accuracy of
the extra authentication factor solution is increased by the usage
of a public/private key to digitally sign an authentication token
to show that the user 100 who is demanding an operation is in
possession of the private key of a certificate, an specific mobile
device with the private information built inside or a physical
token guarding this private information (e.g. smartcard used as
citizen card). Therefore, in this embodiment, the first server 300
is absolved from the responsibility of incorporating or supporting
any public key infrastructure.
[0090] Once the user 100 has requested an operation (A) and has
exchanged the credentials that authenticate her/him for said first
server 300 (B), the first server 300 determines which ID allows to
identify this operation for this user 100 (C) to said second server
200 and performs an status request to the second server to retrieve
the status that the legitimate user has set, through the second
server 200 (D), for said operation. The second server 200 checks if
the first server 300 is allowed to access to the configuration that
the user 100 has established to the particular operation and
recover the status (E) that can be on or off. This information can,
also, indicate if the corresponding operation is reinforced with
the extra authentication factor. In this embodiment, this extra
authentication factor is, in addition, hardened with the usage of a
digital certificate. So, based on a digital signature mechanism, it
validates that the user 100, who is in possession of the
credentials with the second server 200 and who knows the private
key of the legitimate user, can provide them at the moment when the
operation is requested.
[0091] Therefore, and in difference with other embodiments, before
sending the operation status to the first server 300, an exchange
of information is initialized if the second server 200 detects that
said operation is configured with the extra authentication factor
reinforced with digital signature. First, the first server 300
generates and sends an OTP as token for this extra factor mechanism
to the dedicated program 102 (F). With this OTP, if it is needed,
some information about the operation can be attached. This way, the
user can decide sign or not sign the OTP received taking into
consideration this information. If the user 100 has decided to
sign, within the computing device and depending of the alternative
chosen to store the user's private key and operate with it, the
solution retrieves this private key (G), compute the signature for
this OTP (H) and it re-sends the OTP along with the signature to
the second server 200 (I). Then the second server 200 verifies if
the OTP is the same that was sent (J) and verifies, also, the
signature (K). For this verification, the second server 200
previously must have stored the legitimate user's public key. If it
is a valid signature then the second server 200 sends the status to
the first server 300 (L). Along with the status information, the
same OTP used to authenticate the user 100 is sent to the first
server 300. In fact, this is an OTP verified. So, when the first
server 300 requests the OTP to the user 100 (M) and verifies that
the user 100 sends the same OTP (O and P), at least, it can be sure
that the user 100 who requests the operation is in possession of
the legitimate user's credentials for the second server 200 and
that this user 100 also custodies the private key of the digital
certificate. If the signature received by the second server 200 is
not valid, then the second server 200 returns an OFF status for the
operation (Q) and the first server 300 could decide to deny its
execution (R).
[0092] FIG. 6 illustrates an embodiment in which the accuracy of
the extra authentication factor mechanism is increased based on a
public/private key encryption process to demonstrate that the user
who is demanding an operation is in possession of the private key
of a certificate, an specific computing mobile device with a
private/public system built-in or a physical token that provides
all the necessary to perform cryptographic procedures in a secure
way (e.g. smartcard used as citizen card). In this case, the
solution is provided in view of the fact that the first server 300
assumes the responsibility of incorporating or supporting a public
key infrastructure.
[0093] Once the user 100 has requested an operation (A) and has
exchanged the credentials that authenticate her/him for the first
server (B) 300, the first server 300 determines which ID allows to
identify this operation for this user (C) to the second server 200
and performs an status request to the said second server to
retrieve the status that the legitimate user has set, through the
second server 200 (D), for said operation. The second server 200
checks if the first server 300 is allowed to access to the
configuration that the user 100 has established to the particular
operation and recover the status (E) that can be on or off. This
information can, also, indicate if the corresponding operation is
reinforced with the extra authentication factor. In this
embodiment, this extra authentication factor is, in addition,
hardened with the usage of a digital certificate. So, based on
encryption, it validates that the user 100, who is in possession of
the credentials with the second server 200 and who knows the
private key of the legitimate user 100, can provide
them--credentials and private key--at the moment when the operation
is requested.
[0094] The second server 200 then sends the information related
with the status to the first server 300 (F), but, in difference
with other embodiments, now the OTP is not generated by the second
server 200. Instead of that, it is the first server 300 which
generates it and, using user's public key information, previously
stored, encrypts it (G) and sends it to the second server 200 (H).
Here the second server 200 plays the role of secure channel just
making easy and secure the exchange of information. So, while the
first server 300 requests the OTP to the user 100 (J), the second
server 200 sends the encrypted OTP to the dedicated program 102
(I). The dedicated program 102 receives the ciphered information
and, depending of the alternative chosen to store the user's
private key and operate with it, the solution retrieves this
private key (K), decrypts the OTP (L) and allows the user 100 to
enter it in the interface that the first server 300 have employed
for demand this token (M). Once this token has been sent to the
first server 300 (N), it is possible to determine if it matches
with the token received from the second server 200 (O). If both
tokens are the same, then the first server 300 can assume that the
user 100 who is demanding an operation could correspond with the
user 100 who has decrypted the OTP, has sent it and, consequently,
is in possession of the private key of the digital certificate
stored by the first server 300.
[0095] FIG. 7 illustrates an embodiment in which the accuracy of
the extra authentication factor mechanism is increased by the usage
of a public/private key to digitally sign an authentication token
to show that the user 100 who is demanding an operation is in
possession of the private key of a certificate, an specific
computing mobile device with the private information built inside
or a physical token guarding this private information (e.g.
smartcard used as citizen card). In this case, the solution is
provided in view of the fact that the first server 300 assumes the
responsibility of incorporating or supporting a public key
infrastructure.
[0096] Once the user 100 has requested an operation (A) and has
exchanged the credentials that authenticate her/him for the first
server 300 (B), the first server 300 determines which ID allows to
identify this operation for this user 100 (C) to said second server
200 and performs an operation status request to the second server
200 to retrieve the status that the legitimate user has set,
through the said seconds server 200 (D), for the said operation.
The second server 200 checks if the said first server 300 is
allowed to access to the configuration that the user 100 has
established to the particular operation and recover the status (E)
that can be on or off. This information can, also, indicates if the
corresponding operation is reinforced with an extra authentication
factor. In this embodiment, this extra authentication factor is, in
addition, hardened with the usage of a digital certificate. So,
based on cryptographic digital signature, it validates that the
user 100, who is in possession of the credentials with the second
server 200 and who knows the private key of the legitimate user
100, can provide them at the moment when the operation is
requested.
[0097] The second server 200 then sends the information related
with the status to the first server 300 (G), but, in difference
with other embodiments, now the OTP is not generated by the second
server 200. Instead of that, it is the first server 300 which
generates the OTP (H) and sends it to the second server 200 (I).
Here the second server 200 plays the role of "out of band" channel
just making easy and secure the exchange of information. So, while
the first server 300 requests the OTP to the user 100 (J), the
second server 200 sends the OTP to the said dedicated program 102
(K). The dedicated program 102 receives the information and,
depending of the alternative chosen to store the user's private key
and operate with it, the solution retrieves this private key (L),
digitally signs the OTP (M) and sends both, the OTP and the
signature to the second server 200 (N).Then it allows the user 100
to enter the OTP in the interface that 300 have employed for demand
this token (O). Once this token and its signature have been sent to
the first server 300 (P), it is possible to determine if it matches
with the token received from the second server 200 (Q and R). If
both tokens are the same, then the first server 300 can assume that
the user 100 who is demanding an operation could correspond with
the user 100 who has signed the OTP, has sent it and, consequently,
is in possession of the private key of the digital certificate
stored by the first server 300.
[0098] The proposed method may be implemented in hardware,
software, firmware, or any combination thereof. If implemented in
software, the functions may be stored on or encoded as one or more
instructions or code on a computer-readable medium.
[0099] Computer-readable media includes computer storage media.
Storage media may be any available media that can be accessed by a
computer. By way of example, and not limitation, such
computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or
other optical disk storage, magnetic disk storage or other magnetic
storage devices, or any other medium that can be used to carry or
store desired program code in the form of instructions or data
structures and that can be accessed by a computer. Disk and disc,
as used herein, includes compact disc (CD), laser disc, optical
disc, digital versatile disc (DVD), floppy disk and Blu-ray disc
where disks usually reproduce data magnetically, while discs
reproduce data optically with lasers. Combinations of the above
should also be included within the scope of computer-readable
media. Any processor and the storage medium may reside in an ASIC.
The ASIC may reside in a user terminal. In the alternative, the
processor and the storage medium may reside as discrete components
in a user terminal.
[0100] As used herein, computer program products comprising
computer-readable media including all forms of computer-readable
medium except, to the extent that such media is deemed to be
non-statutory, transitory propagating signals.
[0101] The scope of the present invention is defined in the
following set of claims.
* * * * *
References