WO2010084209A1 - Sistema de control de acceso seguro - Google Patents

Sistema de control de acceso seguro Download PDF

Info

Publication number
WO2010084209A1
WO2010084209A1 PCT/ES2009/000034 ES2009000034W WO2010084209A1 WO 2010084209 A1 WO2010084209 A1 WO 2010084209A1 ES 2009000034 W ES2009000034 W ES 2009000034W WO 2010084209 A1 WO2010084209 A1 WO 2010084209A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
user
client
environment
banking
Prior art date
Application number
PCT/ES2009/000034
Other languages
English (en)
French (fr)
Inventor
Jorge URIOS RODRÍGUEZ
Iván MORENO HERVÁS
Original Assignee
Vanios Consulting, S.L.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Vanios Consulting, S.L. filed Critical Vanios Consulting, S.L.
Priority to PCT/ES2009/000034 priority Critical patent/WO2010084209A1/es
Priority to EP09838687A priority patent/EP2391053A1/en
Priority to US13/145,976 priority patent/US20120054842A1/en
Publication of WO2010084209A1 publication Critical patent/WO2010084209A1/es

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3231—Biological data, e.g. fingerprint, voice or retina
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • the purpose of the secure access control system and method is to provide a secure environment for operations that require it, especially banking operations carried out through WLAN networks.
  • the center of the system is an external USB-type device basically equipped with a processor, a memory, a cryptographic chip and biometric reading media configured as the main element of protection of the operations to be performed.
  • the secure access control system in banking or similar applications that includes at least one server or host element configured to contain all the functionality of the solution in communication with a banking environment, a biometric device, a client element and the communication elements between the server element and the client element, said elements being configured, basically, so that: an applef component integrated in the server element initiates the control process by requesting the authentication to the biometric device, performing the authentication by means of a own certificate of the biometric device; once the biometric device (2) has been validated, the user requests the biometric data, checking this data by comparison with the biometric data recorded in a previous process and if the result is positive a password (OTP) is generated that is sent to the server element (1) to be validated, valid for For a single access, informing the banking environment, and responding with the personalized environment to the user if the authentication is positive, presenting said environment in the client element, leaving the client environment in the background against the banking environment that is the one who maintains control over the state of the session.
  • OTP password
  • Authentication of the device in the host environment is done by means of a certificate of the biometric device.
  • the server registers the public key of the certificate server of each device and is compared in each access operation with the public key of the certificate sent in that communication by the device to subsequently perform a signature operation that guarantees the integrity of the device within the system.
  • the device Once the device is validated on the server, the device, through the applet.
  • the system also includes a database including all the information associated with each biometric device, said information comprising at least one common field that uniquely identifies the user in the server and banking environments.
  • the information is in the form of tables, at least one of users, one of devices and one of versions of the application.
  • the system is configured to sign processes digitally, and where a plugin element integrated in the user environment starts the signing process, after verifying the positioning of the biometric fingerprint or data, against the traditional bank server, it makes the request for signature against the user through the applet element and the biometric device, where said data is checked as well as the signature of the document; and where once the signed document is considered, the signature is sent to the server element, where it is stored, and a response, redirection and result is given against the traditional banking server.
  • the device can provide other ways to guarantee the identity of the user and the integrity of the processes in this environment of operations with the banking environment. These alternatives can be:
  • the system can compare a server-specific key with the one entered in the device, this comparison may be total, partial, random, etc. - Verification of the keys of the certificates of the device, that is, without the realization of signatures.
  • the biometric device comprises, at least: a fingerprint reader and a cryptographic element configured to understand the crucial security elements for a scenario of access to banking environments, such as the user's personal data including the fingerprint and its digital certificate; and a processor and memory configured to run an Unix / Linux / Windows operating system, where this operating system is responsible for communicating and managing the different components of the device, as well as access and modification of personal data stored in Ia memory, and communication with the client element.
  • the biophoretric device is an external USB type component that communicates with the client element using the IP over USB protocol, so that the exchange of packets is carried out through TCP defining a closed message and data format.
  • Communications between the client element and the server element is carried out by means of the HTTPS protocol, end-to-end encryption, the server element and the biometric device connected to the client element being responsible for the cryptographic functions.
  • FIG. 1 shows the general architecture of the system object of the present invention.
  • FIG. 2 shows a series of user identification tables that are limited to the server (host) environment.
  • FIG. 3 shows the communication architecture between the different elements that make up the system object of the invention.
  • FIG. 4 shows the scheme for sending requests between the different parties involved in the identification of a user.
  • FIG. 5 shows the scheme for sending requests between the different parties involved in the verification of the digital signature of a document.
  • the secure access control system consists of four main elements, the server element 1 (host, that is, the servers of the banking entity that implements the system object of the invention), the device biometric 2, preferably a fingerprint reader device, the client element 3 (the client of the banking entity) and the communications 4 between said elements.
  • the server element 1 host, that is, the servers of the banking entity that implements the system object of the invention
  • the device biometric 2 preferably a fingerprint reader device
  • client element 3 the client of the banking entity
  • the communications 4 between said elements Each of these elements must adapt to the specifications of the architecture of the bank 5 to achieve an integration with its least intrusive system possible.
  • the server element 1 contains all the functionality of the solution that the banking entity 5 will have installed on its own servers. It is here that all the information associated with each bank client is included, such as, for example, the balance, the contracted products or the password to access the environment.
  • the solution requires an integrated or independent database of the client, which includes Tables where the information associated with each biometric device 2 will be stored, such as the identifier of each device, the one-time password (OTP, one time password) update versions, etc. All the necessary functions for the encryption and password generation processes in the server 1 (host) environment will also be included. ⁇
  • the Applet starts the process 41 asking for authentication 42 to the biometric device, which in turn indicates to the user the request for fingerprint 43, once this has been done by the user, the fingerprint 44 is checked and the data of the identification and OTP 45 to the server, through the Applet.
  • the server will verify that the data is correct 46 and the traditional server will be informed that, through two different channels (redirection information and request for web content 47 or user and session information 48), the personalized environment will be presented to the user 49.
  • Updates in the server 1 (host) environment will be made through an executable on the server, where this executable will automatically update the critical processes and modify all the necessary data so as not to compromise the normal operation of the solution.
  • the biometric device 2 is an external component of the USB type, in addition to being the basic element of the application, since it is where the crucial security elements reside for a scenario of access to banking environments, such as the user's personal data including the fingerprint and its digital certificate. All this data is stored securely and inaccessible to unauthorized personnel and meets all safety standards. ⁇
  • This device 2 includes a cryptographic element where the user's information is stored securely and inaccessibly as well as the sample of the fingerprint.
  • a fingerprint reader which will be used to obtain a representation of the user's fingerprint. These readings will serve to store in the cryptographic chip the information necessary for the authentication. It also incorporates a processor and memory sufficient to run an operating system of Unix type, where this operating system is responsible for communicating and managing the different components of the device, as well as access and modification of personal data stored in the memory, and the communication via USB with the equipment in which the device is connected.
  • an exclusive software has been developed structured in a series of dynamic libraries loaded in the system that are called from a main program.
  • the functions of these libraries range from the control of the hardware elements drivers to the implementation of the different encryptions and access to critical data.
  • This structure has been chosen to facilitate the system update process.
  • the communication of the biometric device 2 with the client element 3 via the USB port is carried out using the IP protocol over USB, so that the exchange of packets is done through TCP. This has allowed defining a closed message and data format.
  • the software has been provided with the possibility of remote updating, so that it is possible to improve it or solve problems or errors even if it is already deployed and is being used by the end user.
  • the hardware has the characteristic that if it is open to inspect the internal components or attempt to access the data through non-lawful means, the immediate invalidation of the operation of the elements that compose it will occur.
  • the client element or client environment is referred to the interface of the system object of the invention with the end user or client of the banking entity, accessible through a WLAN network, preferably internet.
  • a WLAN network preferably internet.
  • they are a series of plugins that allow communication with the biometric data reader device safely and without the need to install any specific software on the user's PC.
  • any type of machine that includes a USB port and a Web browser can be used, without any other restrictions (domestic PCs, POS, PDAs or any other one that the banking entity wants to make available) are valid.
  • the plugin has to be compatible with the largest possible number of client operating systems, which must be accessible via the Web, as well as being able to establish communication with the USB port, a Java implementation in the form of embedded Applet has been chosen on a web page and signed by an authorized certification body. The reason why the plugin must be signed by a trusted certification body is for it to have permissions on the bank server.
  • Another embodiment could be an ActiveX component for Internet Explorer and different proprietary plugins for each of the existing major browsers. However, this would cause the existence of different implementations of the same application, so that its management, maintenance and subsequent modification would be much more complex.
  • the communication with the device is done through the TCP / IP protocol over USB Io that allows to use a standard protocol, well known and that adapts to the needs of the solution, in addition to being included in most of the operating systems for what No installation or configuration is necessary on the device.
  • the communication protocol used is based on the exchange of predefined and encrypted messages based on parameters known only to the plugin and the biometric device. These messages vary over time although they always have the same format, so they are illegible to an observer not allowed.
  • Client (3) and server (1) communication is carried out using the HTTPS protocol. This communication is encrypted end to end. That is to say, the plugin will never perform encryption or decryption tasks, but it is limited to sending the data from the device to the server and vice versa, so that they are both in charge of the cryptographic functions.
  • the communications environment 4 encompasses everything necessary to achieve communication between the client environment and the biometric device so that the user can perform all operations safely and transparently.
  • communications are made using the TCP / IP, TCP / IP over USB protocols and through HTTPS and SSL.
  • the data transmitted during communications may contain confidential information, which a malicious user could attempt to use to acquire sufficient knowledge to perform unauthorized actions.
  • it is always necessary to move the fingerprint of the end user and, therefore, their consent, it is necessary to encrypt all communications in some way that only authorized elements are able to understand.
  • the system elements that should have access to this information are the biometric device itself and the server element.
  • the application does not need to decrypt or encrypt any information, since it is only limited to transferring it from one end to another, these ends being responsible for carrying out the cryptography work.
  • the application does not need to decrypt or encrypt any information, since it is only limited to transferring it from one end to another, these ends being responsible for carrying out the cryptography work.
  • All the data exchanged is encrypted after the exchange of a couple of messages between the device and the application.
  • a 3DES algorithm is used, with a variable seed both in session and with each of the possible software updates.
  • the encrypted data will be different.
  • An additional security layer is provided to communications by providing the SSL type communication system. That is, the server element works on HTTPS, so that all the data that is sent to the server will be encrypted with the public key of the server certificate, thus ensuring that no observer who has access to the messages that travel through the network can understand them
  • the same device is an SSL server with a device certificate, and all the data that is sent is encrypted with its public key, being the only one capable of decrypting them. It is possible to change the device certificate depending on the number of uses to guarantee their integrity. Once we have ensured the confidentiality of communications, it is also necessary to ensure user identification so that it is impossible to supplant it. This is achieved thanks to the generation of a One Time Password (OTP), which will be recognized by the server as valid and will change from session to session. The generation of this OTP is also based on a sequential algorithm with several input parameters. Both these parameters and the same algorithm can be changed from version to version, to be able to secure the system again in the event that the algorithm is broken. This data must be shared between the device and the server, and it should be possible to verify if an OTP is valid for the current moment, and detect the misuse of a misused OTP to be able to inform the user or the banking environment.
  • OTP One Time Password
  • the banking environment requests the signature from the device
  • the document you want to sign will be provided, and the device will return the signature and the user's public certificate signed by the trusted CA.
  • This certificate and the same signature will be verified by the server, and in the case of making a positive match, the user's digital signature will be validated and stored as valid.
  • the great advantage of the system consists in the control that is had on all the parts involved, being able to provide it with all the security that is necessary for specific cases. In addition, the intervention of the client machine or its operating system is not necessary, so that the problem of the presence of locally installed malware is avoided.
  • the application in charge of communications is not installed on client machines, but is downloadable via web in any machine and place. Therefore, it is decided to implement it as a web application integrated in the client.
  • This also provides the advantage that it can be updated in the same way as the server elements, since it is enough to update it so that the download of the new version occurs in the next access of each of the users.
  • the biometric device is the key element in a desirable policy of continuous updates. These updates are not only an improvement to the system, but, due to the conditions surrounding the device, they are totally mandatory for the correct operation of the solution.
  • This device will be used by users in environments and machines that are predictably unsafe, with the risk of the existence of any type of virus, Trojan or derivatives. It is also exposed to attacks and misuse of malicious users, such as attempts to deny service, unauthorized signatures of documents, or theft of credentials of the owner.
  • the device is designed with all these threats in mind, and trying to avoid or minimize them as much as possible.
  • This central device control also allows other actions based on the device's history, such as remote formatting or storage of access and location logs. For example, a user could see his device compromised, either for theft or for any other reason, and inform the bank that he wants to cancel it for that reason. At that time, the device data stored on the server could be put in a "compromised” state, so that if a subsequent access attempt occurred, it could be stored from where you are trying to access and from which environment, and then proceed to the complete invalidation Of the device.
  • the updates are grouped into compressed files that include an XML descriptor with the actions to be taken. There are also major or minor updates, so that depending on the type of update the device will act in one way or another, restarting immediately or waiting for future updates before returning to the initial state.
  • the first step is that the web page where the Applet is embedded calls a method thereof, through a JavaScript type function, whose parameter will be the string Complete that you want to sign. It is very important that the Applet be the same one that has been used to login, and that it has been continuously loaded, that is, that there must be a frame or some other container that is always kept open and where the Applet is permanently loaded. This call can be made in response to an event related to an html button, for example.
  • the Applet communicates with the device and asks you to sign the indicated chain. At this time the device asks the user to slide his fingerprint. If the verification is incorrect, an empty string is returned to the Javascript function, which should interpret this result as an error in the signing process. If the fingerprint is correct, the device calculates the hash of the chain to be signed using the SHA-1 algorithm, and encrypts said hash with the user's private key, which is obtained from the cryptographic chip and never leaves the device, using the RSA algorithm. In addition, the certificate containing the user's public key is also obtained from the cryptographic chip.
  • the device returns the result of the signature and the user certificate containing its public key to the applet. Both data are returned by the applet to the Javascript function that requested the signature. Then, this same Javascript routine should be responsible for sending this data to the server along with all the necessary to complete the transaction or process that is being performed. When this data arrives at the server, it must verify that the certificate presented is correct and that it is signed by one of its trusted entities, that the transaction to be performed is possible, and that the signature provided by the device is correct and It corresponds to the certificate presented.
  • System initialization process it will be carried out from an application running locally, not downloaded online, and with access to the bank's intranet, so that you will have access to the resources necessary to complete the process. It should not be an online application to avoid sending confidential data through the network, such as the machine code of the application itself, or the certificate to be installed on the device. This process is as follows:
  • the device boots, verifies that it has no registered fingerprint or any client certificate, and is waiting to be initialized. To carry out the verification, try to communicate with the cryptographic card, which will either not be initialized because it is the first time the device starts up, or it will be initialized but without the two necessary files. If the card is not initialized, it will be initialized. It also checks if the device certificate exists, necessary for SSL communication with the client. If it does not exist (because it is the first time it is started), a self-signed certificate is generated for secure communication. Both processes, both the communication with the cryptographic card and the generation of the device certificate are detailed below. Second: A process is launched that listens on the assigned TCP port, and awaits communication from the initialization program.
  • This communication is established over SSL, so that all the information that travels from the client application to the device will travel encrypted with asymmetric encryption. For this, the device will use the self-signed certificate generated on its first boot. Once the communication is established from the application to the device, it immediately replies with the software version that it has installed, so that the client application knows the peculiarities of the specific device.
  • the client application must send a specific command, specified by two bytes, which indicates that it wants to know the device ID. If this command is not what is expected, the device will cut off the communication immediately. If it is correct, it will answer with the device ID encrypted in 3DES (in the future AES) with its own and different encryption key for each software update version of the device.
  • a specific command specified by two bytes, which indicates that it wants to know the device ID. If this command is not what is expected, the device will cut off the communication immediately. If it is correct, it will answer with the device ID encrypted in 3DES (in the future AES) with its own and different encryption key for each software update version of the device.
  • the client application will notify the device if it will work with a digital certificate or text file, depending on the requirements of each specific platform.
  • This communication will consist of two bytes, which the device process will analyze to act accordingly. Again, if the command is incorrect, the immediate cancellation of the communication will proceed.
  • the next step is the sending of the digital client certificate and its associated private key (or where appropriate the text file with its summary data) to the device.
  • the length of the file that is to be transmitted in the form of a text string finished in the newline character is sent first.
  • the file content itself is sent as binary data.
  • the client certificate will be a pair of private key and public key signed by a trusted entity for the banking entity (it can either be a CA of Microsoft, or of some external trust entity). Both data will be in a single file, in pfx format, to help the simplicity of communications with the device.
  • the device proceeds to store the pfx file on the cryptographic card. Answer to the client application that the overall result of the application has been correct with an OK byte, closes the connection, and waits for subsequent communications. Seventh: The client application will then communicate to the database engine that the device with the collected ID has been initialized. In addition, the data related to the device certificate that has been used for SSL communication with it will be stored therein. This data will not be the device certificate itself, but the certificate of the internal CA of the device that has been used to self-sign the device certificate. In this way, it is possible for the device itself to change its certificate and re-sign it with its internal CA, without any identification problem.
  • the initialization PIN that will have to be used later for the activation of the device and the first fingerprint registration.
  • This PIN will be based on the device ID, and will be obtained by some basic transformation algorithm.
  • the cryptographic card is used to store the data of the certificate and the user's private key, and its fingerprint. For this, a tree structure is used within the file system of the card, so that there is a root or MasterFile MF (as in other cards of this type), from which a DF DedicatedFile hangs for the present application. Within this DF there is an EF ElementaryFile for each file, in total two, with binary format without any structure. One of the files represents the pfx where the certificate data and the private key are stored, and the other saves the HASH chain summarizing the user's fingerprint.
  • This PIN must be generated by a standard algorithm that uses the device ID and a symmetric key known only to the device software. In this way, the PIN of the card will be different for each cryptographic card, and the possibility of accessing a cryptographic card from a device that is not the same as the one initialized is also avoided.
  • the symmetric key used to generate the PIN is stored within the device control program, so it is stored in machine code within the executable and subsequently in the volatile RAM used by the operating system for its processes. Therefore he never leaves the device, and is not exposed to theft in the network. Therefore, the initialization process would consist of the creation of the MF, the DF and its associated PIN.
  • Update process and remote formatting Once the device has been registered in the system, initialized and activated, it is possible to remotely update the software that has been installed or any of its parameters. This is possible thanks to a version control system that is performed on the server, and in which both a version history and the version identifier that each device has installed are stored.
  • the update process is as follows:
  • the device boots, verifies that it has a registered fingerprint and client certificate. To perform the check try to communicate with the cryptographic card, which must be initialized and with the two necessary files. In addition, it is verified that the device certificate exists, necessary for SSL communication with the client.
  • a process is launched that listens on the assigned TCP port, and awaits communication from the client program. This communication is established over SSL, so that all the information that travels from the client application to the device will travel encrypted with asymmetric encryption. For this, the device will use the self-signed certificate generated on its first boot. Once the communication is established from the application to the device, it immediately replies with the software version that it has installed, so that the client application knows the peculiarities of the specific device.
  • the client application must send a specific command, specified by two bytes, which indicates that it wants to know the device ID.
  • This command is dependent on the software version installed on the device, so it may be different between versions. Therefore, it is necessary to keep a history of versions, either on the server or in the client application, since if the information on how to communicate with a software version is not available, it will be impossible to use devices with said software version installed.
  • the decision to eliminate old versions of the history will correspond to the policies established in each client. If the version history and its peculiarities (types of commands, media, etc.) are stored on the server, the client application must request the necessary information from it to be able to dialogue with the device. If this command is not what is expected, the device will cut off the communication immediately. If it is correct, it will answer with the device ID encrypted in 3DES (in the future AES) with its own and different encryption key for each software update version of the device.
  • the client application Once the client application has collected both data, it will be forwarded to the server along with the SSL server certificate used by the device. This will decrypt the device dentist with the appropriate 3DES key for the version of software installed in the device, and will check in its database that according to the information available, the data provided by the device is correct.
  • This verification will consist of two steps: first you must validate that the SSL certificate of the device is signed by the device CA that the server has stored in a database, accepting in this way that it is a valid device. The second step is to verify that the version that the device has said it has is the one that the server has registered for that device. If the information does not match, it is determined that the system is being misled, and the device will be marked as invalid. Once this verification has been carried out correctly, a software version available after the one installed will be searched. If it does not exist, the device has the latest software version installed, and from this point the normal login process continues. If there is a new version, it is installed.
  • the client application will inform the device that it must be updated, and that it is prepared to receive the new update. This will be done with a 2-byte code; as always this code will be dependent on software version. Then the device will be waiting to receive, first the length of the update file, and second the content of the file. One time Once the update file is received, the device will decompress it in a temporary directory and analyze the contents of the xml. As we have already said, this xml will consist of a list of actions on device files and files contained in said temporary directory.
  • An example file would be:
  • the device will inform the client application that the update has been completed correctly, and will proceed to close the connection, terminate the processes in execution, and restart not only the necessary routines for its operation, but the complete operating system.
  • the plugin will then let the server know, that it will have to register in its database that the device indicated from now on will operate with the new version. It could happen that this information does not reach the server, but the device has actually been updated. In this case, the server will know that it has sent the version so that the device is updated and has not received a response.
  • the terminology just used corresponds to the way of applying these changes, so that the first number represents complete “versions” of the software. The second however are only “updates” of these versions, since they do not include all the software, but certain changes about it. And finally, the last number represents configuration changes, such as encryption keys, in which the last change always overwrites the previous ones.
  • Updates and modifications will travel and be installed in the form of compressed files that will contain an xml with the installation instructions, and all files that need to be changed or updated. If an error occurs during these updates, the device will always have the latest full installed version stored somewhere in its file system, so that it is possible to reinstall it.
  • the versions are complete software packages. They are also compressed files, with full paths for all files that are I need to unpack. It could be said that they are self-installable packages, since they should only be treated with their default application so that all the necessary files are copied to the operating system. Thus, it will always be possible to install these packages even if the process is corrupted as a result of an update, since it will be standard programs that will install them.
  • they may also include an xml file with post-boot instructions, so that as a step after the first boot of the newly installed version, it will be checked if said xml exists and the instructions contained therein will be executed.
  • Activation process When the device starts up, and when making its checks, it discovers that it has a client certificate and a device certificate installed, but that there is no registered fingerprint, it will proceed to execute the following process.
  • a process is heard that listens on the assigned TCP port, and waits for communication from the activation program.
  • This communication is established over SSL, so that all the information that travels from the client application to the device will travel encrypted with asymmetric encryption.
  • the device will use the self-signed certificate generated on its first boot. This process may have already been started before, since as we saw in the previous section, at the end of the initialization, the device does not turn off, but rather it waits for new TCP communications (which, being already initialized, will be used for activation).
  • Once the communication is established from Ia ai application device it immediately responds with Ia software version you have installed, for 'that the application client knows the peculiarities of the particular device.
  • the client application must send a specific command, specified by two bytes, which indicates that it wants to know the device ID. This command is the same as in the initialization process, and only changes from one software version to the next version. If this command is not what is expected, the device will cut off the communication immediately. If it is correct, it will answer with the device ID encrypted in 3DES (in the future AES) with its own and different encryption key for each software update version of the device.
  • a specific command specified by two bytes, which indicates that it wants to know the device ID. This command is the same as in the initialization process, and only changes from one software version to the next version. If this command is not what is expected, the device will cut off the communication immediately. If it is correct, it will answer with the device ID encrypted in 3DES (in the future AES) with its own and different encryption key for each software update version of the device.
  • the user will have to enter the activation PIN, which will be sent first to the server for verification, and then to the device in the form of a text string terminated in the new line character.
  • the server verifies that the PIN is correct, and inform the client application that it is correct. Once checked, it is sent to the device. This will also verify that the PIN is correct, since it knows the transformation necessary to obtain it from its own ID.
  • the client application receives the response from the server, and before sending the PIN to the device, the current date and IP data is sent from the one that is connecting to the server, data that the server itself device is unable to know for itself.
  • the device sends a specific 2-byte command indicating that the date will be set, and then sends a text string that represents the current date.
  • the date is obtained from the client machine, and the month-day-hour-minute-year format (MMddkkmmyyyy) is given.
  • the client application sends another 2-byte command indicating that it will indicate to the device the external IP from which it is being connected so that it is reflected in the 1ogs that the device stores.
  • After sending the 2 bytes it sends a text string that reflects the IP, in xxx.xxx.xxx.xxx format.
  • the device informs the activation application and the communication is cut off. Otherwise, the device informs that the PIN is correct, and remains waiting for the user to slide his finger through the fingerprint reader. If the PIN sent to the server is wrong, it will register a failed activation attempt, increasing a counter with each failed attempt. When a certain number of attempts is reached, the device will be locked and it will not be possible to operate with it.
  • Fingerprints The result of sliding your finger through the fingerprint reader is a reconstructed bitmap image. This image is treated with proprietary algorithms of the manufacturer of the fingerprint reader to extract its critical points, its minutiae. These minutiae, which summarize and store all the information necessary to identify a fingerprint, are treated again with a function proprietary and grouped and compacted in the form of a HASH chain, which in the case of the fingerprint registration will be what is stored in the cryptographic chip.
  • the HASH stored in the device is compared with the HASH obtained from the sliding of the finger. This check is not of equality, but each time the finger slides the result can be different, and therefore it is necessary to use a proprietary recognition algorithm that should take into account the way to obtain the details of each image and the shape of compacting them in HASH chain.
  • the device boots and checks its status. As in the previous processes, it acts accordingly and starts the listening process on the TCP port. When communication is established, it sends its software version.
  • the client application must send a specific command, specified by two bytes, indicating that it wants to know the device ID. This command is the same as in the initialization and activation processes, and only changes from one software version to the next version. If this command is not what is expected, the device will cut off the communication immediately. If it is correct, it will answer with the device ID encrypted in 3DES (in the future AES) with its own and different encryption key for each software update version of the device.
  • 3DES in the future AES
  • the client application will send the ID of the device obtained encrypted and its software version to the server.
  • the client application will never encrypt or decrypt any data coming from or destined for the device.
  • the server checks that the device with the indicated ID is activated and that the installed software version is the correct one. In the event that the device needs to be updated, it will be communicated to the client application and this will begin with the updating or formatting of the same. In case the status is correct, the client application assumes that you can continue with the login process. To do this, the first thing you will do is send the current date and IP data to the device from which you are connecting to the server, data that the device itself is incapable of Know for yourself.
  • the device sends a specific 2-byte command indicating that the date will be set, and then sends a text string that represents the current date.
  • the date is obtained from the client machine, and the month-day-hour-minute-year format (MMddkkmmyyyy) is given.
  • the client application sends another 2-byte command indicating that it will indicate to the device the external IP from which it is being connected so that it is reflected in the logs that the device stores.
  • the client application sends a text string that reflects the IP, in xxx.xxx.xxx.xxx format. In case both shipments are made correctly, a 2-byte command is sent again to the device that indicates that it can start with the fingerprint check.
  • the process of the device remains waiting for the user to slide his finger through the fingerprint reader. Once the bitmap image of the user's fingerprint is obtained, it is treated and transformed as indicated, the registered fingerprint that is stored in the cryptographic chip is obtained and compared. If the check is negative, the application is informed, the communication is cut off and the device is again in standby mode.
  • a OneTimePassword is generated inside the device. This OneTimePassword is based on the device ID and a session counter, which are combined to generate a chain from which both parameters can be extracted by means of an algorithm to be defined. Subsequently it is encrypted with the same encryption that is used for the device ID in previous communications, and sent to the application, which without deciphering it at any time will be sent to the server. At this point the device considered to have successfully initiated session Ia and Ia is expected ⁇ following operations such as signing transactions or other.
  • the server receives the generated OTP, decrypts and verifies it. To do this, check that the ID obtained from this password corresponds to the ID of the device you are trying to login, and that the associated session counter is later than the last one used to login. It is not necessary for the session counter to be immediately subsequent, but it is enough that it is greater, due to the infinite number of problems that could be obtained when using this strict requirement.
  • the user When he server has positively checked this OTP, the user will be shown his client environment, since it is considered that he has successfully made the login in the environment.
  • Post-session processes Once the device has been logged in, it will remain open until either the TCP communication is closed, or a command is received to terminate the session. Meanwhile, he is listening while waiting to receive other operation commands.
  • Each command is composed of 2 bytes, and they are the following. It should be noted that each command is not exclusive of the others, that is, once the session is initiated, it is possible, for example, to make 2 process signatures, and subsequently modify the fingerprint without having to log in again, provided that Do not cut the TCP channel with the client application.
  • the client application When the signature of a process or document is to be made from the web page, the client application is requested to do so. This will send the corresponding command to the device through the TCP communication that is established with it. Then you must send the length of the content to be signed, and then the content itself. The device will then access the cryptographic chip thanks to the PIN, and will obtain the pfx file that contains both the private key and the user's certificate. It will use the private key to sign the content using the SHA1 hash and RSA encryption algorithms, and will return both this signature and the user's certificate to the client application. The client application will send both data to the web page, which will be responsible for sending them to the server for verification, processing and storage.
  • the client application sends the command to start this process to the device; This is waiting for the user to slide his finger through the fingerprint reader, and stores the result on the cryptographic chip.
  • the previous fingerprint registered to the user is not requested since he has already logged in to the device and therefore his identity has been verified.
  • the client application is responsible for sending both the command to the device necessary (2 bytes), such as the length and content of the new certificate. Once it is received, it will be stored in the cryptographic chip completely replacing the previous certificate (and private key).
  • the solution can, in turn, allow access to corporate telematic environments through that biometric device, provided that it implements the contents of the solution described.
  • multi-user and multi-entity capacity are, several users on the same device and a single device for several banking entities.
  • multi-user the user will be uniquely identified against the server after sliding his fingerprint due to a unique user identifier equal to that registered on the server.
  • the multi-entity is achieved by sending, by the applet, an entity code that acts as a pointer so that the device knows the data to be delivered.

Abstract

Sistema de control de acceso seguro en aplicaciones de tipo bancario o similar que comprende, al menos, un elemento servidor (1 ) u host en comunicación con un entorno bancario (5), un dispositivo biométrico (2), un elemento cliente (3) y los elementos de comunicaciones (4) entre el elemento servidor (1 ) y el elemento cliente (3), dichos elementos configurados para que un componente "applet" integrado en el elemento servidor (1 ) inicie el proceso de control (41 ) pidiendo Ia autenticación (42) al dispositivo biométrico (2), efectuando Ia autenticación por medio de un certificado propio del dispositivo biométrico, éste solicita al usuario el dato biométrico (43), comprobándose dicho dato por comparación con el dato biométrico registrado en un proceso anterior y generándose una contraseña (OTP) que se envía al elemento servidor (1 ) para su validación, informándose al entorno bancario (5) y respondiendo éste con el entorno personalizado al usuario (49) si Ia autenticación es positiva, presentándose dicho entorno en el elemento cliente (3).

Description

SISTEMA DE CONTROL DE ACCESO SEGURO.
El sistema y método de control de acceso seguro tiene por objeto proporcionar un entorno seguro para operaciones que así Io requieran, especialmente operaciones bancarias realizadas a través de redes WLAN. El centro del sistema es un dispositivo externo de tipo USB dotado básicamente de un procesador, una memoria, un chip criptográfico y medios de lectura biométrica configurados como principal elemento de protección de las operaciones que se deseen realizar.
ANTECENDENTES DE LA INVENCIÓN
Se desconoce por parte de los inventores, expertos en Ia materia, de ningún sistema de control de acceso seguro como el descrito en Ia presente patente de invención.
DESCRIPCIÓN DE LA INVENCIÓN
El sistema de control de acceso seguro en aplicaciones de tipo bancario o similar que comprende, al menos, un elemento servidor u host configurado para contener toda Ia funcionalidad de Ia solución en comunicación con un entorno bancario, un dispositivo biométrico, un elemento cliente y los elementos de comunicaciones entre el elemento servidor y el elemento cliente, estando dichos elementos configurados, básicamente, para que: un componente "applef integrado en el elemento servidor inicie el proceso de control pidiendo Ia autenticación al dispositivo biométrico, efectuando Ia autenticación por medio de un certificado propio del dispositivo biométrico; una vez validado el dispositivo biométrico (2) éste solicita al usuario el dato biométrico, comprobándose dicho dato por comparación con el dato biométrico registrado en un proceso anterior y si el resultado es positivo se genera una contraseña (OTP) que se envía al elemento servidor (1 ) para que sea validada, válida para un solo acceso, , informándose al entorno bancario, y respondiendo éste con el entorno personalizado al usuario si Ia autenticación es positiva, presentándose dicho entorno en el elemento cliente, quedando el entorno cliente en un segundo plano frente al entorno bancario que es quien mantiene el control sobre el estado de Ia sesión.
La autenticación del dispositivo en el entorno host se realiza por medio un certificado propio del dispositivo biométrico. En el momento del registro- del dispositivo en el sistema, el servidor registra Ia clave pública del servidor de certificados de cada dispositivo y es comparada en cada operación de acceso con Ia clave pública del certificado enviado en esa comunicación por el dispositivo para posteriormente realizar una operación de firma que garantiza Ia integridad del dispositivo dentro del sistema. Una vez validado el dispositivo en el servidor, el dispositivo, por medio del applet.
El sistema comprende, además, una base de datos incluyendo toda Ia información asociada a cada dispositivo biométrico comprendiendo dicha información, al menos, un campo común que identifique al usuario de forma única en los entornos servidor y banca rio.
La información se encuentra en forma de tablas, al menos una de usuarios, una de dispositivos y una de versiones de Ia aplicación.
Ei sistema está configurado para firmar procesos digitalmente, y donde un elemento plugin integrado en el entorno usuario inicia el proceso de firma, tras verificar el posicionamiento de Ia huella o dato biométrico de nuevo, contra el servidor tradicional del banco, éste hace Ia petición de firma contra el usuario a través del elemento applet y del dispositivo biométrico, donde se chequea dicho dato así como Ia firma del documento; y donde una vez se considera el documento firmado, se envía Ia firma al elemento servidor, donde se almacena, y se da una respuesta, redirección y resultado contra el servidor tradicional de banca.
Además de realizar el proceso de firma mediante Ia firma digital, el dispositivo puede aportar otras formas para garantizar Ia identidad del usuario y Ia integridad de los procesos en este entorno de operaciones con el entrono bancario. Estas alternativas pueden ser:
Generar una password temporal por medio de una función de generación de claves.
Habiendo introducido una clave en un momento anterior a estas operaciones, el sistema puede comparar una clave propia del servidor con Ia introducida en el dispositivo, esta comparación podrá ser total, parcial, aleatoria, etc. - Comprobación de las claves de los certificados del dispositivo, esto es, sin realización de firmas.
Todo ello después de que el usuario ponga Ia huella y su comparación con Ia base, o las huellas bases, sea correcto. El dispositivo biométrico comprende, al menos: un lector de huella digital y un elemento criptográfico configurado para comprender los elementos de seguridad cruciales para un escenario de acceso a entornos bancarios, tales como los datos personales del usuario incluidos Ia huella y su certificado digital; y un procesador y memoria configurados para ejecutar un sistema operativo de tipo Unix/Linux/Windows, donde este sistema operativo es el encargado de comunicar y gestionar los distintos componentes del dispositivo, así como del acceso y Ia modificación de los datos personales almacenados en Ia memoria, y Ia comunicación con el elemento cliente. El dispositivo biofnétrico es un componente externo de tipo USB que se comunica con el elemento cliente utilizando el protocolo IP sobre USB, de forma que el intercambio de paquetes se realiza mediante TCP definiéndose un formato de mensajes y datos cerrado.
Las comunicaciones entre el elemento cliente y elemento servidor se realiza mediante el protocolo HTTPS, cifrada extremo a extremo, siendo el elemento servidor y el dispositivo biométrico conectado con el elemento cliente, los encargados de las funciones criptográficas.
A Io largo de Ia descripción y las reivindicaciones Ia palabra "comprende" y sus variantes no pretenden excluir otras características técnicas, aditivos, componentes o pasos. Para los expertos en Ia materia, otros objetos, ventajas y características de Ia invención se desprenderán en parte de Ia descripción y en parte de Ia práctica de Ia invención. Los siguientes ejemplos y dibujos se proporcionan a modo de ilustración, y no se pretende que sean limitativos de Ia presente invención. Además, Ia presente invención cubre todas las posibles combinaciones de realizaciones particulares y preferidas aquí indicadas.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
FIG. 1 muestra Ia arquitectura general del sistema objeto de Ia presente invención.
FIG. 2 muestra una serie de tablas identificativas de los usuarios y que se circunscriben al entorno servidor (host).
FIG. 3 muestra Ia arquitectura de comunicación entre los distintos elementos que componen el sistema objeto de Ia invención.
FIG. 4 muestra el esquema de envío de peticiones entre las distintas partes implicadas en Ia identificación de un usuario.
FIG. 5 muestra el esquema de envío de peticiones entre las distintas partes implicadas en Ia comprobación de Ia firma digital de un documento. REALIZACIÓN PREFERENTE DE LA INVENCIÓN
Tal y como se observa en Ia figura 1 el sistema de control de acceso seguro consta de cuatro elementos principales, el elemento servidor 1 (host, es decir, los servidores de Ia entidad bancaria que implemente el sistema objeto de Ia invención), el dispositivo biométrico 2, preferentemente un dispositivo lector de huellas dactilares, el elemento cliente 3 (el cliente de Ia entidad bancaria) y las comunicaciones 4 entre dichos elementos. Cada uno de estos elementos debe adaptarse a las especificaciones de Ia arquitectura del banco 5 para conseguir una integración con su sistema Io menos intrusiva posible.
Más concretamente, el elemento servidor 1 contiene toda Ia funcionalidad de Ia solución que va a tener instalado Ia entidad bancaria 5 en sus propios servidores. Es aquí donde se incluye toda Ia información asociada a cada cliente del banco, como puede ser, por ejemplo, el saldo, los productos contratados o Ia contraseña de acceso al entorno.
Para Ia integración del sistema de Ia invención, se realiza previamente un análisis de los procesos que realiza el entorno Web de Ia entidad bancaria 5 pero, a grandes rasgos, Ia solución requiere una base de datos integrada o independiente de Ia del cliente, que incluya unas tablas donde se almacenará Ia información asociada a cada dispositivo biométrico 2, como por ejemplo el identificador de cada dispositivo, Ia contraseña de un solo uso (OTP, one time password) versiones de actualización, etc. También se incluirán todas las funciones necesarias para los procesos de encriptación y de generación de contraseña en el entorno servidor 1 (host). }
En este punto pueden surgir variaciones en Ia arquitectura dependiendo del diseño de base de datos que desee tener Ia entidad bancaria 5. Las opciones pasan por un único sistema con varias instancias, incluir todo en Ia misma o emplear dos bases de datos totalmente independientes conectadas por algún proceso tipo Web, sockets, RMI o transacciones. Lo único imprescindible es tener un campo común que identifique a un usuario en los dos entornos. La estructura básica de las tablas utilizadas se muestra en Ia figura 2, donde se aprecia una tabla de usuarios 21 con distintos datos propios, una tabla de dispositivos 22 con sus datos, y una tabla de versiones 23 con sus datos propios. El entorno de comunicaciones 4 entre los distintos elementos se muestra en Ia figura 3 donde se observa cómo, una vez que el elemento servidor 1 ha identificado al usuario como cliente autenticado del banco, el acceso queda reflejado y se informa al entorno tradicional bancario 5. Entonces el usuario será redirigido a su entorno personal y Ia aplicación propia de Ia invención quedará en un segundo plano hasta que solicite Ia firma digital de algún proceso o documento.
La forma de indicar al servidor Web original que el usuario ha realizado un login o acceso válido tiene varias posibilidades que van desde los Web Sen/ices hasta las redirecciones Web. En cualquiera de los casos, se debe informar al servidor bancario 5 que el usuario ha accedido al sistema, Io que implica que el servidor debe conocer algunos datos requeridos por el servidor Web bancario 5 y que deben formar parte de los datos comunes entre ambas bases de datos. En Ia figura 4 se muestra el flujo de datos entre las partes implicadas en el acceso.
En un primer momento el Applet inicia el proceso 41 pidiendo Ia autenticación 42 al dispositivo biométrico, que a su vez indica al usuario Ia petición de huella 43, una vez realizado esto por el usuario, se comprueba Ia huella 44 y se transmiten los datos de identificación y OTP 45 al servidor, a través del Applet. En el servidor se comprobarán que los datos son correctos 46 y se informará al servidor tradicional que, por medio de dos vías distintas (información de redirección y petición de contenido web 47 o bien información de usuario y de sesión 48), presentará el entorno personalizado al usuario 49.
Llegados a este punto es el servidor web tradicional el qué mantiene el control sobre el estado de Ia sesión y del entorno, pero Ia aplicación de cliente queda cargada en Ia memoria del navegador a Ia espera de tener que realizar alguna otra acción.
Para el proceso de firma digital, es el entorno el que solicita al plugin de Ia aplicación que comience el proceso, y debe suministrar el documento o los datos que se desean firmar. Entonces el plugin comenzará las comunicaciones necesarias con todos los elementos del sistema, incluida Ia solicitud al usuario de Ia huella digital y el almacenamiento del documento firmado en el servidor 1 (host). El esquema de tiempos y comunicaciones se muestra en detalle en Ia figura 5. ,
I
En dicha figura 5 se puede observar como el plugin propio del usuario inicia el proceso de firma 51 contra el servidor tradicional del banco, éste hace Ia petición de firma 52 contra el usuario a través del Applet y del dispositivo de lectura de datos biométricos, donde nuevamente se chequea Ia huella y Ia firma del documento 53, una vez se considera el documento firmado 54, se envía Ia firma 55 al servidor, donde se almacena 55, y se da una respuesta, redirección y resultado 56 contra el servidor tradicional de banca.
Las actualizaciones en el entorno servidor 1 (host) se harán por medio de un ejecutable sobre el servidor, donde este ejecutable actualizará automáticamente los procesos críticos y modificará todos los datos necesarios para no comprometer el funcionamiento normal de Ia solución.
El dispositivo biométrico 2, como se observa en Ia figura 6, es un componente externo de tipo USB, además de resultar el elemento básico de Ia aplicación, puesto que es donde residen los elementos de seguridad cruciales para un escenario de acceso a entornos bancarios, tales como los datos personales del usuario incluidos Ia huella y su certificado digital. Todos estos datos son almacenados de forma segura e inaccesible para personal no autorizado y cumple todos los estándares de seguridad. ¡
Este dispositivo 2 incluye un elemento criptográfico donde se almacena de forma segura e inaccesible Ia información del usuario así como Ia muestra de Ia huella.
Otro de sus elementos es un lector de huella digital, que se utilizará para obtener una representación de Ia huella digital del usuario. Estas lecturas servirán para almacenar en el chip criptográfico Ia información necesaria para Ia autenticación. Se incorpora también un procesador y memoria suficientes para ejecutar un sistema operativo de tipo Unix, donde este sistema operativo es el encargado de comunicar y gestionar los distintos componentes del dispositivo, así como del acceso y Ia modificación de los datos personales almacenados en Ia memoria, y Ia comunicación mediante USB con el equipo en el que el dispositivo está conectado.
Para Ia implementación de las funcionalidades necesarias, se ha desarrollado un software exclusivo estructurado en una serie de librerías dinámicas cargadas en el sistema que son llamadas desde un programa principal. Las funciones de estas librerías van desde el control de los drivers de los elementos hardware hasta Ia implementación de las distintas encriptaciones y accesos a datos críticos. Se ha optado por esta estructura para facilitar el proceso de actualización del sistema. La comunicación del dispositivo biométrico 2 con el elemento cliente 3 mediante el puerto USB se realiza utilizando el protocolo IP sobre USB, de forma que el intercambio de paquetes se realiza mediante TCP. Esto ha permitido definir un formato de mensajes y datos cerrado.
Todas las operaciones comienzan siempre a petición del elemento servidor 1 por Io que el software del dispositivo 2 se limita a escuchar peticiones, interactuar con el usuario en caso de que sea necesario y a responder con los datos adecuados. Se ha dotado al software de Ia posibilidad de actualización remota, de forma que sea posible mejorarlo o solucionar problemas o errores aunque ya esté desplegado y esté siendo utilizado por el usuario final.
Por último conviene indicar que el hardware tiene Ia característica de que si es abierto para inspeccionar los componentes interiores o intentar el acceso a los datos mediante medios no lícitos, se producirá Ia invalidación inmediata del funcionamiento de los elementos que Io componen.
El elemento cliente o entorno cliente está referido a Ia interfaz del sistema objeto de Ia invención con el usuario final o cliente de Ia entidad bancaria, accesible a través de una red WLAN, preferentemente internet. En concreto, son una serie de plugins que permiten Ia comunicación con el dispositivo lector de datos biométricos de manera segura y sin necesidad de instalar ningún software específico en el PC del usuario.
Dado el diseño del sistema, se podrá utilizar cualquier tipo de máquina que incluya un puerto USB y un navegador Web, sin ninguna otra restricción (son válidos PCs domésticos, TPV, PDAs o cualquier otro que Ia entidad bancaria quiera hacer disponible).
Debido a que el plugin tiene que ser compatible con el mayor número posible de sistemas operativos de cliente, que debe ser accesible vía Web, así como poder establecer comunicación con el puerto USB, se ha optado por una implementación en Java en forma de Applet embebido en una página web y firmada por una entidad de certificación autorizada. El motivo por el que el plugin debe de estar firmado por una entidad certificadora de confianza es para que tenga permisos en el servidor bancario. Otro ejemplo de realización pudiera ser un componente ActiveX para Internet Explorer y distintos plugin propietarios para cada uno de los navegadores mayoritarios existentes. Sin embargo, esto provocaría Ia existencia de diferentes implementaciones de una misma aplicación, por Io que su gestión, mantenimiento y modificación posterior sería mucho más compleja.
La comunicación con el dispositivo se realiza mediante el protocolo TCP/IP sobre USB Io que permite utilizar un protocolo estándar, bien conocido y que se adapta a las necesidades de Ia solución, además de estar incluido en Ia mayoría de los sistemas operativos por Io que no es necesario realizar ninguna instalación ni configuración en el equipo.
El protocolo de comunicación utilizado se basa en el intercambio de mensajes predefinidos y encriptados en función de parámetros sólo conocidos por el plugin y el dispositivo biométrico. Estos mensajes varían con el tiempo aunque siempre tienen el mismo formato, por Io que son ilegibles para un observador no permitido.
La comunicación cliente (3) y servidor (1) se realiza mediante el protocolo HTTPS. Esta comunicación está cifrada extremo a extremo. Es decir, el plugin nunca realizará labores de encriptación o desencriptación, sino que se limita a enviar los datos desde el dispositivo al servidor y viceversa, de forma que son ambos los encargados de las funciones criptográficas.
Como ya se ha indicado, antes del funcionamiento normal del dispositivo es necesario realizar algunas asociaciones y registros desde el entorno bancario. En concreto, se debe asociar el dispositivo con el usuario final e insertar un certificado de usuario en su dispositivo. Este certificado será el que más adelante Ie permita firmar procesos y documentos de forma inequívoca y" legal. Además, será el propio usuario el que, al registrar su huella en el dispositivo biométrico en un primer uso, permita validar dicha huella cuando así se solicite.
El entorno de comunicaciones 4 engloba todo Io necesario para conseguir Ia comunicación entre el entorno cliente y el dispositivo biométrico de manera que el usuario pueda realizar todas las operaciones de forma segura y transparente. Como ya se ha indicado anteriormente, las comunicaciones se realizan mediante los protocolos TCP/IP, TCP/IP sobre USB y mediante HTTPS y SSL. Los datos transmitidos durante las comunicaciones, en determinadas ocasiones, pueden contener información confidencial, que un usuario malintencionado podría intentar utilizar para adquirir un conocimiento suficiente para realizar acciones no autorizadas. A pesar que, para generar esta información siempre es necesario el desplazamiento de Ia huella del usuario final y, por tanto, su consentimiento, es necesario encriptar todas las comunicaciones de alguna forma que sólo los elementos autorizados sean capaces de comprender. Los elementos del sistema que deberían tener acceso a esta información son el propio dispositivo biométrico y el elemento servidor.
Por el contrario, Ia aplicación no necesita desencriptar ni encriptar ninguna información, puesto que sólo se limita a transferirla de un extremo a otro, siendo estos extremos los encargados de realizar las labores de criptografía. Además, de este modo se consigue proteger el algoritmo de encriptación, puesto que no se realiza ninguna tarea en Ia propia máquina cliente.
Todos los datos intercambiados se encriptan después del intercambio de un par de mensajes entre el dispositivo y Ia aplicación. Se utiliza un algoritmo 3DES, con una semilla variable tanto en sesión como con cada una de las posibles actualizaciones del software. Así, es posible cambiar Ia encriptación en cada una de las actualizaciones para evitar o suprimir algunos tipos de ataques. Y además, en cada sesión los datos encriptados serán distintos.
Se proporciona una capa de seguridad adicional a las comunicaciones dotando al sistema de comunicaciones tipo SSL. Es decir, el elemento servidor funciona sobre HTTPS, por Io que todos los datos que se envíen al servidor estarán cifrados con Ia clave pública del certificado del servidor, asegurándonos así de que ningún observador que tenga acceso a los mensajes que viajen por Ia red pueda comprenderlos.
De forma similar, el mismo dispositivo es un servidor SSL con un certificado de dispositivo, y todos los datos que se Ie envían están cifrados con su clave pública, siendo éste el único capaz de desencriptarlos. Es posible cambiar el certificado del dispositivo dependiendo del número de usos para garantizar Ia integridad de los mismos. Una vez que hemos asegurado Ia confidencialidad de las comunicaciones, también es necesario asegurar Ia identificación del usuario para que sea imposible suplantarlo. Esto se consigue gracias a Ia generación de una One Time Password (OTP), que será reconocida por el servidor como válida y que cambiará de sesión a sesión. La generación de esta OTP también está basada en un algoritmo secuencial con varios parámetros de entrada. Tanto dichos parámetros como el mismo algoritmo pueden ser cambiados de versión en versión, para poder asegurar el sistema de nuevo en el caso de que se rompa el algoritmo. Estos datos deben ser compartidos entre el dispositivo y el servidor, y se debe poder verificar si una OTP es válida para el momento actual, y detectar el mal uso de una OTP mal utilizada para poder informar al usuario o al entorno bancario.
Por último, también existe Ia posibilidad de realizar firmas digitales de procesos y documentos con el certificado de usuario almacenado en el dispositivo biométrico. Este certificado se almacena al dar de alta el dispositivo en el servidor, y está firmado por una autoridad de certificación (CA) de confianza para el elemento servidor.
Así, cuando el entorno bancario solicite Ia firma al dispositivo, Ie proporcionará el documento que quiere firmar, y el dispositivo Ie devolverá Ia firma y el certificado público del usuario firmado por Ia CA de confianza. Este certificado y Ia misma firma serán comprobados por el servidor, y en el caso de realizar un match positivo se procederá a validar y almacenar Ia firma digital del usuario como válida.
La gran ventaja del sistema consiste en el control que se tiene sobre todas las partes implicadas, pudiendo dotarlo así de toda Ia seguridad que sea necesaria para casos específicos. Además no es necesaria Ia intervención de Ia máquina del cliente ni de su sistema operativo, por Io que se evita el problema de Ia presencia de malware instalado localmente.
Todas las comunicaciones están doblemente encriptadas, y además, en el caso de que las comunicaciones o los algoritmos se vean comprometidos es posible cambiarlos de forma remota mediante el despliegue de una nueva versión de software.
En esta arquitectura hay varias partes implicadas y distribuidas en distintas máquinas, ya que no se trata de una solución completamente centralizada a Ia que acceden los usuarios finales, como en el caso de aplicaciones íntegramente web. Los elementos que residen en el servidor, aunque es posible que no estén accesibles de forma inmediata para su mantenimiento, están centralizados en un lugar físico, por Io que son más fácilmente actualizables y se pueden mantener libres de errores. Además, puesto que previsiblemente residen en una intranet, el problema de protegerlos de ataques externos es un problema común, y para el que existen varias soluciones ya probadas y llevadas a Ia práctica.
Uno de los requisitos del sistema es que Ia aplicación encargada de las comunicaciones no esté instalada en las máquinas clientes, sino que sea descargable vía web en cualquier máquina y lugar. Por ello se opta por implementarla como aplicación web integrada en el cliente. Esto además aporta Ia ventaja de que puede actualizarse de Ia misma forma que los elementos del servidor, ya que basta con actualizarla para que Ia descarga de Ia nueva versión se produzca en el siguiente acceso de cada uno de los usuarios. El dispositivo biométrico, es el elemento clave en una deseable política de actualizaciones continuas. Estas actualizaciones no son sólo una mejora al sistema, sino que, debido a las condiciones que rodean al dispositivo, son totalmente obligatorias para el correcto funcionamiento de Ia solución.
Este dispositivo va a ser utilizado por los usuarios en entornos y máquinas previsiblemente no seguras, con el riesgo de existencia de cualquier tipo de virus, troyano o derivados. Además está expuesto a los ataques y el mal uso de usuarios malintencionados, tales como intentos de denegación de servicio, de firmas no autorizadas de documentos, o de robo de credenciales del propietario. El dispositivo está diseñado de teniendo muy en cuenta todas estas amenazas, e intentando evitarlas o minimizarlas en Io posible. Sin embargo, debido a Ia continua aparición de nuevas amenazas y el descubrimiento de vulnerabilidades en sistemas ya existentes, es necesario mantener un sistema de actualizaciones de software y control remoto del dispositivo.
Estas actualizaciones son gestionadas desde el elemento servidor, de forma que es posible dar de alta una nueva actualización en un único lugar, para que más tarde esa actualización se despliegue e instale automáticamente en todos los dispositivos dados de alta. Cuando Ia aplicación de cliente detecta Ia inserción de un dispositivo válido, Io primero que realizará será Ia consulta del estado de las versiones, para desplegar inmediatamente Ia nueva versión si fuera necesario. El dispositivo por tanto, nada más arrancar está esperando una comprobación de versión, y una actualización posterior si fuera necesario. El applet por su parte consulta al servidor y Ie informa de cuál es el dispositivo con el que está entablando comunicación, para que sea el servidor el que decida qué acción llevar a cabo con dicho dispositivo biométrico.
Este control central de dispositivos también permite otras acciones en función del historial del dispositivo, como fórmateos remotos o almacenamiento de logs de acceso y localización. Por poner un ejemplo, un usuario podría ver comprometido su dispositivo, bien por robo o bien por cualquier otra razón, e informar al banco de que quiere darlo de baja por dicho motivo. En ese momento los datos del dispositivo almacenados en el servidor podrían ponerse en estado "comprometido", de forma que si se produjera un intento de acceso posterior podría almacenarse desde dónde se está intentando acceder y desde qué entorno, y posteriormente proceder a Ia completa invalidación del dispositivo.
Las actualizaciones se agrupan en ficheros comprimidos que incluyen un descriptor XML con las acciones a tomar. Además existen actualizaciones mayores o menores, de forma que en función del tipo de actualización el dispositivo actuará de una forma u otra, reiniciándose inmediatamente o esperando a futuras actualizaciones antes de volver al estado inicial.
Aunque por el momento no se va a realizar Ia firma digital de los procesos, es importante indicar los procesos a seguir para el momento de su implantación:
Primero: Para iniciar el proceso de firma de transacciones o de cualquier otro documento, el primer paso es que Ia página web donde está incrustado el Applet llame a un método del mismo, a través de una función de tipo JavaScript, cuyo parámetro será Ia cadena completa que se quiere firmar. Es muy importante que el Applet sea el mismo que se ha utilizado para hacer login, y que haya estado cargado continuamente, es decir, que debe haber un frame o algún otro contenedor que se mantenga siempre abierto y donde esté cargado permanentemente el Applet. Esta llamada puede realizarse como respuesta a un evento relacionado con un botón html, por ejemplo.
Segundo: Una vez se ha iniciado Ia ejecución del método, el Applet comunica con el dispositivo y Ie solicita que firme Ia cadena indicada. En este momento el dispositivo Ie pide al usuario que deslice su huella. Si Ia comprobación es incorrecta se devuelve una' cadena vacía a Ia función Javascript, que debería interpretar este resultado como un error en el proceso de firma. Si Ia huella es correcta, dispositivo calcula Ia hash de Ia cadena a firmar mediante el algoritmo SHA-1, y encripta dicha hash con Ia clave privada del usuario, que se obtiene del chip criptográfico y nunca abandona el dispositivo, mediante el algoritmo RSA. Además también se obtiene del chip criptográfico el certificado que contiene Ia clave pública del usuario.
Tercero: Una vez realizado todo este proceso, el dispositivo Ie devuelve al applet el resultado de Ia firma y el certificado de usuario conteniendo su clave pública. Ambos datos son devueltos por el applet a Ia función Javascript que solicitó Ia firma. Entonces, esta misma rutina de Javascript debería encargarse de hacerle llegar al servidor estos datos junto con todos los necesarios para completar Ia transacción o proceso que se esté realizando. Cuando estos datos llegan al servidor, el mismo debe comprobar que el certificado presentado es correcto y que está firmado por una de sus entidades de confianza, que Ia transacción que se quiere realizar es posible, y que Ia firma proporcionada por el dispositivo es correcta y se corresponde con el certificado presentado.
Proceso de inicialización del sistema: se llevará a cabo desde una aplicación corriendo en local, no descargada en línea, y con acceso a Ia intranet del banco, de forma que se tendrá acceso a los recursos necesarios para completar el proceso. No deberá ser una aplicación en línea para evitar el envío de datos confidenciales a través de Ia red, como podrían ser el propio código máquina de Ia aplicación, o el certificado a instalar en el dispositivo. Este proceso es el siguiente:
Primero: El dispositivo arranca, comprueba que no tiene registrada ninguna huella ni ningún certificado de cliente, y se queda a Ia espera de ser inicializado. Para realizar Ia comprobación intenta comunicarse con Ia tarjeta criptográfica, que o bien no estará inicializada por ser Ia primera vez que arranca el dispositivo, o estará inicializada pero sin los dos ficheros necesarios. Si Ia tarjeta no está inicializada, se procederá a inicializarla. Además comprueba si existe el certificado de dispositivo, necesario para Ia comunicación SSL con el cliente. En caso de no existir (por ser Ia primera vez que se arranca) se genera un certificado auto-firmado para Ia comunicación segura. Ambos procesos, tanto el de comunicación con Ia tarjeta criptográfica como el de generación del certificado de dispositivo se detallan más adelante. Segundo: Se lanza un proceso que escucha en el puerto TCP asignado, y espera Ia comunicación desde el programa de inicialización. Esta comunicación se establece sobre SSL, de forma que toda Ia información que viaje desde Ia aplicación cliente hasta el dispositivo viajará cifrada con cifrado asimétrico. Para ello el dispositivo utilizará el certificado auto-firmado generado en su primer arranque. Una vez que se establece Ia comunicación desde Ia aplicación al dispositivo, éste inmediatamente contesta con Ia versión de software que tiene instalada, para que Ia aplicación cliente sepa las peculiaridades del dispositivo en concreto.
Tercero: Seguidamente Ia aplicación cliente deberá enviar un comando concreto, especificado por dos bytes, que indica que quiere saber el ID del dispositivo. Si este comando no es el que se está esperando, el dispositivo cortará Ia comunicación inmediatamente. Si es correcto, contestará con el ID del dispositivo encriptado en 3DES (en el futuro AES) con una clave de encriptación propia y distinta para cada versión de actualización de software del dispositivo.
Cuarto: La aplicación cliente comunicará al dispositivo si va a funcionar con certificado digital o con fichero de texto, en función de los requisitos de cada plataforma concreta. Esta comunicación constará de dos bytes, que el proceso del dispositivo analizará para actuar en consecuencia. De nuevo, si el comando es incorrecto se procederá a Ia cancelación inmediata de Ia comunicación.
Quinto: El siguiente paso es el envío del certificado digital de cliente y su clave privada asociada (o en su caso del fichero de texto con sus datos resumidos) al dispositivo. Para ello primero se envía Ia longitud del fichero que se quiere transmitir en forma de cadena de texto terminada en el carácter de nueva línea. Seguidamente se envía el propio contenido del fichero como datos binarios. El certificado de cliente será una pareja de clave privada y clave pública firmada por una entidad de confianza para Ia entidad bancaria (bien puede ser una CA propia de Microsoft, o bien de alguna entidad de confianza externa). Ambos datos estarán en un único fichero, en formato pfx, para ayudar a Ia simplicidad de las comunicaciones con el dispositivo.
Sexto: El dispositivo procede a almacenar el fichero pfx en Ia tarjeta criptográfica. Contesta a Ia aplicación cliente que el resultado global de Ia aplicación ha sido correcto con un byte de OK, cierra Ia conexión, y se queda a Ia espera de subsiguientes comunicaciones. Séptimo: La aplicación dé cliente Ie comunicará entonces al motor de Ia base de datos que el dispositivo con el ID recogido ha sido inicializado. Además, se almacenarán en Ia misma los datos relativos al certificado de dispositivo que se ha utilizado para Ia comunicación SSL con el mismo. Estos datos no serán el propio certificado de dispositivo, sino el certificado de Ia CA interna del dispositivo que se ha utilizado para auto-firmar el certificado de dispositivo. De esta forma, es posible que el propio dispositivo cambie su certificado y Io vuelva a firmar con su CA interna, sin que exista ningún problema de identificación del mismo.
Octavo: Por último se Ie muestra al usuario por pantalla el PIN de inicialización que tendrá que utilizarse con posterioridad para Ia activación del dispositivo y el primer registro de huella. Este PIN estará basado en el ID de dispositivo, y se obtendrá por algún algoritmo de transformación básico.
Proceso de inicialización de Ia tarjeta criptográfica: La tarjeta criptográfica se utiliza para almacenar los datos del certificado y Ia clave privada del usuario, y su huella dactilar. Para ello se utiliza una estructura en árbol dentro del sistema de archivos de Ia tarjeta, de forma que existe una raíz o MasterFile MF (como en otras tarjetas de este tipo), de Ia que cuelga un DF DedicatedFile para Ia presente aplicación. Dentro de este DF existe un EF ElementaryFile para cada archivo, en total dos, con formato binario sin ninguna estructura. Uno de los ficheros representa el pfx donde se almacenan los datos del certificado y Ia clave privada, y el otro guarda Ia cadena HASH de resumen de Ia huella dactilar del usuario.
Como protección a estos datos, es necesario introducir un PIN de acceso al DF, que nos permitirá tanto leer como cambiar ambos ficheros. Este PIN deberá ser generado por un algoritmo estándar que utilice el ID del dispositivo y una clave simétrica conocida sólo por el software de los dispositivos. De esta forma el PIN de Ia tarjeta será distinto para cada tarjeta criptográfica, y además se evita Ia posibilidad de acceso a una tarjeta criptográfica desde un dispositivo que no sea el mismo que Ia inicializó.
La clave simétrica utilizada para generar el PIN se almacena dentro del programa de control del dispositivo, por Io que está guardada en código máquina dentro del ejecutable y posteriormente en Ia memoria RAM volátil que utiliza el sistema operativo para sus procesos. Por tanto nunca abandona el dispositivo, y no está expuesta al robo en Ia red. Por tanto, el proceso de inicialización consistiría en Ia creación del MF, el DF y su PIN asociado.
Proceso de actualización y formateo remoto: Una vez que el dispositivo ha sido registrado en el sistema, inicializado y activado, es posible actualizar de forma remota el software que lleva instalado o cualquiera de sus parámetros. Esto es posible gracias a un sistema de control dé versiones que se realiza en el servidor, y en el que se almacena tanto un histórico de versiones, como el identificador de versión que tiene instalado cada dispositivo. El proceso de actualización es el siguiente:
Primero: El dispositivo arranca, comprueba que tiene registrada huella y certificado de cliente. Para realizar Ia comprobación intenta comunicarse con Ia tarjeta criptográfica, que deberá estar inicializada y con los dos ficheros necesarios. Además, se comprueba que existe el certificado de dispositivo, necesario para Ia comunicación SSL con el cliente.
Segundo: Se lanza un proceso que escucha en el puerto TCP asignado, y espera Ia comunicación desde el programa de cliente. Esta comunicación se establece sobre SSL, de forma que toda Ia información que viaje desde Ia aplicación cliente hasta el dispositivo viajará cifrada con cifrado asimétrico. Para ello el dispositivo utilizará el certificado auto-firmado generado en su primer arranque. Una vez que se establece Ia comunicación desde Ia aplicación al dispositivo, éste inmediatamente contesta con Ia versión de software que tiene instalada, para que Ia aplicación cliente sepa las peculiaridades del dispositivo en concreto.
Tercero: Seguidamente Ia aplicación cliente deberá enviar un comando concreto, especificado por dos bytes, que indica que quiere saber el ID del dispositivo. Este comando es dependiente de Ia versión de software instalada en el dispositivo, por Io que, podrá ser diferente entre versiones. Por ello es necesario mantener un histórico de versiones, bien en el servidor, o bien en Ia aplicación cliente, ya que si Ia información de cómo comunicarse con una versión de software no está disponible, será imposible Ia utilización de dispositivos con dicha versión de software instalada. Corresponderá a las políticas establecidas en cada cliente Ia decisión de eliminar versiones antiguas del historial. Si el histórico de versiones y sus peculiaridades (tipos de comandos, medios de comunicación, etc.) se almacena en el servidor, Ia aplicación cliente deberá solicitar al mismo Ia información necesaria para poder dialogar con el dispositivo. Si este comando no es el que se está esperando, el dispositivo cortará Ia comunicación inmediatamente. Si es correcto, contestará con el ID del dispositivo encriptado en 3DES (en el futuro AES) con una clave de encriptación propia y distinta para cada versión de actualización de software del dispositivo.
Cuarto: Una vez Ia aplicación cliente ha reunido ambos datos, se los reenviará al servidor junto con el certificado de servidor SSL utilizado por el dispositivo. Éste descifrará el ¡dentificador de dispositivo con Ia clave 3DES apropiada para Ia versión de software instalada en el dispositivo, y comprobará en su base de datos que según Ia información de Ia que dispone, los datos proporcionados por el dispositivo son correctos. Esta comprobación constará de dos pasos: primero deberá validar que el certificado SSL del dispositivo está firmado por Ia CA de dispositivo que el servidor tiene almacenada en base de datos, aceptando de esta forma que es un dispositivo válido. El segundo paso es comprobar que Ia versión que el dispositivo ha dicho que tiene, es Ia que el servidor tiene registrada para ese dispositivo. Si Ia información no coincide, se determina que se está intentando engañar al sistema, y el dispositivo se marcará como no válido. Una vez esta comprobación se ha realizado correctamente, se buscará una versión de software disponible posterior a Ia instalada. Si no existe, es que el dispositivo tiene instalada Ia última versión de software, y a partir de este punto se continúa con el proceso normal de login. Si existe una nueva versión, se procede a Ia instalación de Ia misma.
Quinto: Una vez se ha detectado que hay que instalar una versión nueva, ésta se envía como fichero desde el servidor a Ia aplicación cliente. Este fichero estará comprimido en formato tar.gz, e incluirá todos los ficheros nuevos que haya que copiar o sustituir en el dispositivo, y un fichero xml que especificará qué acciones debe llevar a cabo el dispositivo para completar Ia actualización. En principio estas acciones únicamente estarán referidas a los ficheros contenidos en el tar.gz y a los ficheros del sistema local al dispositivo.
Sexto: Seguidamente Ia aplicación cliente Ie comunicará al dispositivo que debe actualizarse, y que se prepare para recibir Ia nueva actualización. Esto se hará con un código de 2 bytes; como siempre este código será dependiente por versión de software. A continuación el dispositivo se quedará a Ia espera de recibir, primero Ia longitud del fichero de actualización, y segundo el contenido del fichero. Una vez recibido el fichero de actualización, el dispositivo Io descomprimirá en un directorio temporal y analizará el contenido del xml. Como ya hemos dicho, este xml consistirá en una lista de acciones sobre ficheros del dispositivo y ficheros contenidos en dicho directorio temporal. Un ejemplo de fichero sería:
<actualizacion version="1.0"> <acciones>
<moveFile>
<origen>cert. data</origen> <destino>A/aniOs/cert.data2</destino> </moveFile> <moveFile>
<origen>sign. data</origen> <destino>A/aniOs/sign.data2</destino> </moveFile> </acciones> </actualizacion>
En el que las acciones a realizar sería sustituir los ficheros locales indicados con sus rutas completas por las versiones incluidas en el fichero de actualización.
Séptima: Por último, una vez completadas todas las acciones a realizar, el dispositivo informará a Ia aplicación cliente de que Ia actualización se ha completado correctamente, y procederá a cerrar Ia conexión, terminar los procesos en ejecución, y reiniciar no únicamente las rutinas necesarias para su funcionamiento, sino el sistema operativo completo. El plugin entonces se Io hará saber al servidor, que tendrá que registrar en su base de datos que el dispositivo indicado a partir a ahora operará con Ia nueva versión. Podría ocurrir que esta información no llegue al servidor, pero efectivamente el dispositivo se haya actualizado. En este caso el servidor sabrá que ha enviado Ia versión para que el dispositivo se actualice y no ha recibido respuesta. En este caso, Ia siguiente vez que se quiera hacer login desde el dispositivo, el servidor deberá comprobar que el dispositivo tiene instalada una de las dos versiones de software, ya que a priori no se sabe si Ia actualización llegó a ejecutarse o no, actuar en consecuencia, y registrar los posibles cambios en su base de datos. Respecto a las versiones y actualizaciones hay que decir que se etiquetarán con un nombre dependiente del banco, y tres números separados por comas; por ejemplo: CAN.3.5.7 Según esta nomenclatura, tanto el primer como el último número serán indicadores de cambios que sobrescribirán los anteriores, de forma que versiones consecutivas con cambios en dichos números sobrescribirán completamente a Ia anterior. Así, Ia versión 3.5.7 sobrescribirá los cambios realizados en Ia versión 3.5.4 completamente. Esto implica que para pasar de Ia versión 4.2.5 a Ia versión 8.0.0 no sería necesario instalar ninguna versión intermedia, solamente ésta última. Así, los cambios de versiones que modifiquen el primer número de versión siempre deberán incluir todos los cambios realizados en versiones anteriores, y por tanto deberán contener Ia aplicación completa en su estado actual.
Sin embargo el número intermedio se actualiza de forma incremental, de manera que hay que pasar por todas las actualizaciones previas hasta llegar a Ia actual.
Como ejemplo, el proceso para pasar de Ia versión 1.2.3 a Ia versión 4.2.5 sería el siguiente:
- Instalar Ia versión 4.0.0
- Instalar las actualizaciones 4.1.0 y 4.2.0
- Instalar Ia modificación 4.2.5
La terminología que se acaba de utilizar se corresponde a Ia forma de aplicar estos cambios, de forma que el primer número representa "versiones" completas del software. El segundo sin embargo son únicamente "actualizaciones" de dichas versiones, ya que no incluyen todo el software, sino determinados cambios sobre él. Y por último, el último número representa cambios de configuración, tales como claves de encriptación, en los que el último cambio siempre sobrescribe los anteriores.
Las actualizaciones y modificaciones viajarán y se instalarán en forma de ficheros comprimidos que contendrán un xml con las instrucciones de instalación, y todos los ficheros que sea necesario cambiar o actualizar. Si ocurre algún error durante estas actualizaciones, el dispositivo siempre tendrá Ia última versión instalada completa guardada en algún lugar de su sistema de ficheros, de forma que sea posible volver a instalarla.
Las versiones, como hemos dicho, son paquetes completos del software. También son ficheros comprimidos, con rutas completas para todos los ficheros que se i necesitan descomprimir. Podría decirse que son paquetes autoinstalables, ya que únicamente deben tratarse con su aplicación por defecto para que se copien todos los ficheros necesarios al sistema operativo. Así, siempre será posible instalar estos paquetes aunque el proceso se corrompa por efecto de una actualización, ya que serán programas estándar los que se encargarán de instalarlos. Además, opcionalmente, podrán incluir también un fichero xml con instrucciones posteriores al arranque, de forma que como paso posterior al primer arranque de Ia versión recién instalada, se comprobará si existe dicho xml y se ejecutarán las instrucciones contenidas en él.
Estas versiones serán también el software que se instalará en los dispositivos en su inicialización por parte del banco; las versiones serán iguales tanto en Ia primera inicialización, como en instalaciones posteriores.
Por último, hay que indicar que todos los envíos de versiones y actualizaciones serán encriptados con un algoritmo estático de encriptación simétrica, cuya clave se obtendrá a partir del identificador de dispositivo. Esta encriptación no podrá ser cambiada entre versiones.
Creación y actualización del certificado de dispositivo: Antes de Ia primera inicialización del dispositivo, de hecho en cada arranque, se comprobará Ia existencia de un certificado de dispositivo con su clave privada asociada. Estos datos estarán almacenados en el sistema de ficheros local del dispositivo, accesibles para el sistema operativo instalado. En caso de no existir, se procederá a crearlo, siguiendo el siguiente proceso.
Primero: Creación de una clave pública y una privada mediante openSSL, que hará las veces de entidad certificadora. Más adelante, cuando se complete el proceso de inicialización del dispositivo, será esta clave pública Ia que se almacene en Ia base de datos del servidor, para poder reconocer qué certificados de dispositivo son válidos para cada uno de ellos.
Segundo: Creación de una clave privada para el dispositivo. Una vez tengamos esta clave privada, se procederá a generar una petición de certificado con Ia clave pública asociada, y a firmarlo con Ia clave privada de Ia CA generada en el paso anterior. Estas acciones se basan todas en openssl, de forma que será necesario que el dispositivo ejecute un comando específico para cada una ellas. Tercero: Para Ia comunicación con las aplicaciones clientes se utilizarán Ia pareja clave privada-pública de dispositivo, y será Ia aplicación cliente Ia encargada de validar que el certificado utilizado está firmado por Ia CA del dispositivo, cuya clave pública está almacenada en el servidor desde Ia inicialización.
Proceso de activación: Cuando el dispositivo arranque, y al realizar sus comprobaciones descubra que tiene Instalado un certificado de cliente y otro de dispositivo, pero que aún no hay ninguna huella digital registrada, pasará a ejecutar el siguiente proceso.
Primero: Se lanza un proceso que escucha en el puerto TCP asignado, y espera Ia comunicación desde el programa de activación. Esta comunicación se establece sobre SSL, de forma que toda Ia información que viaje desde Ia aplicación cliente hasta el dispositivo viajará cifrada con cifrado asimétrico. Para ello el dispositivo utilizará el certificado auto-firmado generado en su primer arranque. Este proceso puede que ya esté arrancado con anterioridad, ya que como vimos en el apartado anterior, al terminar Ia inicialización no se apaga el dispositivo, sino que se queda esperando nuevas comunicaciones TCP (que al ya estar inicializado, servirán para Ia activación). Una vez que se establece Ia comunicación desde Ia aplicación ai dispositivo, éste inmediatamente contesta con Ia versión de software que tiene instalada, para' que Ia aplicación cliente sepa las peculiaridades del dispositivo en concreto.
Segundo: Seguidamente Ia aplicación cliente deberá enviar un comando concreto, especificado por dos bytes, que indica que quiere saber el ID del dispositivo. Este comando es el mismo que en el proceso de inicialización, y sólo cambia de una versión de software a Ia versión siguiente. Si este comando no es el que se está esperando, el dispositivo cortará Ia comunicación inmediatamente. Si es correcto, contestará con el ID del dispositivo encriptado en 3DES (en el futuro AES) con una clave de encriptación propia y distinta para cada versión de actualización de software del dispositivo.
Tercero: En este momento en Ia aplicación de activación el usuario tendrá que introducir el PIN de activación, que se enviará primero al servidor para que Ia compruebe, y posteriormente al dispositivo en forma de cadena de texto terminada en el carácter de nueva línea. El servidor comprueba que el PIN es correcto, e informa a Ia aplicación cliente de que es correcto. Una vez comprobado, se envía al dispositivo. Este también comprobará que el PIN es correcto, ya que conoce Ia transformación necesaria para obtenerlo a partir de su propio ID. En el instante en que Ia aplicación cliente recibe Ia respuesta del servidor, y antes de enviar el PIN al dispositivo, se procede a realizar el envío de los datos de fecha actual e IP desde Ia que se está conectando al servidor, datos que el propio dispositivo es incapaz de conocer por sí mismo. Para ello envía un comando concreto de 2 bytes indicando que se va a proceder a configurar Ia fecha, y acto seguido envía una cadena de texto que representa Ia fecha actual. La fecha se obtiene de Ia máquina cliente, y se Ie da el formato mes-dia-hora-minuto-año (MMddkkmmyyyy). El dispositivo una vez recibe esta cadena, establece Ia fecha y hora de su sistema operativo según Io indicado. Seguidamente Ia aplicación cliente envía otro comando de 2 bytes indicando que va a indicar al dispositivo Ia IP externa desde Ia que se está conectando para que quede reflejada en los 1ogs que almacena el dispositivo. Después de enviar los 2 bytes, envía una cadena de texto que refleja Ia IP, en formato xxx.xxx.xxx.xxx.
Cuarto: En el caso de que el PIN sea incorrecto, el dispositivo informa a Ia aplicación de activación y se corta Ia comunicación. En caso contrario el dispositivo informa de que el PIN es correcto, y se queda a Ia espera de que el usuario deslice su dedo por el lector de huellas. En caso de que el PIN enviado al servidor sea erróneo, éste registrará un intento fallido de activación, aumentando un contador con cada intento fallido. Cuando se alcance un número determinado de intentos, el dispositivo se bloqueará y no será posible operar con él.
Quinto: El resultado de esta primera lectura de huella digital se almacena inmediatamente como cadena HASH en el chip criptográfico, y de nuevo se informa a Ia aplicación cliente del resultado correcto del proceso. '
Sexto; Por último, como en el proceso de inicialización, se corta Ia comunicación y el dispositivo queda activado y a Ia espera de nuevas comunicaciones para llevar a cabo el proceso de funcionamiento normal.
Huellas digitales: El resultado de deslizar el dedo por el lector de huellas digitales es una imagen de mapa de bits reconstruida. Esta imagen se trata con algoritmos propietarios del fabricante del lector de huellas para extraer sus puntos críticos, sus minucias. Estas minucias, que resumen y almacenan toda Ia información necesaria para identificar una huella digital, son tratadas nuevamente con una función propietaria y agrupadas y compactadas en forma de cadena HASH, que en el caso del registro de huella será Io que se almacene en el chip criptográfico.
En caso de querer hacer una comprobación de identidad, se comparan Ia HASH almacenada en el dispositivo con Ia HASH obtenida del deslizamiento del dedo. Esta comprobación no es de igualdad, sino que cada vez que se desliza el dedo el resultado puede ser distinto, y por ello es necesario utilizar un algoritmo de reconocimiento propietario que deberá tener en cuenta Ia forma de obtener las minucias de cada imagen y Ia forma de compactarlas en cadena HASH.
Proceso de trabajo habitual: Cuando el dispositivo detecta que ya ha sido inicializado y activado, es decir, que ya tiene certificado de usuario, certificado de dispositivo y huella digital registrada, entra en el modo de proceso habitual.
Primero: El dispositivo arranca y comprueba su estado. Como en los procesos anteriores, actúa en consecuencia y arranca el proceso de escucha en el puerto TCP. Cuando se establece Ia comunicación envía su versión del software.
Segundo: De nuevo, Ia aplicación cliente deberá enviar un comando concreto, especificado por dos bytes, que indica que quiere saber el ID del dispositivo. Este comando es el mismo que en los procesos de inicialización y activación, y sólo cambia de una versión de software a Ia versión siguiente. Si este comando no es el que se está esperando, el dispositivo cortará Ia comunicación inmediatamente. Si es correcto, contestará con el ID del dispositivo encriptado em 3DES (en el futuro AES) con una clave de encriptación propia y distinta para cada versión de actualización de software del dispositivo.
Tercero: La aplicación cliente enviará el ID del dispositivo obtenido encriptado y su versión de software al servidor. La aplicación cliente en ningún momento cifrará ó descifrará ningún dato proveniente o con destino al dispositivo. El servidor entonces comprueba que el dispositivo con el ID indicado está activado y que Ia versión de software instalada es Ia correcta. En caso de que el dispositivo necesite ser actualizado, se comunicará a Ia aplicación cliente y esta empezará con Ia actualización o formateo del mismo. En caso de que el estado sea el correcto, Ia aplicación cliente asume que puede continuar con el proceso de login. Para ello, Io primero que realizará será enviar al dispositivo los datos de fecha actual e IP desde Ia que se está conectando al servidor, datos que el propio dispositivo es incapaz de conocer por sí mismo. Para ello envía un comando concreto de 2 bytes indicando que se va a proceder a configurar Ia fecha, y acto seguido envía una cadena de texto que representa Ia fecha actual. La fecha se obtiene de Ia máquina cliente, y se Ie da el formato mes-dia-hora-minuto-año (MMddkkmmyyyy). El dispositivo una vez recibe esta cadena, establece Ia fecha y hora de su sistema operativo según Io indicado. Seguidamente Ia aplicación cliente envía otro comando de 2 bytes indicando que va a indicar al dispositivo Ia IP externa desde Ia que se está conectando para que quede reflejada en los logs que almacena el dispositivo. Después de enviar los 2 bytes, envía una cadena de texto que refleja Ia IP, en formato xxx.xxx.xxx.xxx. En caso de que ambos envíos se realicen correctamente, se envía de nuevo un comando de 2 bytes al dispositivo que Ie indica que puede empezar con Ia comprobación de huella.
Cuarto El proceso del dispositivo se queda a Ia espera de que el usuario deslice su dedo por el lector de huellas. Una vez obtenida Ia imagen de mapa de bits de Ia huella del usuario, se trata y transforma como se ha indicado, se obtiene Ia huella registrada que hay almacenada en el chip criptográfico y se comparan. Si Ia comprobación es negativa, se informa a Ia aplicación, se corta Ia comunicación y el dispositivo vuelve a quedar nuevamente en modo de espera.
Quinto. Si Ia comprobación es positiva también se Ie hace saber a Ia aplicación. Además se genera un OneTimePassword dentro del dispositivo. Esta OneTimePassword está basada en el ID del dispositivo y en un contador de sesión,' que se combinan para generar una cadena de Ia que se puedan extraer ambos parámetros mediante un algoritmo por definir. Posteriormente se cifra con el mismo cifrado que se utiliza para el ID del dispositivo en comunicaciones anteriores, y se envía a Ia aplicación, que sin descifrarlo en ningún momento se Io hará llegar al servidor. En este momento el dispositivo considera que se ha iniciado correctamente Ia sesión y se queda a Ia espera ^de siguientes operaciones, como firma de transacciones u otras.
Sexto El servidor recibe ía OTP generada, Ia descifra y Ia comprueba. Para ello comprueba que el ID obtenido de esta password se corresponde con el ID del dispositivo que intenta hacer login, y que el contador de sesión asociado es posterior al último utilizado para hacer login. No es necesario que el contador de sesión sea el inmediatamente posterior, sino que basta con que sea mayor, debido a Ia infinidad de problemas que podrían obtenerse al utilizar este requisito tan estricto. Cuando el servidor ha comprobado positivamente esta OTP, se mostrará al usuario su entorno de cliente, puesto que se considera que ha realizado correctamente el login en el entorno.
Procesos posteriores al inicio de sesión: Una vez se ha iniciado sesión en el dispositivo, ésta permanecerá abierta hasta que, o bien Ia comunicación TCP se cierre, o bien se reciba un comando para terminar Ia sesión. Mientras tanto está escuchando a Ia espera de recibir otros comandos de operación. Cada comando está compuesto de 2 bytes, y son los siguientes. Hay que indicar que cada comando no es excluyente de los demás, es decir, que una vez iniciada Ia sesión es posible, por ejemplo, realizar 2 firmas de procesos, y posteriormente modificar Ia huella digital sin tener que volver a iniciar sesión, siempre que no se corte el canal TCP con Ia aplicación cliente.
- Firma de un conjunto de bytes. Cuando desde Ia página web se quiere realizar Ia firma de un proceso o documento, se Ie solicita a Ia aplicación cliente que Io haga. Ésta enviará el comando correspondiente al dispositivo a través de Ia comunicación TCP que mantiene establecida con él. Acto seguido debe enviar Ia longitud del contenido a firmar, y posteriormente el propio contenido. El dispositivo entonces accederá al chip criptográfico gracias al PIN, y obtendrá el fichero pfx que contiene tanto Ia clave privada como el certificado del usuario. Utilizará Ia clave privada para firmar el contenido mediante los algoritmos de hash SHA1 y de cifrado RSA, y devolverá a Ia aplicación cliente tanto esta firma como el certificado del usuario. La aplicación cliente Ie hará llegar ambos datos a Ia página web, que se encargará de enviárselos al servidor para su comprobación, tratado y almacenamiento.
- Actualización de software.
- Modificar huella digital. La aplicación cliente envía al dispositivo el comando para iniciar este proceso; éste queda a Ia espera de que el usuario deslice su dedo por el lector de huellas digitales, y almacena el resultado en el chip criptográfico. No se solicita Ia huella digital anterior registrada al usuario puesto que éste ya ha hecho login en el dispositivo y por tanto se ha verificado su identidad.
- Modificar certificado de usuario. Al igual que en el caso anterior, Ia aplicación cliente es Ia encargada de enviar al dispositivo tanto el comando necesario (2 bytes), como Ia longitud y el contenido del nuevo certificado. Una vez recibido éste, se almacenará en el chip criptográfico sustituyendo completamente al anterior certificado (y clave privada).
Posibilidades de uso adicionales al sistema de acceso a entornos seguros.
Partiendo de Ia misma solución y de los mismos procesos, este sistema de acceso a entornos telemáticos basado en huella digital y sistemas criptográficos también tiene otros usos claramente definidos como pueden ser:
- Sistema de medio de pago: Asociado a una pasarela de pago, esta solución puede servir para realizar pagos o cobros por medio de Internet, el sistema requeriría de los procesos descritos anteriormente para identificar al usuario en el entorno bancario y por medio de sistemas ya implementados las entidades bancarias realizar esas operaciones.
- Acceso a entornos corporativos: Usando los procesos descritos con anterioridad, Ia solución puede servir, a su vez, para permitir el acceso a entornos telemáticos corporativos por medio de ese dispositivo biométrico, siempre que implemente los contenidos de Ia solución descrita.
Así mismo, estos mismos procesos se pueden implementar para identificación de usuarios en entornos telemáticos de manera fiable y segura, con independencia del uso o aplicaciones a las que se quiera acceder, siempre y cuando , se implementen los componentes y los procesos descritos en este documento.
Otro elemento diferenciador es Ia capacidad multiusuario y multientidad, esto es, varios usuarios en el mismo dispositivo y un solo dispositivo para varias entidades bancarias. En el primer caso, multiusuario, el usuario se identificará unívocamente contra el servidor tras el deslizamiento de su huella debido a un identificador único de usuario igual al registrado en el servidor. Por otro lado Ia multientidad se consigue con el envío, por parte del applet, de un código de entidad que hace de puntero para que el dispositivo sepa los datos a entregar.

Claims

REIVINDICACIONES
1.- Sistema de control de acceso seguro en aplicaciones de tipo bancario o similar que comprende, al menos, un elemento servidor (1 ) u host configurado para contener toda Ia funcionalidad de Ia solución en comunicación con un entorno bancario (5), un dispositivo biométrico (2), un elemento cliente (3) y los elementos de comunicaciones (4) entre el elemento servidor (1) y el elemento cliente (3), caracterizado porque dichos elementos están configurados para que: un componente "applef integrado en el elemento servidor (1 ) inicie el proceso de control (41) pidiendo Ia autenticación (42) al dispositivo biométrico (2), efectuando Ia autenticación por medio de un certificado propio del dispositivo biométrico; una vez validado el dispositivo biométrico (2) éste solicita al usuario el dato biométrico (43), comprobándose dicho dato por comparación con el dato biométrico registrado en un proceso anterior y si el resultado es positivo se genera una contraseña (OTP) que se envía al elemento servidor (1 ) para que sea validada, informándose al entorno bancario (5) y respondiendo éste con el entorno personalizado al usuario (49) si Ia autenticación es positiva, presentándose dicho entorno en el elemento cliente (3), quedando el entorno cliente en un segundo plano frente al entorno bancario (5) que es quien mantiene el control sobre el estado de Ia sesión.
2.- Sistema de acuerdo con Ia reivindicación 1 caracterizado porque comprende una base de datos incluyendo toda Ia información asociada a cada dispositivo biométrico (2) comprendiendo dicha información, al menos, un campo común que identifique al usuario de forma única en los entornos servidor (1) y bancario (5).
3.- Sistema de acuerdo con Ia reivindicación 2 caracterizado porque dicha información se encuentra en forma de tablas, al menos una de usuarios (21 ), una de dispositivos (22) y una de versiones de Ia aplicación (23).
4.- Sistema de acuerdo con Ia reivindicación 1 caracterizado porque está configurado para firmar procesos digitalmente, y donde un elemento plugin integrado en el entorno usuario (3) inicia el proceso de firma (51) contra el servidor tradicional del banco (5), éste hace Ia petición de firma (52) contra el usuario a través del elemento applet y del dispositivo biométrico (2), donde se chequea dicho dato así como la firma del documento (53); y donde una vez se considera el documento firmado (54), se envía Ia firma (55) al elemento servidor (1 ), donde se almacena, y se ddaa L una respuesta, redirección y resultado (56) contra el servidor tradicional de banca (5).
5.- Sistema de acuerdo con Ia reivindicación 1 caracterizado porque el dispositivo biométrico (2) comprende, al menos: . un lector de huella digital y un elemento criptográfico configurado para comprender Jos elementos de seguridad cruciales para un escenario de acceso a entornos bancarios, tales como los datos personales del usuario incluidos Ia huella y su certificado digital; y un procesador y memoria configurados para ejecutar un sistema operativo , donde este sistema operativo es el encargado de comunicar y gestionar los distintos componentes del dispositivo, así como del acceso y Ia modificación de los datos personales almacenados en Ia memoria, y Ia comunicación con el elemento cliente (3).
6.- Sistema de acuerdo con Ia reivindicación 5 ¿ caracterizado porque el dispositivo biométrico (2) es un componente externo de tipo USB que se comunica con el elemento cliente (3) utilizando el protocolo IP sobre USB, de forma que el intercambio de paquetes se realiza mediante TCP definiéndose un formato de mensajes y datos cerrado.
7.- Sistema de acuerdo con Ia reivindicación 1 caracterizado porque las comunicaciones (4) entre el elemento cliente (3) y elemento servidor (1 ) se realiza mediante el protocolo HTTPS, cifrada extremo a extremo, siendo el elemento servidor (1 ) y el dispositivo biométrico (2) conectado con el elemento cliente (3), los encargados de las funciones criptográficas.
PCT/ES2009/000034 2009-01-23 2009-01-23 Sistema de control de acceso seguro WO2010084209A1 (es)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/ES2009/000034 WO2010084209A1 (es) 2009-01-23 2009-01-23 Sistema de control de acceso seguro
EP09838687A EP2391053A1 (en) 2009-01-23 2009-01-23 Secure access control system
US13/145,976 US20120054842A1 (en) 2009-01-23 2009-01-23 Secure access control system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/ES2009/000034 WO2010084209A1 (es) 2009-01-23 2009-01-23 Sistema de control de acceso seguro

Publications (1)

Publication Number Publication Date
WO2010084209A1 true WO2010084209A1 (es) 2010-07-29

Family

ID=42355569

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/ES2009/000034 WO2010084209A1 (es) 2009-01-23 2009-01-23 Sistema de control de acceso seguro

Country Status (3)

Country Link
US (1) US20120054842A1 (es)
EP (1) EP2391053A1 (es)
WO (1) WO2010084209A1 (es)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012050585A1 (en) 2010-10-15 2012-04-19 Hewlett-Packard Development Company, L.P. Authenticate a fingerprint image
US8776190B1 (en) * 2010-11-29 2014-07-08 Amazon Technologies, Inc. Multifactor authentication for programmatic interfaces
US20210234699A1 (en) * 2018-07-17 2021-07-29 Imageware Systems Inc. System and Method for Zero-Knowledge, Anonymous Verification and Management

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120084544A1 (en) * 2010-10-04 2012-04-05 Ralph Robert Farina Methods and systems for providing and controlling cryptographically secure communications across unsecured networks between a secure virtual terminal and a remote system
US8485442B2 (en) 2009-07-02 2013-07-16 Biometric Payment Solutions Electronic transaction verification system with biometric authentication
US8966101B2 (en) * 2009-08-10 2015-02-24 Sling Media Pvt Ltd Systems and methods for updating firmware over a network
US8799666B2 (en) 2009-10-06 2014-08-05 Synaptics Incorporated Secure user authentication using biometric information
US9870452B1 (en) * 2010-03-02 2018-01-16 Amazon Technologies, Inc. Assigning new passcodes to electronic devices
GB201109311D0 (en) * 2011-06-03 2011-07-20 Avimir Ip Ltd Method and computer program for providing authentication to control access to a computer system
US8943150B2 (en) 2011-09-12 2015-01-27 Fiserv, Inc. Systems and methods for customizing mobile applications based upon user associations with one or more entities
JP5899751B2 (ja) * 2011-09-28 2016-04-06 ソニー株式会社 情報処理装置、および情報処理方法、並びにプログラム
JP5936103B2 (ja) * 2011-10-04 2016-06-15 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ クライアントでＪａｖａメソッドを呼び出すシステム、コンピュータ、方法及びプログラム
US9003507B2 (en) * 2012-03-23 2015-04-07 Cloudpath Networks, Inc. System and method for providing a certificate to a third party request
RS54229B1 (en) 2012-06-14 2015-12-31 Vlatacom D.O.O. BIOMETRIC ACCESS CONTROL SYSTEM AND PROCEDURE
US9589399B2 (en) 2012-07-02 2017-03-07 Synaptics Incorporated Credential quality assessment engine systems and methods
US9390245B2 (en) 2012-08-02 2016-07-12 Microsoft Technology Licensing, Llc Using the ability to speak as a human interactive proof
US9391966B2 (en) * 2013-03-08 2016-07-12 Control4 Corporation Devices for providing secure remote access
WO2014154291A1 (en) * 2013-03-28 2014-10-02 Irdeto B.V. Protection of digital content
US9231765B2 (en) * 2013-06-18 2016-01-05 Arm Ip Limited Trusted device
US10250597B2 (en) * 2014-09-04 2019-04-02 Veridium Ip Limited Systems and methods for performing user recognition based on biometric information captured with wearable electronic devices
US9715621B2 (en) * 2014-12-22 2017-07-25 Mcafee, Inc. Systems and methods for real-time user verification in online education
CN106529963B (zh) * 2016-11-26 2018-02-16 浙江邦盛科技有限公司 一种用于移动设备安全认证的系统及方法
JP6340120B1 (ja) * 2017-06-16 2018-06-06 アイビーシー株式会社 デバイスプロビジョニングシステム
CN110750767B (zh) * 2019-10-18 2023-05-02 神州数码融信软件有限公司 智能终端设备的登录初始化方法及智能终端设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999008238A1 (en) * 1997-08-11 1999-02-18 International Business Machines Corporation A portable information and transaction processing system and method utilizing biometric authorization and digital certificate security
WO2003007538A1 (en) * 2001-07-12 2003-01-23 Icontrol Transactions, Inc. Operating model for mobile wireless network based transaction authentication and non-repudiation
US20040186912A1 (en) * 2003-03-20 2004-09-23 International Business Machines Corporation Method and system for transparently supporting digital signatures associated with web transactions
US20060242693A1 (en) * 2005-04-22 2006-10-26 Kussmaul John W Isolated authentication device and associated methods

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6848048B1 (en) * 2000-10-13 2005-01-25 Litronic Inc. Method and apparatus for providing verifiable digital signatures
CA2451491C (en) * 2001-07-18 2009-06-02 Daon Holdings Limited A distributed network system using biometric authentication access
US8127142B2 (en) * 2005-09-09 2012-02-28 University Of South Florida Method of authenticating a user on a network
US20070136573A1 (en) * 2005-12-05 2007-06-14 Joseph Steinberg System and method of using two or more multi-factor authentication mechanisms to authenticate online parties
TWI321731B (en) * 2006-09-18 2010-03-11 Quanta Comp Inc Device connection system and device connection method
EP2034458A3 (en) * 2007-03-09 2009-09-02 ActivIdentity, Inc. One-time passwords

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999008238A1 (en) * 1997-08-11 1999-02-18 International Business Machines Corporation A portable information and transaction processing system and method utilizing biometric authorization and digital certificate security
WO2003007538A1 (en) * 2001-07-12 2003-01-23 Icontrol Transactions, Inc. Operating model for mobile wireless network based transaction authentication and non-repudiation
US20040186912A1 (en) * 2003-03-20 2004-09-23 International Business Machines Corporation Method and system for transparently supporting digital signatures associated with web transactions
US20060242693A1 (en) * 2005-04-22 2006-10-26 Kussmaul John W Isolated authentication device and associated methods

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012050585A1 (en) 2010-10-15 2012-04-19 Hewlett-Packard Development Company, L.P. Authenticate a fingerprint image
EP2628133A4 (en) * 2010-10-15 2016-12-28 Hewlett Packard Development Co Lp AUTHENTICATION OF A DIGITAL FOOTPRINT IMAGE
US8776190B1 (en) * 2010-11-29 2014-07-08 Amazon Technologies, Inc. Multifactor authentication for programmatic interfaces
US10263978B1 (en) 2010-11-29 2019-04-16 Amazon Technologies, Inc. Multifactor authentication for programmatic interfaces
US20210234699A1 (en) * 2018-07-17 2021-07-29 Imageware Systems Inc. System and Method for Zero-Knowledge, Anonymous Verification and Management

Also Published As

Publication number Publication date
EP2391053A1 (en) 2011-11-30
US20120054842A1 (en) 2012-03-01

Similar Documents

Publication Publication Date Title
WO2010084209A1 (es) Sistema de control de acceso seguro
US11818274B1 (en) Systems and methods for trusted path secure communication
US11153076B2 (en) Secure communication for medical devices
US8261087B2 (en) Digipass for web-functional description
ES2739896T3 (es) Acceso seguro a datos de un dispositivo
KR101198120B1 (ko) 홍채정보를 이용한 양방향 상호 인증 전자금융거래시스템과 이에 따른 운영방법
BR112019022845B1 (pt) Método e sistema fornecendo um acesso seguro ao banco de dados
TWI708159B (zh) 包含安全處理器之裝置平台、裝置中之安全處理器、以及相關儲存媒體
JP2016531508A (ja) データセキュアストレージ
KR102514429B1 (ko) 생체인식 데이터 템플레이트의 업데이트
WO2004079988A1 (en) Secure object for convenient identification
KR101078546B1 (ko) 범용 저장장치의 식별정보를 기반으로 하는 보안 데이터 파일 암호화 및 복호화 장치, 그를 이용한 전자 서명 시스템
US20090217375A1 (en) Mobile Data Handling Device
JP2008226191A (ja) 情報処理端末認証システム及び情報処理端末認証方法，情報処理端末認証用プログラム
NO340355B1 (en) 2-factor authentication for network connected storage device
US7779452B2 (en) Computer access security
Song et al. Trustcube: An infrastructure that builds trust in client
CN111506915B (zh) 授权访问的控制方法、装置和系统
KR102288445B1 (ko) 단체용 인증모듈의 온보딩 방법, 장치 및 프로그램
KR20020053045A (ko) 공인인증서를 이용한 컴퓨터단말기 보안시스템 및 그 방법
ES2887902T3 (es) Autenticación de terminales
Mathisen Confidential
Stötzner Design of an Android App2App redirect flow for the FAPI 2.0 standard
Indushree et al. A novel Blockchain-based authentication scheme for telecare medical information system
La Lau et al. Secure Shell (SSH)

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09838687

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2009838687

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13145976

Country of ref document: US