WO2009103824A1 - Transferencia segura de datos - Google Patents

Transferencia segura de datos Download PDF

Info

Publication number
WO2009103824A1
WO2009103824A1 PCT/ES2008/000087 ES2008000087W WO2009103824A1 WO 2009103824 A1 WO2009103824 A1 WO 2009103824A1 ES 2008000087 W ES2008000087 W ES 2008000087W WO 2009103824 A1 WO2009103824 A1 WO 2009103824A1
Authority
WO
WIPO (PCT)
Prior art keywords
entity
secure channel
application
card
session
Prior art date
Application number
PCT/ES2008/000087
Other languages
English (en)
French (fr)
Inventor
Javier CAÑIS ROBLES
Po Yuan
Original Assignee
Microelectronica Española S.A.U.
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 Microelectronica Española S.A.U. filed Critical Microelectronica Española S.A.U.
Priority to EP08736691A priority Critical patent/EP2262164A1/en
Priority to US12/309,288 priority patent/US20110131640A1/en
Priority to PCT/ES2008/000087 priority patent/WO2009103824A1/es
Publication of WO2009103824A1 publication Critical patent/WO2009103824A1/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/3215—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 plurality of channels
    • 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/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • 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/321—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 a third party or a trusted authority
    • 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/80—Wireless

Definitions

  • the present invention relates to the field of information exchange between two entities and, more particularly, to the establishment of secure channels for the transfer of data between two entities through an unsecured medium.
  • TrustedFlash Security System System that is designed to improve the capabilities of flash memory card with a set of security features that enable the card to protect and control the use of stored data.
  • TrustedFlash provides several types of authentication algorithms and allows multiple authenticated entities to use the card concurrently.
  • the TrustedFlash security system allows you to configure a specific set of permissions (rights) for each of the authenticated entities.
  • Each order that is received by means of a flash memory module is associated with an entity authenticated at the present time, and the service request is validated against the rights registered for that entity.
  • the flash memory module authorizes the request and executes the order only if the service is allowed for the requesting entity.
  • TrustedFlash TM is a registered trademark of SanDisk Corporation.
  • TrustedFlash Card Memory card that supports TrustedFlash security technology.
  • Smart card, chip card or integrated circuit card defined as any pocket-sized card with built-in integrated circuits that can process information.
  • UICC Universal Integrated Circuit Card
  • the UICC In a GSM network, the UICC contains a SIM application and in a UMTS network it is the USIM application.
  • a UICC can contain several applications, making it possible for the same smart card to give access to both the GSM network and the network
  • UMTS and also provides storage of a phone book and other applications. It is also possible to access a GSM network using a USIM application and it is possible to access UMTS networks using a SIM application with mobile terminals prepared for this.
  • SIM Subscriber Identity Module
  • ICC Integrated Circuit Card
  • MNO Mobile Network Operator
  • GSM Global System for Mobile Communications
  • MNO Mobile communications network
  • USIM Universal Subscriber Identity Module
  • UICC Universal Integrated Circuit Card
  • SIM or a USIM card that additionally comprises a large amount of storage capacity (i.e., more than 128 Mbytes), typically a flash memory, which allows the subscriber and the MNO to store a large amount of information, such as video or images.
  • Large-Capacity Universal Integrated Circuit (UICC) or a MegaSIM card usually comprises a high-speed communications interface, such as USB, but is not limited to it, which allows offering services that involve a large exchange of information.
  • MegaSIM is a registered term (MegaSIM TM) by MSYSTEMS LTD. Kefar
  • FIG. 1 shows how two entities 110 120 can communicate securely through an unsecured communications medium 130 through the establishment of a secure channel
  • Safe channels like the one illustrated in Figure 1 can be implemented using different techniques cryptographic
  • the first secure channel was implemented in 1976, when two researchers proposed a key exchange technique, the so-called Diffie-Hellman (DH) key exchange.
  • DH Diffie-Hellman
  • This technique was based on an agreement between two entities in order to establish a password, which was only known by the two entities involved. Once the key was agreed by the two entities, encrypted data could be exchanged using the agreed key. In this way the risk of the interception of data transferred by third parties was avoided.
  • DH Diffie-Hellman
  • secure channels are those used in technologies such as IPsec, used to secure the Internet Protocol (IP); Transport Layer Security (TLS), used to provide secure communications to Internet technologies such as web browsers, email, fax or instant messaging over the Internet; and Global Platform, which defines a secure smart card infrastructure, which allows the secure and dynamic management of the card and its applications.
  • IPsec Internet Protocol
  • TLS Transport Layer Security
  • Global Platform which defines a secure smart card infrastructure, which allows the secure and dynamic management of the card and its applications.
  • the operation of the secure channel is mainly based on three processes: an authentication process, a session key agreement and a secure data transfer.
  • the authentication process involves mutual authentication between the two entities that will establish a secure channel.
  • This authentication can be based on shared secrets or credentials for symmetric algorithms or asymmetric algorithms based on, for example, public key infrastructures (PKI) (English, Public Key Infrastructures).
  • PKI public key infrastructures
  • Figure 2 shows an example of a symmetric authentication process, in which an entity B 220 is authenticated by an entity A 210.
  • Entity A 210 comprises a random number generator 211, a decryptor 212 based on a symmetric algorithm, a comparator 213 and a private key 214.
  • Entity B 220 comprises an encrypter 222 based on the same symmetric algorithm as that of entity A 220 and the same private key 224 as that of entity A 210.
  • Entity A 210 generates a random number using its random number generator 211 that is sent 250 to entity B 220.
  • Entity B 220 encrypts the number ⁇ received using its encryptor 222 with private key 224 and sends 260 the result to entity A 210.
  • Entity A 210 decrypts the number received using its decryptor 212 with private key 214 and sends the result to comparator 213, which compares the outputs of decryptor 212 and random number generator 211. If both inputs of comparator 213 are the same, then entity B 220 is authenticated by entity A 210. This is indicated to entity B 220. through an authentication result 270. In contrast to this, if both inputs of comparator 213 are not Likewise, entity B 220 is not authenticated by entity A 210. This is indicated to entity B 220 through an authentication result 270.
  • Figure 2 only shows authentication on one side, it can also be extended to the other. side.
  • asymmetric authentication protocol it usually uses Public Key Infrastructure (PKI) and RSA algorithms (Rivest, Shamir and Adleman). As defined by these algorithms, it is allowed and really Stimulates each part of the authentication process, so that it creates a single pair of RSA keys. Each key pair consists of public and private keys. The keys cannot provide proof of identity since the source of the keys is anonymous.
  • the PKI layer makes a call to a trusted third party, which signs each of the public keys.
  • the public key of the third party trust is pre-shared between the parties in charge of authenticating each other, and is used to verify the public keys. Once a trust is established (both parties involved have determined that the public key provided by the trusted third party can be trusted), the protocol continues with authentication by verifying that each party retains the matching private key . The keys are exchanged after the verification is completed.
  • FIG 3 shows an example of asymmetric authentication between a first entity A 310 and a second entity B 320 in collaboration with a third party 380 that both entities 310 320 have to rely on, based on the RSA algorithm mentioned above.
  • Each entity 310 320 comprises a pair of RSA keys, a public key (pkA 311 and pkB 321 respectively) and a private key (PkA 312 and PkB 322 respectively).
  • both entities comprise a SpkA 313 SpkB 323 signature of their public keys pkA 311 and pkB 321, which use the private key PkT 382 of the Third Party of trust 380 and the public key pkT 381 of the Third Party of trust 380 .
  • entity A 310 sends 350 its signed public key SpkA 313 to entity B 320, which verifies that third party 380 relies on public key pkA 311 using your public key pkT 381. If the verification is successful, the public key pkA 311 of entity A 310 is authenticated by entity B 320 and a result 355 is sent to entity A 310.
  • entity B 320 In order to authenticate your private key PkB 322, entity B 320 sends 360 a random number to entity A 310 that signs 315 said random number using its private key PkA 312 and sends result 365 to entity B 320, which verifies 328 the signed data received 365 using the key public pkA 311 of entity A 310, obtained previously, and compares 329 with the random number generated. If the comparison is successful, the private key is authenticated and a result 370 is sent to entity A 310. As in Figure 2, Figure 3 only shows authentication on one side, but could easily be extended to the other side as well.
  • the structure comprising the signed public key is preferably a certificate.
  • the trusted party 380 with the power to sign the certificate is preferably a Certification Authority (CA).
  • CA Certification Authority
  • the certificate must be signed by a Certification Authority (CA) trusted by the other authenticating party.
  • CA Certification Authority
  • the authenticating party is expected to hold the public key of the trusted CA.
  • Figure 4 shows an example of how session keys can be generated after symmetric authentication.
  • Random numbers are generated in both entities 410 420 through their respective random generators 411 421. These random numbers are encrypted 412 422 using a symmetric algorithm with the shared private key.
  • the results are sent 413 423 to the other entity 420 410, which performs an XOR operation between the random number received that is decrypted 414 424 and the number that was previously generated 411 421. On both sides, the result is the session key 415 425.
  • a confirmation of the session key 415 425 can be performed following, for example, the following steps: An entity 410 encrypts 417 a first shared string 416 with the session key 415 and sends 433 to the other entity 420, which decrypts 427 the received chain and compares it 428 with its first shared chain 426. Similarly, the other entity 420 encrypts a second shared chain 429 with session key 425 and sends 434 to the other side 410. The receiving entity 410 decrypts 418 the received chain and compares it 441 with its second shared chain 419. In case both comparisons are successful, the session key 415 425 is valid and the secure channel is created.
  • Figure 5 shows an example of session key generation after asymmetric authentication.
  • only one entity 520 generates 521 a random number 521 and uses the public key pkA 511 of the other entity 510 to encrypt 522 the random number.
  • the random number is sent 560 and 512 is decrypted on the other side 510 using its own private key PkA 513.
  • This random number which is now present in both entities, is the session key 514 524.
  • TrustedFlash a system that uses a secure channel mechanism
  • a secure flash memory card has the ability to identify the entity that is requesting a card service, where the entity is related to memory access or not.
  • TrustedFlash provides several types of authentication algorithms and allows multiple authenticated entities to concurrently use the card.
  • the TrustedFlash security system allows the configuration of a specific set of permissions (rights) for each of the authenticated entities.
  • Each order that receives the flash memory card is associated with a currently authenticated entity, and the service request is validated against the rights registered for that entity.
  • the card authorizes the request and executes the order only if the requesting entity has permission to use that service.
  • the authorization system supports several different kinds of services.
  • Flash memory cards are used as mass storage devices. Other types of Mass storage devices allow data to be stored in files that are organized through a file structure that is managed by an application server system (in English, "host system"). TrustedFlash cards follow this same storage procedure. However, TrustedFlash cards (TF cards) do not control the file system. Individual files can be encrypted with specific content keys in order to provide file-level protection.
  • the TrustedFlash authorization system provides the application of compliance with the read and write access rights to the content keys of the file. This protects the data by avoiding the use of data instead of access to the data.
  • Figure 6 shows a detailed diagram of a possible TrustedFlash service.
  • Entity A 610 is accessing protected content 655 that is stored on a TF 650 card.
  • an application server agent layer 620 is required; the application server agent layer 620 offers non-standard file system services to applications / entities.
  • the diagram shows authentication 660 and the establishment of secure channel 680 between entity A 610 (for example, a mobile terminal) and TF card 650. It also shows how protected data 655 within TF card 650 passes to be available to entity A 610 through secure channel 680.
  • the 615 credentials that are stored in entity A 610 allow access to various services and content.
  • a secure communication has been described between a first entity (for example, a mobile terminal) and a second entity (for example, a TrustedFlash card).
  • a second entity for example, a TrustedFlash card
  • This entity can be, for example, a smart card that, as it can be considered as a secure witness, allows to improve the security of the entire system.
  • the smart card may contain a credential required to access content stored on the TrustedFlash card, with the MNO to which the user of the mobile terminal is paid full control over the credentials. If you have to reproduce the content stored by means of an application that runs on the mobile terminal, such as a runtime application (“player application”), you have to retrieve the credential that is stored on the smart card.
  • a possible solution to this problem is that the mobile application retrieves the required content through the smart card. In this way, the mobile application requests the contents of the smart card and the smart card in turn, requests it from the TF card. In this way, the lack of visibility and control of the MNO is resolved.
  • a new problem arises regarding the operation, since it is much faster for the mobile application to recover the content directly from the TF card that the pass through the smart card, because the communications channel and the protocol to communicate with the smart card are very inefficient compared to the high-speed protocols used between the mobile application and the TF card.
  • the new approach allows the use of that secure channel established between a first entity and a second entity by that third entity, which the first or second entity relies on. It also allows the trusted third party (entity) to inherit some of the privileges of the trusted entity in that third trusted entity. These privileges allow the third entity to perform certain operations in relation to those first and second entities.
  • a secure data transfer procedure between entities includes: the establishment of a first secure channel between a first entity that has at least a first credential and a second entity that has at least a second credential; the establishment of a second secure channel between said first entity and a third entity, said third entity being a trusted entity for said first entity; through said second secure channel between said first entity and said third entity, delegate said first secure channel from said first entity to said third entity for data transfer between said second entity and said third entity.
  • the step of establishing said first secure channel comprises: authentication of the first entry by the second entity and vice versa, using the respective credentials of said first and second entities; the generation of session keys for each of the aforementioned first entity and second entity respectively; the establishment of the first safe channel mentioned. It also includes the assignment of privileges from the first entity to the second entity and vice versa.
  • said step of delegating said first secure channel comprises the steps of: requesting by the said third entity the delegation of a right to use said first secure channel; the passage from said first entity to said third entity of the session credentials required to use said first secure channel and to enable said third entity to communicate with said second entity.
  • Said required session credentials are at least one session key of said first secure channel.
  • the step of delegating the mentioned first secure channel optionally comprises the negotiation step between said first entity and said second entity to create at least one session credential for said third entity. It also includes the step of creating at least one session privilege for said third entity.
  • said second entity When said third entity accesses said second entity through said delegated secure channel, said second entity assigns at least one session privilege to said third entity, said at least one session privilege defining the processes and / or processes. data of said second entity to which access to said third entity is allowed through said delegated secure channel.
  • a secure data transfer procedure between entities comprising: establishing a first secure channel between an application running on a universal integrated circuit card having at least a first credential and a functionality of a non-volatile memory card that has at least a second credential; the establishment of a second secure channel between said application that runs on a universal integrated circuit card and an application that runs on a mobile terminal, said application being run on a trusted mobile terminal for said application that runs on a universal integrated circuit card; through the said second secure channel between said application running on a universal integrated circuit card and said application running on a mobile terminal, the delegation of said first secure channel from said application running on a card from Universal integrated circuit to the aforementioned application running in a mobile terminal for data transfer between the aforementioned functionality of a non-volatile memory card and the mentioned application running in a mobile terminal.
  • said functionality of a non-volatile memory card is firmware, hardware or a combination thereof.
  • said non-volatile memory card is a TrustedFlash card. Said Trusted Flash card is placed inside said mobile terminal.
  • Said second secure channel is established between said application running on said universal integrated circuit card and said application running on said mobile terminal, the said application running on said mobile terminal requiring access to the protected content found within the aforementioned Trusted Flash card.
  • Said delegated secure channel is established between the aforementioned application running on said mobile terminal and the aforementioned functionality of said TrustedFlash card through a proxy application (a proxy is a server that allows other computers to connect to a network of indirectly through it) located within the aforementioned mobile terminal.
  • a proxy application a proxy is a server that allows other computers to connect to a network of indirectly through it located within the aforementioned mobile terminal.
  • a system comprising a first entity, a second entity and a third entity. Understand: a means to establish a first secure channel between said first entity and said second entity; a means for establishing a second secure channel between said first entity and said third entity, said third trusted entity being for said first entity; a means for delegating said first secure channel through said second secure channel between said first entity and said third entity.
  • a system comprising an application that runs on a universal integrated circuit card, a functionality of a non-volatile memory card and an application that runs on a mobile terminal.
  • the system comprises: a means for establishing a first secure channel between said application running on a universal integrated circuit card and said functionality of a non-volatile memory card; a means for establishing a second secure channel between said application running on a universal integrated circuit card and said application running on a mobile terminal, said application running on a mobile terminal being trusted by said application that runs on a universal integrated circuit card; a means for delegating said first secure channel through said second secure channel between said application running on a universal integrated circuit card and said application running on a mobile terminal.
  • said non-volatile memory card is a TrustedFlash card.
  • the aforementioned TrustedFlash card is located inside the mentioned mobile terminal.
  • a computer program is provided comprising a computer program code adapted to perform the steps of the above-mentioned procedure when said program is executed on a smart card, a computer, a digital signal processor, an array of field-programmable doors, an application-specific integrated circuit, a microprocessor, a microcontroller or any other form of programmable hardware.
  • Figure 1 shows how two entities can communicate securely through an unsecured communications medium by establishing a secure channel.
  • Figure 2 shows an example of a process of symmetric authentication
  • Figure 3 shows an example of an asymmetric authentication process.
  • Figure 4 shows an example of how session keys can be generated after symmetric authentication.
  • Figure 5 shows an example of session key generation after asymmetric authentication.
  • Figure 6 shows a diagram of a possible TrustedFlash service.
  • Figure 7 represents an example embodiment showing how the secure transfer of data between entities is carried out.
  • Figure 8 represents another exemplary embodiment showing how the secure transfer of data between entities is carried out.
  • Figure 9 shows a flow chart indicating the steps carried out between the entities of Figure 8 in order to ensure the secure transfer of data.
  • Figure 7 shows how a secure delegated channel is established.
  • Figure 7 shows three entities: a first entity 710, a second entity 720 and a third entity 780.
  • entities are: According to where they can be executed: a smart card application, a SIM card application, an application UICC, a RUIM application, a USIM application, an ISIM application, a Java card application, a UICC Toolset application (in English, "UICC Toolkit application"), a mobile application, a non-volatile memory functionality, a functionality of a TrustedFlash card, a personal computer application and an MNO server application ("MoJbile Network Operator").
  • a smart card application a SIM card application, an application UICC, a RUIM application, a USIM application, an ISIM application, a Java card application, a UICC Toolset application (in English, "UICC Toolkit application"), a mobile application, a non-volatile memory functionality, a functionality of a TrustedFlash
  • a server application a Smart Card Web Server application
  • SCWS Smart Card Web Server
  • a servlet program that runs on a server on the context of a browser
  • a client application for example, a browser
  • the first entity 710 comprises at least a first credential 7101.
  • the second entity 720 comprises at least a second credential 7201.
  • Non-limiting examples of the credentials comprised in any of these entities are keys, such as symmetric keys and asymmetric keys. The calculation of such credentials is beyond the scope of this description.
  • a secure channel 740 is established between the first entity 710 and the second entity 720.
  • the step of establishing this secure channel 740 comprises an authentication step between the first entity 710 and the second entity 720.
  • This authentication is mutual: the first entity 710 authenticates the second entity 720 and vice versa. This is done by using the respective credentials 7101 7102 of the two entities 710 720. That authentication is a conventional authentication, carried out as explained in the prior art section.
  • the step of establishing this secure channel 740 also includes, once the mutual authentication between the first entity 710 and the second entity 720 has been done, a session key generation step (which is not illustrated in Figure 7). Both the first entity 710 and the second entity 720 generate session keys. This session key generation is done in accordance with any conventional way of generating said keys, as mentioned in the prior art section. Each session has its own specific session key, with each of the keys being generated independently on each side but whose key value is the same. The life of these session keys ends with the end of the session. The credentials of an entity, however, remain the same. Once entities are authenticated and session keys are generated, secure channel 740 is established.
  • each 710 720 entity assigns privileges (not illustrated in Figure 7) to the other entity.
  • the privileges can be either access to data or access to a process.
  • the privileges that this functionality can assign to other entities are access to part of its data (because the memory card does not include processes).
  • the privileges that can be assigned to other entities are access to some processes. These privileges therefore define the processes and data of an entity that can be accessed by the other entity.
  • the third entity 780 of Figure 7 is a trusted entity for the first entity 710. This means that the third entity has the credential that allows the first entity, after an authentication process, to know that this third entity is an entity safe without malicious purpose and that follows the procedures under the security policy of the first entity.
  • the process of trust in this third entity 780 by the first entity 710 is outside the scope of this description. It is done through any conventional way of trust between entities.
  • the secure channel 740 can be established first between the first entity 710 and the second entity 720, or the secure channel 750 can be established first between the first entity 710 and the third entity 780, or both secure channels 740 750 can be established in parallel . In order to complete the delegation, both channels must already be established.
  • the third entity 780 in which the first entity 710 relies but in which the second entity 720 does not trust, asks the entity that relies on it to delegate the secure channel 740 established between the first entity 710 and the second entity 720.
  • the first entity 710 passes to the third entity 780 the session credentials (not illustrated in Figure 7) required in order to use the first secure channel and to be able to communicate with the second entity 720.
  • these session credentials may be the session keys of the secure channel 740 established between the first entity 710 and the second entity 720 or different session keys agreed between the first and the second entities during the negotiation process of the delegation.
  • a delegation must be interpreted as the passage from one entity A to another entity C session credentials necessary to use a secure channel established between that entity A and another entity B, so that entity C is able to use that secure channel and thus communicate with that entity B.
  • it may also comprise a negotiation between entity A and entity B in order to establish a credential and session privileges to be used by entity C in the channel sure. In this way the delegation of the first secure channel 740 is established.
  • the step of delegating the first secure channel 740 to the third entity 780 comprises a negotiation stage between the first entity 710 and the second entity 720, to create at least one session credential (not illustrated in Figure 7) for the third entity 780.
  • This negotiation is as follows: the first entity 710 sends a command to the second entity 720, asking for the particular privileges to be assigned to the third entity 780. If the second entity 720 agrees with the request, includes, in its response to the command, a session credential that is internally associated within the second entity 720 with the requested privileges, to be assigned to the third entity 780. From that, at least one, session credential, a session privilege can be created (not illustrated in Figure 7).
  • This session privilege is agreed between the first entity 710 and the second entity 720 and is assigned to the third entity 780 when accessing the second entity 720.
  • a privilege is the access rights to certain data or processes.
  • the second entity 720 assigns at least one session privilege to the third entity 780.
  • This session privilege defines the processes or data of the second entity 720 that is allowed access to the third entity 780.
  • These session privileges may be of the same level as the privileges assigned by the second entity 720 to the first entity 710, or of a lower level.
  • the delegation of secure channel 740 is only valid during the current secure channel session (first secure channel) established between the first entity 710 and the second entity 720. Session credentials are only valid as long as it is I live the first secure channel. In the event that the trusted entity 780 requires them in another session, it is required to obtain a new session credential or new session credentials from the trusted entity. This establishes delegated secure channel 790.
  • a system which has a first entity 710, a second entity 720 and a third entity 780.
  • the system comprises means for establishing a first secure channel 740 between The first entity 710 and the second entity 720. It also comprises a means for establishing a second secure channel 750 between the first entity 710 and the third entity 780, for which the third entity 780 has previously become a trusted entity for the first entity 710.
  • the system also comprises means for delegating the first secure channel 740 through the second secure channel 750 between the first entity 710 and the third entity 780.
  • a computer program comprising a computer program code adapted to perform the steps of delegating a secure channel, when the program is executed on a smart card, a computer, a digital signal processor, a field programmable door array, an application-specific integrated circuit, a microprocessor, a microcontroller or any other form of programmable hardware.
  • Figure 8 is related to another embodiment that describes how a delegated secure channel is established.
  • Figure 8 shows three entities: a first entity 810, which in this particular embodiment is an application that runs on a universal integrated circuit card 810, such as a SIM card or a USIM card; a second entity 820, which in this particular embodiment is a functionality of a non-volatile memory card 820, such as a TrustedFlash card; and a third entity 880, which in this particular embodiment is an application 882 running on a mobile terminal 880.
  • a first entity 810 which in this particular embodiment is an application that runs on a universal integrated circuit card 810, such as a SIM card or a USIM card
  • a second entity 820 which in this particular embodiment is a functionality of a non-volatile memory card 820, such as a TrustedFlash card
  • a third entity 880 which in this particular embodiment is an application 882 running on a mobile terminal 880.
  • the application running on the universal integrated circuit card (UICC) 810 It comprises at least one credential 8101.
  • the functionality of the non-volatile memory card 820 comprises at least one credential 8201.
  • Non-limiting examples of the credentials included in any of these entities are keys, such as symmetric keys and asymmetric keys, whose creation is It is beyond the scope of this description.
  • a secure channel 840 is established between the application running in the UICC 810 and the functionality of the non-volatile memory card 820.
  • the setting step of this secure channel 840 comprises a mutual authentication step between both entities . This is done by using the respective credentials 8101 8201 of the two entities.
  • the setting step of this secure channel 840 also includes, once authentication has been made between the application running in the UICC 810 and the functionality of the non-volatile memory card 820, a session key generation step by both entities.
  • This session key generation is done in accordance with any conventional way of generating said keys, as mentioned in the prior art section.
  • Each session has its own specific session keys. The life of these session keys ends with the end of the session.
  • the at least one, credential 8101 8201 of each entity remains the same.
  • Non-limiting examples of the session keys that can be generated when the secure channel 840 is established are: symmetric and asymmetric keys.
  • the application in UICC 810 assigns privileges to the functionality of the 820 non-volatile memory card and vice versa.
  • the privileges (not illustrated in Figure 8) assigned to the non-volatile memory card 820 by the application running in the UICC 810 are: access to some UICC files and the UICC application.
  • the privileges assigned to the application running in UICC 810 by the functionality of the 820 non-volatile memory card are permissions to access part of the data stored in the non-volatile memory card. These privileges therefore define the data of the non-volatile memory card that can be accessed by the application running in the UICC.
  • the application 882 running on the mobile terminal 880 of Figure 8 is trusted for the application running on the UICC 810.
  • secure channel 840 is established between the application running on the UICC 810 and the functionality of the non-volatile memory card 820
  • a second secure channel 850 is established between the application running in the UICC 810 and the application 882 running in a mobile terminal 880.
  • the establishment of this second secure channel 850 is carried carried out in the same manner as the establishment of the first secure channel 840, mutatis mutandis.
  • the secure channel 840 can first be established between the application running on the UICC 810 and the functionality of the non-volatile memory card 820, or the secure channel 850 can first be established between the application running on the UICC 810 and the application 882 running on a mobile terminal 880, or both secure channels 840 850 can be established in parallel.
  • the application 882 running on the mobile terminal 880 which the application relies on which runs on UICC 810 but does not rely on the functionality of the 820 non-volatile memory card, asks the application that runs on the UICC the delegation of the right to use the secure channel 840 established between the application that is It runs on the UICC and the functionality of the 820 non-volatile memory card.
  • the application that runs on the UICC 810 passes to the application 882 running on the mobile terminal 880 session credentials (which not shown in Figure 8) required in order to use secure channel 840 and to be able to communicate with the functionality of non-volatile memory card 820.
  • Non-limiting examples of these session credentials may be the session keys of the secure channel 840 established between the application running on UICC 810 and the functionality of the 820 non-volatile memory card. Therefore, a delegation must be understood as the step from an application that It is executed in the UICC 810 to another application 882 running in the mobile terminal 880 of session credentials necessary to use the secure channel 840 established between that application running in the UICC 810 and the memory card functionality not volatile 820, so that that application running on the mobile terminal 880 is able to use that secure channel and in this way communicate with that non-volatile memory card 820. In this way the delegation of the first secure channel 840 is established.
  • the step of delegating the first secure channel 840 to the application 882 running on a mobile terminal 880 comprises an optional negotiation step between the application running on the UICC 810 and the functionality of the 820 non-volatile memory card, to create at least one session credential (not illustrated in Figure 8) for the application running on mobile terminal 880.
  • at least one, session credential a session privilege can be created (not illustrated in Figure 8).
  • application 882 running on mobile terminal 880 accesses the functionality of nonvolatile memory card 820 through delegated secure channel 890, nonvolatile memory card 820 assigns at least one session privilege to application 882 running on mobile terminal 880.
  • This session privilege defines the functionality data of the non-volatile memory card 820 that can be accessed by application 882 running on mobile terminal 880.
  • a Mobile terminal application can access a memory file, such as a movie file or an mp3 file, that is protected, and the privileges to access this file are associated with the session credential used by the mobile terminal application.
  • These privileges (which are not illustrated in Figure 8) can be of the same level as those assigned by the functionality of the non-volatile memory card 820 to the application running in UICC 810, or of a lower level.
  • Delegation of secure channel 840 is only valid until the channel that was delegated is terminated.
  • the secure channel is terminated when one of the entities wishes to terminate the communication by means of a specific secure channel command (that is, a terminating secure channel command) or when one of the entities realizes that the other entity is missing operational or when one of the entities realizes that an error has occurred in communications or a security issue has occurred in the secure channel or others.
  • a specific secure channel command that is, a terminating secure channel command
  • the session credentials that are obtained through the application 882 running on the mobile terminal 880, which is trusted by the application running on the UICC 810 can only be used during the current session.
  • the trusted application 882 running on the mobile terminal 880 requires them in another session, it is required to obtain a new session credential or new session credentials from the application running in UICC 810 ( trust entity).
  • the second secure channel 850 is established between an application that runs on the universal integrated circuit card 810 and an application 882 that runs on the mobile terminal 880.
  • This application 882 requires access to protected content 825 located within the card 820 non-volatile memory.
  • this 820 non-volatile memory card is a TrustedFlash 820 card.
  • this delegated secure channel 890 is established between the application running on the mobile terminal and the TrustedFlash card 820 through a proxy application 887 located inside the mobile terminal 880.
  • the proxy acts as a protocol converter, converting the protocol used in the communication between the application running in UICC 810 and the application that is Run the protocol used between the functionality of the TrustedFlash card and the application running on the terminal on the mobile terminal 880 880 mobile, and vice versa.
  • application 882 running on mobile terminal 880 attempts to read the contents of a public partition of the card TrustedFlash 820, for which the 882 application has established a connection with a TrustedFlash 820 card functionality using the standard file system functionality of the mobile terminal.
  • application 882 can access and use that content. This is indicated in blocks 902 903.
  • the application 882 If, however, the content is protected by encryption, the application 882 is not allowed to access that protected content 825. Then, the question that arises is whether the application 882 has or not the credential or credentials required to register to the functionality of the TrustedFlash 820 card (which protects the 825 content). This is indicated in block 904.
  • application 882 If application 882 has those required credentials, it registers - establishes a channel. secure using the credential for the authentication phase with the functionality of the TrustedFlash card that protects the content - in the functionality of the TrustedFlash 820 card that protects that content. This creates a secure channel between application 882 and the functionality of the TrustedFlash 820 card. This is indicated in block 905. Through that secure channel, application 882 can retrieve that content in open without coding, as is shown in block 906. Finally, application 882 may use that content for any purpose, as indicated in block 907.
  • application 882 does not have those required credentials, it cannot be registered in the functionality of the TrustedFlash 820 card that protects the desired content 825. Then, it is checked whether the application that runs on UICC 810 has these required credentials or not. If the application running on UICC 810 does not have those required credentials, then application 882 cannot access the desired content. This is indicated in blocks 908 909.
  • application 882 establishes a secure channel 850 with the application running in UICC 810. This is indicated in block 910. Through this secure channel 850, application 882 asks the application to run in UICC 810 the Delegation of another secure channel with card functionality
  • TrustedFlash 820 that protects the desired content 825, as indicated in block 911.
  • the application running on UICC 810 establishes a secure channel 840 with the functionality of the TrustedFlash 820 card (which protects the desired content 825).
  • This establishment of secure channel 840 between the application running on UICC 810 and the functionality of the TrustedFlash 820 card includes mutual authentication between the two and the generation of session keys (by both). This is indicated in block 914.
  • These session credentials are preferably session keys (temporary, or what is the same, that last as long as the corresponding session is kept alive).
  • an optional negotiation is made between the application running on UICC 810 and the functionality of the TrustedFlash 820 card, as indicated by block 915, to decide which session credentials and what session privileges are given to application 882 to delegate secure channel 840. This is indicated by block 915.
  • secure channel 840 is delegated to application 882
  • this application 882 retrieves protected content 825 through the delegated secure channel. As indicated in block 917, application 882 may use said content 825 for any purpose.
  • the establishment of the secure channel (block 914) between the application running in the UICC (810) and the functionality of the TrustedFlash 820 card can be carried out before the request (block 911) by the application 882 to establish a secure channel with the functionality of the TrustedFlash 820 card.
  • the establishment of the secure channel (block 914) between the application running in the UICC and the functionality of the TrustedFlash 820 card can also be carried out before establishment (block 910) by the application 882 of a secure channel with the application that runs in the UICC (810).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Storage Device Security (AREA)

Abstract

Un procedimiento de transferencia segura de datos entre entidades, que comprende: el establecimiento de un primer canal seguro (740, 840) entre una primera entidad (710, 810) que tenga al menos una primera credencial (7101, 8101) y una segunda entidad (720, 820) que tenga al menos una segunda credencial (7201, 8201); el establecimiento de un segundo canal seguro (750, 850) entre la mencionada primera entidad (710, 810) y una tercera entidad (780, 880), la mencionada tercera entidad (780, 880) siendo de confianza para la mencionada primera entidad (710, 810); a través del mencionado segundo canal seguro (750, 850) entre la mencionada primera entidad (710, 810) y la mencionada tercera entidad (780, 880), la delegación (790, 890) del mencionado primer canal seguro (740, 840) desde la mencionada primera entidad (710, 810) a la mencionada tercera entidad (780, 880) para la transferencia de datos entre la mencionada segunda entidad (720, 820) y la mencionada tercera entidad (780, 880).

Description

TRANSFERENCIA SEGURA DE DATOS
CAMPO DE LA INVENCIÓN
La presente invención está relacionada con el campo del intercambio de información entre dos entidades y, de manera más particular, con el establecimiento de canales seguros para la transferencia de datos entre dos entidades a través de un medio no seguro.
ESTADO DE LA TÉCNICA
En el contexto de la presente descripción, los siguientes términos y expresiones se pueden interpretar como se declara a continuación:
Sistema de Seguridad TrustedFlash: Sistema que está diseñado para mejorar las capacidades de tarjeta de memoria flash con un conjunto de características de seguridad que habilitan a la tarjeta para proteger y para controlar el uso de los datos almacenados. TrustedFlash proporciona varios tipos de algoritmos de autenticación y permite que múltiples entidades autenticadas usen de manera concurrente la tarjeta. El sistema de seguridad TrustedFlash permite configurar un conjunto especifico de permisos (derechos) para cada una de las entidades autenticadas. Cada orden que se recibe por medio de un módulo de memoria flash está asociado con una entidad autenticada en el momento presente, y la petición de servicio se valida frente a los derechos registrados para esa entidad. El módulo de memoria flash autoriza la petición y ejecuta la orden solamente si el servicio está permitido para la entidad solicitante. TrustedFlash™ es una marca registrada de SanDisk Corporation. Tarjeta TrustedFlash: Tarjeta de memoria que soporta tecnología de seguridad TrustedFlash.
Tarjeta inteligente, tarjeta de chip o tarjeta de circuito integrado (ICC) : se define como cualquier tarjeta de tamaño de bolsillo con circuitos integrados incorporados que pueden procesar información.
UICC (Tarjeta de Circuito Integrado Universal (del inglés Universal Integrated Circuit Card) ) : es la tarjeta inteligente, tarjeta de chip o tarjeta de circuito integrado usada en terminales móviles en redes GSM y UMTS.
En una red GSM, la UICC contiene una aplicación SIM y en una red UMTS es la aplicación USIM. Una UICC puede contener varias aplicaciones, haciendo posible que la misma tarjeta inteligente dé acceso tanto a la red GSM como a la red
UMTS, y también proporciona almacenamiento de una agenda telefónica y otras aplicaciones. También es posible acceder a una red GSM usando una aplicación USIM y es posible acceder a redes UMTS usando una aplicación SIM con terminales móviles preparados para esto.
SIM (Módulo de Identidad de Abonado (del inglés Subscríber Identíty Module) ) : es parte de una tarjeta inteligente extraible o ICC (Tarjeta de Circuito Integrado) , también conocida como tarjeta SIM, para los dispositivos de telefonía móvil celular tales como ordenadores móviles y teléfonos móviles. Está gestionada por un operador de red móvil (del inglés, "Mobile Network Operador", MNO) GSM (Sistema Global para Comunicaciones Móviles, (del inglés Global System for Mobile Communications) ) y comprende un módulo para identificar a un abonado que acceda a una red de comunicaciones móviles (MNO) . También es capaz de almacenar la información de abonado, tal como su agenda o sus mensajes de texto. USIM (Módulo de Identidad de Abonado Universal (del inglés Universal Subscriber Identity Module) ) : Una aplicación para telefonia móvil UMTS que se ejecuta sobre una UICC (Tarjeta de Circuito Integrado Universal (del inglés Universal Integrated Circuit Card) ) , también conocida como tarjeta USIM, que se inserta en un teléfono móvil 3G.
Tarjeta MegaSIM: Tarjeta de Circuito Integrado Universal (UICC) de Alta Capacidad. En otras palabras, es una tarjeta
SIM o una tarjeta USIM que comprende de manera adicional una gran cantidad de capacidad de almacenamiento (es decir, más de 128 Mbytes) , típicamente una memoria flash, que permite al abonado y al MNO almacenar una gran cantidad de información, tal como video o imágenes. Una Tarjeta de
Circuito Integrado Universal (UICC) de gran capacidad o una tarjeta MegaSIM por lo general comprende una interfaz de comunicaciones de alta velocidad, tal como USB, pero no se limita a ésta, lo que permite el ofrecer servicios que implican un gran intercambio de información. MegaSIM es un término registrado (MegaSIM™) por MSYSTEMS LTD. , Kefar
Saba, Israel.
Cuando se conectan dos entidades por un medio de comunicaciones no seguro, se puede establecer un canal seguro sobre ese medio de comunicaciones no seguro con el fin de transferir datos mientras se proporciona resistencia a la interceptación o a la manipulación. La figura 1 muestra cómo dos entidades 110 120 pueden comunicarse de manera segura a través de un medio de comunicaciones no seguro 130 por medio del establecimiento de un canal seguro
140.
Los canales seguros como el que se ilustra en la figura 1 se pueden implementar usando diferentes técnicas criptográficas. El primer canal seguro se implemento en 1976, cuando dos investigadores propusieron una técnica de intercambio de clave, el denominado intercambio de clave Diffie-Hellman (D-H) . Esta técnica se basaba en un acuerdo entre dos entidades con el fin de establecer una clave, que solamente era conocida por las dos entidades implicadas. Una vez que se acordaba la clave por las dos entidades, se podian intercambiar datos encriptados usando la clave acordada. De esta manera se evitaba el riesgo de la interceptación de los datos transferidos por terceras partes .
Otros ejemplos de canales seguros son aquéllos usados en tecnologías como IPsec, usados para asegurar el protocolo de Internet (en inglés Internet Protocol, IP) ) ; seguridad de capa de transporte (en inglés Transport Layer Security (TLS) ) , usados para proporcionar comunicaciones seguras a las tecnologías de Internet como los navegadores web, correo electrónico, fax o mensajería instantánea por Internet; y Plataforma Global, que define una infraestructura de tarjeta inteligente segura, lo que permite la gestión segura y dinámica de la tarjeta y de sus aplicaciones .
El funcionamiento del canal seguro se basa principalmente en tres procesos: un proceso de autenticación, un acuerdo de claves de sesión y una transferencia segura de datos.
El proceso de autenticación implica la autenticación mutua entre las dos entidades que van a establecer un canal seguro. Esta autenticación se puede basar en secretos o credenciales compartidos para algoritmos simétricos o en algoritmos asimétricos basados en, por ejemplo, infraestructuras de clave pública (PKI) (del inglés, Public Key Infrastructures) .
La figura 2 muestra un ejemplo de proceso de autenticación simétrica, en el que una entidad B 220 es autenticada por una entidad A 210. La entidad A 210 comprende un generador de números aleatorios 211, un desencriptador 212 basado en un algoritmo simétrico, un comparador 213 y una clave privada 214. La entidad B 220 comprende un encriptador 222 basado en el mismo algoritmo simétrico que el de la entidad A 220 y la misma clave privada 224 que la de la entidad A 210. La entidad A 210 genera un número aleatorio usando su generador de números aleatorios 211 que se envia 250 a la entidad B 220. La entidad B 220 encripta el número ^recibido usando su encriptador 222 con la clave privada 224 y envia 260 el resultado a la entidad A 210. La entidad A 210 desencripta el número recibido usando su desencriptador 212 con la clave privada 214 y envia el resultado al comparador 213, que compara las salidas del desencriptador 212 y del generador de números aleatorios 211. Si ambas entradas del comparador 213 son iguales, entonces la entidad B 220 es autenticada por la entidad A 210. Esto es indicado a la entidad B 220. a través de un resultado de autenticación 270. En contraposición con esto, si ambas entradas del comparador 213 no son iguales, la entidad B 220 no es autenticada por la entidad A 210. Esto es indicado a la entidad B 220 a través de un resultado de autenticación 270. Aunque la figura 2 solamente muestra la autenticación en un lado, se puede ampliar también al otro lado.
En lo que se refiere al protocolo de autenticación asimétrico, por lo general utiliza Infraestructura de Clave Pública (PKI) (del inglés, Public Key Infrastructure) y algoritmos RSA (Rivest, Shamir y Adleman) . Como se define por medio de estos algoritmos, se permite y realmente se estiπiula a cada parte del proceso de autenticación, para que cree un único par de claves RSA. Cada par de claves consiste en claves pública y privada. Las claves no pueden proporcionar prueba de identidad ya que la fuente de las claves es anónima. La capa PKI hace una llamada a una tercera parte de confianza, que firma cada una de las claves públicas. La clave pública de la de la tercera parte de confianza es precompartida entre las partes que están a cargo de autenticar unas a otras, y se usa para verificar las claves públicas. Una vez que se establece una confianza (ambas partes implicadas han determinado que se puede confiar en la clave pública proporcionada por la tercera parte de confianza) , el protocolo continúa con la autenticación por medio de la verificación de que cada parte conserva la clave privada coincidente. Las claves se intercambian después de que se completa la verificación.
La figura 3 muestra un ejemplo de autenticación asimétrica entre una primera entidad A 310 y una segunda entidad B 320 en colaboración con una tercera parte 380 en la que tienen que confiar ambas entidades 310 320, basándose en al algoritmo RSA anteriormente mencionado. Cada entidad 310 320 comprende un par de claves RSA, una clave pública (pkA 311 y pkB 321 respectivamente) y una clave privada (PkA 312 y PkB 322 respectivamente) . De manera adicional, ambas entidades comprenden una firma SpkA 313 SpkB 323 de sus claves públicas pkA 311 y pkB 321, que usan la clave privada PkT 382 de la Tercera Parte de confianza 380 y la clave pública pkT 381 de la Tercera Parte de confianza 380.
Como se ilustra en la figura 3, para realizar la autenticación, la entidad A 310 envia 350 su clave pública firmada SpkA 313 a la entidad B 320, que verifica que la tercera parte 380 confia en la clave pública pkA 311 usando su clave pública pkT 381. Si la verificación tiene éxito, la clave pública pkA 311 de la entidad A 310 es autenticada por la entidad B 320 y se envia un resultado 355 a la entidad A 310. Con el fin de autenticar su clave privada PkB 322, la entidad B 320 envia 360 un número aleatorio a la entidad A 310 que firma 315 dicho número aleatorio usando su clave privada PkA 312 y envia el resultado 365 a la entidad B 320, que verifica 328 los datos firmados recibidos 365 usando la clave pública pkA 311 de la entidad A 310, obtenida con anterioridad, y la compara 329 con el número aleatorio generado. Si la comparación tiene éxito, se autentica la clave privada y se envia un resultado 370 a la entidad A 310. Como en la figura 2, la figura 3 solamente muestra la autenticación en un lado, pero podria ampliarse fácilmente también al otro lado.
La estructura que comprende la clave pública firmada es de manera preferible un certificado. La parte de confianza 380 con el poder de firmar el certificado es de manera preferible una Autoridad de Certificación (CA) (del inglés Certifícate Authority) . Con el fin de que una parte sea autenticada, debe tener un par de claves RSA y un certificado que dé fe de la autenticidad de la clave pública. El certificado debe estar firmado por una Autoridad de Certificación (CA) en la que confia la otra parte autenticadora . Se espera que la parte autenticadora posea la clave pública de la CA de confianza. Una vez realizado el proceso de autenticación y antes de establecer el canal seguro, se tienen que generar las claves de sesión y se tienen que acordar por ambas entidades.
La figura 4 muestra un ejemplo de cómo se pueden generar claves de sesión después de una autenticación simétrica. Se generan números aleatorios en ambas entidades 410 420 por medio de sus respectivos generadores aleatorios 411 421. Estos números aleatorios se cifran 412 422 usando un algoritmo simétrico con la clave privada compartida. Los resultados se envian 413 423 a la otra entidad 420 410, que realiza una operación XOR entre el número aleatorio recibido que es descifrado 414 424 y el número que se generó con anterioridad 411 421. En ambos lados, el resultado es la clave de sesión 415 425. Tras esto, se puede realizar una confirmación de la clave de sesión 415 425 siguiendo, por ejemplos, los siguientes pasos: Una entidad 410 cifra 417 una primera cadena compartida 416 con la clave de sesión 415 y se envia 433 a la otra entidad 420, que desencripta 427 la cadena recibida y la compara 428 con su primera cadena compartida 426. De manera análoga, la otra entidad 420 cifra 430 una segunda cadena compartida 429 con la clave de sesión 425 y se envia 434 al otro lado 410. La entidad receptora 410 desencripta 418 la cadena recibida y la compara 441 con su segunda cadena compartida 419. En el caso de que ambas comparaciones sean exitosas, la clave de sesión 415 425 es válida y se crea el canal seguro.
La figura 5 muestra un ejemplo de generación de clave de sesión después de la autenticación asimétrica. En este caso, solamente una entidad 520 genera 521 un número aleatorio 521 y usa la clave pública pkA 511 de la otra entidad 510 para encriptar 522 el número aleatorio. El número aleatorio se envia 560 y se desencripta 512 en el otro lado 510 usando su propia clave privada PkA 513. Este número aleatorio, que ahora está presente en ambas entidades, es la clave de sesión 514 524. Como en la figura 4, puede ocurrir un proceso de confirmación 580 590 de la clave de sesión entre ambas entidades.
El problema de la carencia de seguridad relacionada con el contenido que se almacena una memoria de almacenamiento masivo ya ha sido tratado por medio de protocolos seguros como el protocolo Trusted Flash, como se describe en el documento US 2007/0136501. Esta solicitud de patente describe técnicas para la transmisión de instrucciones especificas de aplicación entre un ordenador central y una tarjeta de memoria. Las órdenes para el protocolo especifico de aplicación son incorporadas junto con una firma en la parte de datos de un protocolo de transmisión que se use para comunicar entre el ordenador central y la tarjeta de memoria.
De esta forma, un sistema que use un mecanismo de canal seguro es la tarjeta TrustedFlash, que permite proteger el contenido que se almacene en su memoria flash. Una tarjeta de memoria flash segura tiene la capacidad para identificar a la entidad que esté solicitando un servicio de tarjeta, donde la entidad esté relacionada con el acceso a memoria o no. TrustedFlash proporciona varios tipos de algoritmos de autenticación y permite a múltiples entidades autenticadas usar de manera concurrente la tarjeta.
El sistema de seguridad TrustedFlash permite la configuración de un conjunto especifico de permisos (derechos) para cada una de las entidades autenticadas. Cada orden que recibe la tarjeta de memoria flash está asociada con una entidad actualmente autenticada, y la petición de servicio se valida frente a los derechos registrados para esa entidad. La tarjeta autoriza la petición y ejecuta la orden solamente si la entidad solicitante tiene permiso para usar ese servicio. El sistema de autorización soporta varias clases diferentes de servicios .
Las tarjetas de memoria flash se usan como dispositivos de almacenamiento masivo. Otros tipos de dispositivos de almacenamiento masivo permiten almacenar los datos en ficheros que están organizados por medio de una estructura de ficheros que está gestionada por un sistema servidor de aplicaciones (en inglés, "host system") . Las tarjetas TrustedFlash siguen este mismo procedimiento de almacenamiento. Sin embargo, las tarjetas TrustedFlash (tarjetas TF) no controlan el sistema de ficheros. Los ficheros individuales se pueden encriptar con claves especificas de contenido con el fin de proporcionar protección a nivel de fichero.
El sistema de autorización TrustedFlash proporciona la aplicación del cumplimiento de los derechos de acceso de lectura y escritura a las claves de contenido del fichero. Esto protege a los datos mediante la evitación del uso de datos en lugar del acceso a los datos.
La figura 6 muestra un diagrama detallado de un posible servicio TrustedFlash. La entidad A 610 está accediendo al contenido protegido 655 que está almacenado en una tarjeta TF 650. Con el fin de usar la funcionalidad TF, se requiere una capa de agente servidor de aplicaciones 620; la capa de agente servidor de aplicaciones 620 ofrece servicios de sistema de ficheros no estándar a las aplicaciones / entidades. En el diagrama, se muestran la autenticación 660 y el establecimiento de canal seguro 680 entre la entidad A 610 (por ejemplo, un terminal móvil) y la tarjeta TF 650. También se muestra cómo los datos protegidos 655 dentro de la tarjeta TF 650 pasan a estar disponibles para la entidad A 610 a través del canal seguro 680. Las credenciales 615 que están almacenadas en la entidad A 610 permiten acceder a varios servicios y contenidos .
Hasta aqui, se ha descrito una comunicación segura entre una primera entidad (por ejemplo, un terminal móvil) y una segunda entidad (por ejemplo, una tarjeta TrustedFlash) . Sin embargo, también es posible incluir una nueva entidad en ese esquema. Dicha entidad puede ser, por ejemplo, una tarjeta inteligente que, como se puede considerar como un testigo seguro, permite mejorar la seguridad de todo el sistema.
En esta disposición, la tarjeta inteligente puede contener una credencial requerida para acceder a un contenido almacenado en la tarjeta TrustedFlash, teniendo el MNO al que el usuario del terminal móvil está abonado un control completo sobre las credenciales. Si se tiene que reproducir el contenido almacenado por medio de una aplicación que se ejecuta en el terminal móvil, como una aplicación de ejecución (del inglés "player application" ) , tiene que recuperar la credencial que esté almacenada en la tarjeta inteligente.
En esta nueva situación, puede surgir un problema porque la aplicación móvil, una vez que haya recuperado la credencial de la tarjeta inteligente, puede usar esa credencial en cualquier momento y puede entregarla a otras entidades. El MNO de esta manera pierde el control sobre la credencial y sobre el contenido asociado con la misma.
Una posible solución a dicho problema es que la aplicación móvil recupere el contenido requerido a través de la tarjeta inteligente. De esta forma, la aplicación móvil solicita el contenido de la tarjeta inteligente y la tarjeta inteligente a su vez, lo solicita de la tarjeta TF. De esta manera, se resuelve la carencia de visibilidad y de control del MNO. Sin embargo, surge un nuevo problema con relación al funcionamiento, ya que es mucho más rápido para la aplicación móvil recuperar el contenido directamente desde la tarjeta TF que el pasar a través de la tarjeta inteligente, porque el canal de comunicaciones y el protocolo para comunicar con la tarjeta inteligente son muy ineficientes en comparación con los protocolos de alta velocidad usados entre la aplicación móvil y la tarjeta TF.
RESUMEN DE LAS REALIZACIONES DE LA INVENCIÓN
Los problemas mencionados con anterioridad son abordados por medio de la delegación de un canal seguro, que se establece entre una primera entidad y una segunda entidad, a una tercera entidad en la que confia la primera entidad o la segunda entidad.
El nuevo enfoque permite el uso de ese canal seguro establecido entre una primera entidad y una segunda entidad por parte de esa tercera entidad, en la que confia la primera o la segunda entidad. También permite que la tercera parte (entidad) de confianza herede algunos de los privilegios de la entidad que confia en esa tercera entidad de confianza. Estos privilegios permiten que la tercera entidad realice ciertas operaciones con relación a aquellas primera y segunda entidades.
Son posibles varias realizaciones para llevar a cabo lo anterior, incluyendo procedimientos y sistemas de transferencia segura de datos entre entidades.
En una realización, se proporciona un procedimiento de transferencia segura de datos entre entidades. Este procedimiento comprende: el establecimiento de un primer canal seguro entre una primera entidad que tenga al menos una primera credencial y una segunda entidad que tenga al menos una segunda credencial; el establecimiento de un segundo canal seguro entre la mencionada primera entidad y una tercera entidad, siendo la mencionada tercera entidad una entidad de confianza para la mencionada primera entidad; a través del mencionado segundo canal seguro entre la mencionada primera entidad y la mencionada tercera entidad, delegar el mencionado primer canal seguro de la mencionada primera entidad a la mencionada tercera entidad para la transferencia de datos entre la mencionada segunda entidad y la mencionada tercera entidad.
En una realización particular, el paso de establecer el mencionado primer canal seguro comprende: la autenticación de la primera entrada por parte de la segunda entidad y viceversa, usando las respectivas credenciales de las mencionadas primera y segunda entidades; la generación de las claves de sesión por cada una de las mencionadas primera entidad y segunda entidad respectivamente; el establecimiento del mencionado primer canal seguro. Comprende de manera adicional la asignación de privilegios provenientes de la primera entidad a la segunda entidad y viceversa.
En una realización particular, el mencionado paso de delegar el mencionado primer canal seguro comprende los pasos de: solicitar por parte de la mencionada tercera entidad la delegación de un derecho para usar el mencionado primer canal seguro; el paso desde la mencionada primera entidad a la mencionada tercera entidad de las credenciales de sesión requeridas para usar el mencionado primer canal seguro y para habilitar a la mencionada tercera entidad para comunicarse con la mencionada segunda entidad. Dichas credenciales de sesión requeridas son al menos una clave de sesión del mencionado primer canal seguro.
El paso de delegar el mencionado primer canal seguro comprende de manera opcional el paso de negociación entre la mencionada primera entidad y la mencionada segunda entidad para crear al menos una credencial de sesión para la mencionada tercera entidad. También comprende el paso de crear al menos un privilegio de sesión para la mencionada tercera entidad.
Cuando la mencionada tercera entidad accede a la mencionada segunda entidad a través del mencionado canal seguro delegado, la mencionada segunda entidad asigna al menos un privilegio de sesión a la mencionada tercera entidad, dicho al menos un privilegio de sesión definiendo los procesos y/o los datos de la mencionada segunda entidad a los que se permite el acceso a la mencionada tercera entidad a través del mencionado canal seguro delegado.
En otra realización, se proporciona un procedimiento de transferencia segura de datos entre entidades, que comprende: el establecimiento de un primer canal seguro entre una aplicación que se ejecuta en una tarjeta de circuito integrado universal que tenga al menos una primera credencial y una funcionalidad de una tarjeta de memoria no volátil que tenga al menos una segunda credencial; el establecimiento de un segundo canal seguro entre la mencionada aplicación que se ejecuta en una tarjeta de circuito integrado universal y una aplicación que se ejecuta en un terminal móvil, siendo la mencionada aplicación que se ejecuta en un terminal móvil de confianza para la mencionada aplicación que se ejecuta en una tarjeta de circuito integrado universal; a través del mencionado segundo canal seguro entre la mencionada aplicación que se ejecuta en una tarjeta de circuito integrado universal y la mencionada aplicación que se ejecuta en un terminal móvil, la delegación del mencionado primer canal seguro de la mencionada aplicación que se ejecuta en una tarjeta de circuito integrado universal a la mencionada aplicación que se ejecuta en un terminal móvil para la transferencia de datos entre la mencionada funcionalidad de una tarjeta de memoria no volátil y la mencionada aplicación que se ejecuta en un terminal móvil.
En una realización particular, la mencionada funcionalidad de una tarjeta de memoria no volátil es firmware, hardware o una combinación de los mismos.
En una realización particular, la mencionada tarjeta de memoria no volátil es una tarjeta TrustedFlash. Dicha tarjeta Trusted Flash está colocada dentro del mencionado terminal móvil.
El mencionado segundo canal seguro se establece entre la mencionada aplicación que se ejecuta en la mencionada tarjeta de circuito integrado universal y la mencionada aplicación que se ejecuta en el mencionado terminal móvil, requiriendo la mencionada aplicación que se ejecuta en el mencionado terminal móvil el acceso al contenido protegido que se encuentra dentro de la mencionada tarjeta Trusted Flash.
El mencionado canal seguro delegado se establece entre la mencionada aplicación que se ejecuta en el mencionado terminal móvil y la mencionada funcionalidad de la mencionada tarjeta TrustedFlash a través de una aplicación proxy (un proxy es un servidor que permite a otros equipos conectarse a una red de forma indirecta a través de él) localizada dentro del mencionado terminal móvil.
En otra realización, se proporciona un sistema que comprende una primera entidad, una segunda entidad y una tercera entidad. Comprende: un medio para establecer un primer canal seguro entre la mencionada primera entidad y la mencionada segunda entidad; un medio para establecer un segundo canal seguro entre la mencionada primera entidad y la mencionada tercera entidad, siendo la mencionada tercera entidad de confianza para la mencionada primera entidad; un medio para delegar el mencionado primer canal seguro a través del mencionado segundo canal seguro entre la mencionada primera entidad y la mencionada tercera entidad.
En otra realización, se proporciona un sistema que comprende una aplicación que se ejecuta en una tarjeta de circuito integrado universal, una funcionalidad de una tarjeta de memoria no volátil y una aplicación que se ejecuta en un terminal móvil. El sistema comprende: un medio para establecer un primer canal seguro entre la mencionada aplicación que se ejecuta en una tarjeta de circuito integrado universal y la mencionada funcionalidad de una tarjeta de memoria no volátil; un medio para establecer un segundo canal seguro entre la mencionada aplicación que se ejecuta en una tarjeta de circuito integrado universal y la mencionada aplicación que se ejecuta en un terminal móvil, la mencionada aplicación que se ejecuta en un terminal móvil siendo de confianza para la mencionada aplicación que se ejecuta en una tarjeta de circuito integrado universal; un medio para delegar el mencionado primer canal seguro a través del mencionado segundo canal seguro entre la mencionada aplicación que se ejecuta en una tarjeta de circuito integrado universal y la mencionada aplicación que se ejecuta en un terminal móvil.
En una realización particular, dicha tarjeta de memoria no volátil es una tarjeta TrustedFlash. La mencionada tarjeta TrustedFlash está situada dentro del mencionado terminal móvil. En otra realización, se proporciona un programa de ordenador que comprende un código de programa de ordenador adaptado para realizar los pasos del procedimiento anteriormente indicado cuando el mencionado programa se ejecuta sobre una tarjeta inteligente, un ordenador, un procesador digital de la señal, una matriz de puertas programable en campo, un circuito integrado especifico de la aplicación, un microprocesador, un microcontrolador o cualquier otra forma de hardware programable.
Las ventajas de esta nueva aproximación comenzarán a ser más aparentes en la siguiente descripción. Además, son posibles variaciones a las realizaciones descritas en este documento y también serán aparentes a partir de la siguiente descripción.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
Para completar la descripción y con el fin de proporcionar una mejor comprensión de las realizaciones descritas en este documento, se proporciona un conjunto de dibujos. Los mencionados dibujos forman una parte integral de la descripción e ilustran una realización preferida de la invención, que no se deberla interpretar como restrictiva del alcance de la invención, sino solamente como un ejemplo de cómo se puede realizar la invención. Los dibujos comprenden las siguientes figuras:
La figura 1 muestra cómo dos entidades pueden comunicarse de manera segura a través de un medio de comunicaciones no seguro mediante el establecimiento de un canal seguro.
La figura 2 muestra un ejemplo de un proceso de autenticación simétrico.
La figura 3 muestra un ejemplo de un proceso de autenticación asimétrico.
La figura 4 muestra un ejemplo de cómo se pueden generar las claves de sesión después de la autenticación simétrica.
La figura 5 muestra un ejemplo de generación de clave de sesión tras la autenticación asimétrica.
La figura 6 muestra un diagrama de un posible servicio de TrustedFlash.
La figura 7 representa una realización de ejemplo que muestra cómo se lleva a cabo la transferencia segura de datos entre entidades.
La figura 8 representa otra realización de ejemplo que muestra cómo se lleva a cabo la transferencia segura de datos entre entidades.
La figura 9 muestra un diagrama de flujo que indica los pasos llevados a cabo entre las entidades de la figura 8 con el fin de asegurar la transferencia segura de datos.
DESCRIPCIÓN DE LAS REALIZACIONES PREFERIDAS DE LA INVENCIÓN
En este contexto, el término "comprende" y sus derivados (tales como "comprendiendo", etc.) no se deberia entender en un sentido excluyente, esto es, estos términos no se deberian interpretar como excluyentes de la posibilidad de que lo que se describe y se define pueda incluir elementos, pasos, etc. adicionales.
La implementación de varias realizaciones de la presente invención se puede llevar a cabo de la siguiente manera:
La figura 7 muestra cómo se establece un canal seguro delegado. La figura 7 muestra tres entidades: una primera entidad 710, una segunda entidad 720 y una tercera entidad 780. Ejemplos no limitadores de entidades son: Atendiendo a dónde se pueden ejecutar: una aplicación de tarjeta inteligente, una aplicación de tarjeta SIM, una aplicación UICC, una aplicación RUIM, una aplicación USIM, una aplicación ISIM, una aplicación de tarjeta Java, una aplicación de conjunto de Herramientas UICC (del inglés, "UICC Toolkit application" ) , una aplicación móvil, una funcionalidad de una memoria no volátil, una funcionalidad de una tarjeta TrustedFlash, una aplicación de ordenador personal y una aplicación de servidor MNO (del inglés "MoJbile Network Operator") . Atendiendo a la función para la que están configurados para llevar a cabo: una aplicación de servidor, una aplicación de Servidor Web de Tarjeta Inteligente, SCWS (del inglés Smart Card Web Server) , un servlet (programa que se ejecuta en un servidor en el contexto de un navegador) y una aplicación de cliente (por ejemplo, un navegador) .
La primera entidad 710 comprende al menos una primera credencial 7101. La segunda entidad 720 comprende al menos una segunda credencial 7201. Ejemplos no limitadores de las credenciales comprendidas en cualquiera de estas entidades son claves, tales como claves simétricas y claves asimétricas. El cálculo de dichas credenciales está fuera del alcance de la presente descripción. Se establece un canal seguro 740 entre la primera entidad 710 y la segunda entidad 720. De manera preferible, la etapa de establecimiento de este canal seguro 740 comprende un paso de autenticación entre la primera entidad 710 y la segunda entidad 720. Esta autenticación es mutua: la primera entidad 710 autentica a la segunda entidad 720 y viceversa. Esto se hace mediante el uso de las respectivas credenciales 7101 7102 de las dos entidades 710 720. Esa autenticación es una autenticación convencional, llevada a cabo como se explica en la sección de la técnica anterior. La etapa de establecer este canal seguro 740 comprende también, una vez que se ha hecho la autenticación mutua entre la primera entidad 710 y la segunda entidad 720, un paso de generación de claves de sesión (que no se ilustra en la figura 7) . Tanto la primera entidad 710 como la segunda entidad 720 generan claves de sesión. Esta generación de claves de sesión se hace de acuerdo con cualquier manera convencional de generación de dichas claves, como se menciona en la sección de la técnica anterior. Cada sesión tiene su propia clave especifica de sesión, con cada una de las claves siendo generada de manera independiente sobre cada uno de los lados pero cuyo valor de clave es el mismo. La vida de estas claves de sesión finaliza con el final de la sesión. Las credenciales de una entidad, sin embargo, siguen siendo las mismas. Una vez que las entidades son autenticadas y se generan las claves de sesión, se establece el canal seguro 740.
Durante el paso de autenticación, cada entidad 710 720 asigna privilegios (que no se ilustran en la figura 7) a la otra entidad. Los privilegios pueden ser o bien el acceso a datos o bien el acceso a un proceso. A modo de ejemplo, si la entidad es una funcionalidad de una tarjeta de memoria no volátil, los privilegios que esta funcionalidad puede asignar a otras entidades son el acceso a parte de sus datos (porque la tarjeta de memoria no comprende procesos) . Sin embargo, si la entidad es una entidad que comprende procesos, los privilegios que puede asignar a otras entidades son el acceso a algunos procesos. Estos privilegios definen por lo tanto los procesos y los datos de una entidad a la que pueda acceder la otra entidad.
La tercera entidad 780 de la figura 7 es una entidad de confianza para la primera entidad 710. Esto significa que la tercera entidad tiene la credencial que permite a la primera entidad, después de un proceso de autenticación, conocer que esta tercera entidad es una entidad segura sin propósito malicioso y que sigue los procedimientos bajo la política de seguridad de la primera entidad. El proceso de confianza en esta tercera entidad 780 por parte de la primera entidad 710 está fuera del alcance de la presente descripción. Se hace por medio de cualquier manera convencional de confianza entre entidades. Una vez que se ha establecido el canal seguro 740 entre la primera entidad 710 y la segunda entidad 720, se establece un segundo canal seguro 750 entre la primera entidad 710 y la tercera entidad 780. El establecimiento de este segundo canal seguro 750 se lleva a cabo de la misma manera que el establecimiento del primer canal seguro 740, mutatis mutandis. Se puede establecer primero el canal seguro 740 entre la primera entidad 710 y la segunda entidad 720, o se puede establecer primero el canal seguro 750 entre la primera entidad 710 y la tercera entidad 780, o se pueden establecer ambos canales seguros 740 750 en paralelo. Con el fin de completar la delegación, ambos canales tienen que estar ya establecidos.
A través de este segundo canal seguro 750, la tercera entidad 780, en la que confia la primera entidad 710 pero en la que no confia la segunda entidad 720, pide a la entidad que confia en ella la delegación del canal seguro 740 establecido entre la primera entidad 710 y la segunda entidad 720. Como contestación a esta petición, la primera entidad 710 pasa a la tercera entidad 780 las credenciales de sesión (que no se ilustran en la figura 7) requeridas con el fin de usar el primer canal seguro y poder comunicarse con la segunda entidad 720. Ejemplos no limitadores de estas credenciales de sesión pueden ser las claves de sesión del canal seguro 740 establecido entre la primera entidad 710 y la segunda entidad 720 o diferentes claves de sesión acordadas entre la primera y la segunda entidades durante el proceso de negociación de la delegación. Por lo tanto, se ha de interpretar una delegación como el paso desde una entidad A a otra entidad C credenciales de sesión necesarias para usar un canal seguro establecido entre esa entidad A y otra entidad B, para que esa entidad C sea capaz de usar ese canal seguro y de esta manera comunicarse con esa entidad B. De manera opcional, también puede comprender una negociación entre la entidad A y la entidad B con el fin de establecer una credencial y privilegios de sesión para ser usados por la entidad C en el canal seguro. De esta forma se establece la delegación del primer canal seguro 740.
El paso de delegar el primer canal seguro 740 a la tercera entidad 780 comprende una etapa de negociación entre la primera entidad 710 y la segunda entidad 720, para crear al menos una credencial de sesión (que no se ilustra en la figura 7) para la tercera entidad 780. Esta negociación es de la siguiente manera: la primera entidad 710 envia un comando a la segunda entidad 720, pidiendo los privilegios particulares que se han de asignar a la tercera entidad 780. Si la segunda entidad 720 está de acuerdo con la petición, incluye, en su respuesta al comando, una credencial de sesión que está internamente asociada dentro de la segunda entidad 720 a los privilegios solicitados, para ser asignados a la tercera entidad 780. A partir de ésa, al menos una, credencial de sesión, se puede crear un privilegio de sesión (que no se ilustra en la figura 7) . Este privilegio de sesión es acordado entre la primera entidad 710 y la segunda entidad 720 y se asigna a la tercera entidad 780 cuando accede a la segunda entidad 720. Como se ha dicho con anterioridad, un ejemplo de un privilegio son los derechos de acceso a determinados datos o procesos. Cuando la tercera entidad 780 accede a la segunda entidad 720 a través del primer canal seguro delegado 740, la segunda entidad 720 asigna al menos un privilegio de sesión a la tercera entidad 780. Este privilegio de sesión define los procesos o los datos de la segunda entidad 720 a los que se permite acceder a la tercera entidad 780. Estos privilegios de sesión pueden ser del mismo nivel que los privilegios asignados por la segunda entidad 720 a la primera entidad 710, o de un nivel inferior.
En cualquiera de estas realizaciones de ejemplo, la delegación del canal seguro 740 solamente es válida durante la sesión de canal seguro actual (primer canal seguro) establecida entre la primera entidad 710 y la segunda entidad 720. Las credenciales de sesión solamente son válidas mientras esté vivo el primer canal seguro. En el caso de que la entidad de confianza 780 las requiera en otra sesión, se requiere la obtención de una nueva credencial de sesión o nuevas credenciales de sesión de la entidad de confianza. De esta manera se establece el canal seguro delegado 790.
En una realización particular, se proporciona un sistema, que tiene una primera entidad 710, una segunda entidad 720 y una tercera entidad 780. El sistema comprende un medio para establecer un primer canal seguro 740 entre Ia primera entidad 710 y la segunda entidad 720. También comprende un medio para establecer un segundo canal seguro 750 entre la primera entidad 710 y la tercera entidad 780, para lo que la tercera entidad 780 anteriormente se ha convertido en una entidad de confianza para la primera entidad 710. El sistema comprende también un medio para delegar el primer canal seguro 740 a través del segundo canal seguro 750 entre la primera entidad 710 y la tercera entidad 780.
En otra realización particular, se presenta un programa de ordenador que comprende un código de programa de ordenador adaptado para realizar los pasos de delegar un canal seguro, cuando se ejecuta el programa sobre una tarjeta inteligente, un ordenador, un procesador digital de la señal, una matriz de puertas programable en campo, un circuito integrado especifico de la aplicación, un microprocesador, un microcontrolador o cualquier otra forma de hardware programable.
La figura 8 está relacionada con otra realización que describe cómo se establece un canal seguro delegado. Como en la figura 7, la figura 8 muestra tres entidades: una primera entidad 810, que en esta realización particular es una aplicación que se ejecuta en una tarjeta de circuito integrado universal 810, tal como una tarjeta SIM o una tarjeta USIM; una segunda entidad 820, que en esta realización particular es una funcionalidad de una tarjeta de memoria no volátil 820, tal como una tarjeta TrustedFlash; y una tercera entidad 880, que en esta realización particular es una aplicación 882 que se ejecuta en un terminal móvil 880.
Como en la figura 7, la aplicación que se ejecuta en la tarjeta de circuito integrado universal (UICC) 810 comprende al menos una credencial 8101. La funcionalidad de la tarjeta de memoria no volátil 820 comprende al menos una credencial 8201. Ejemplos no limitadores de las credenciales comprendidas en cualquiera de estas entidades son claves, tales como claves simétricas y claves asimétricas, cuya creación se encuentra fuera del alcance de esta descripción. Se establece un canal seguro 840 entre la aplicación que se ejecuta en la UICC 810 y la funcionalidad de la tarjeta de memoria no volátil 820. De manera preferible, el paso de establecimiento de este canal seguro 840 comprende un paso de autenticación mutua entre ambas entidades. Esto se hace mediante el uso de las respectivas credenciales 8101 8201 de las dos entidades. El paso de establecimiento de este canal seguro 840 comprende también, una vez que se ha hecho la autenticación entre la aplicación que se ejecuta en la UICC 810 y la funcionalidad de la tarjeta de memoria no volátil 820, un paso de generación de claves de sesión por parte de ambas entidades. Esta generación de claves de sesión se hace de acuerdo con cualquier manera convencional de generar dichas claves, como se menciona en la sección de la técnica anterior. Cada una de las sesiones tiene sus propias claves de sesión especificas. La vida de estas claves de sesión finaliza con el final de la sesión. La, al menos una, credencial 8101 8201 de cada entidad, sin embargo, permanece siendo la misma. Ejemplos no limitadores de las claves de sesión que se pueden generar cuando se establece el canal seguro 840 son: claves simétricas y asimétricas. Una vez que se han autenticado una a la otra la aplicación en la UICC 810 y la funcionalidad de la tarjeta de memoria no volátil 820, y ambas han generado las respectivas claves de sesión, se establece el canal seguro 840.
Durante el paso de autenticación, la aplicación en la UICC 810 asigna privilegios a la funcionalidad de la tarjeta de memoria no volátil 820 y viceversa. Los privilegios (que no se ilustran en la figura 8) asignados a la tarjeta de memoria no volátil 820 por parte de la aplicación que se ejecuta en la UICC 810 son: acceso a algunos ficheros UICC y a la aplicación UICC. Los privilegios asignados a la aplicación que se ejecuta en la UICC 810 por parte de la funcionalidad de la tarjeta de memoria no volátil 820 son permisos para acceder a parte de los datos almacenados en la tarjeta de memoria no volátil. Estos privilegios definen por lo tanto los datos de la tarjeta de memoria no volátil a los que puede acceder la aplicación que se ejecuta en la UICC.
La aplicación 882 que se ejecuta en el terminal móvil 880 de la figura 8 es de confianza para la aplicación que se ejecuta en la UICC 810. Una vez que se establece el canal seguro 840 entre la aplicación que se ejecuta en la UICC 810 y la funcionalidad de la tarjeta de memoria no volátil 820, se establece un segundo canal seguro 850 entre la aplicación que se ejecuta en la UICC 810 y la aplicación 882 que se ejecuta en un terminal móvil 880. El establecimiento de este segundo canal seguro 850 se lleva a cabo de la misma manera que el establecimiento del primer canal seguro 840, mutatis mutandis. Se puede establecer primero el canal seguro 840 entre la aplicación que se ejecuta en la UICC 810 y la funcionalidad de la tarjeta de memoria no volátil 820, o se puede establecer primero el canal seguro 850 entre la aplicación que se ejecuta en la UICC 810 y la aplicación 882 que se ejecuta en un terminal móvil 880, o se pueden establecer ambos canales seguros 840 850 en paralelo.
Como en la realización anterior, a través de este segundo canal seguro 850, la aplicación 882 que se ejecuta en el terminal móvil 880, en la que confia la aplicación que se ejecuta en la UICC 810 pero en la que no confia la funcionalidad de la tarjeta de memoria no volátil 820, pide a la aplicación que se ejecuta en la UICC la delegación del derecho para usar el canal seguro 840 establecida entre la aplicación que se ejecuta en la UICC y la funcionalidad de la tarjeta de memoria no volátil 820. Como contestación a esta solicitud, la aplicación que se ejecuta en la UICC 810 pasa a la aplicación 882 que se ejecuta en el terminal móvil 880 las credenciales de sesión (que no se ilustran en la figura 8) requeridas con el fin de usar el canal seguro 840 y poder comunicarse con la funcionalidad de la tarjeta de memoria no volátil 820. Ejemplos no limitadores de estas credenciales de sesión pueden ser las claves de sesión del canal seguro 840 establecidas entre la aplicación que se ejecuta en la UICC 810 y la funcionalidad de la tarjeta de memoria no volátil 820. Por lo tanto, se ha de entender una delegación el paso desde una aplicación que se ejecuta en la UICC 810 a otra aplicación 882 que se ejecuta en el terminal móvil 880 de credenciales de sesión necesarias para usar el canal seguro 840 establecido entre esa aplicación que se ejecuta en la UICC 810 y la funcionalidad de la tarjeta de memoria no volátil 820, para que esa aplicación que se ejecuta en el terminal móvil 880 sea capaz de usar ese canal seguro y de esta manera comunicarse con esa tarjeta de memoria no volátil 820. De esta forma se establece la delegación del primer canal seguro 840.
Como en la realización ilustrada en la figura 7, el paso de delegar el primer canal seguro 840 a la aplicación 882 que se ejecuta en un terminal móvil 880 comprende un paso opcional de negociación entre la aplicación que se ejecuta en la UICC 810 y la funcionalidad de la tarjeta de memoria no volátil 820, para crear al menos una credencial de sesión (que no se ilustra en la figura 8) para la aplicación que se ejecuta en el terminal móvil 880. A partir de esa, al menos una, credencial de sesión, se puede crear un privilegio de sesión (que no se ilustra en la figura 8). Cuando la aplicación 882 que se ejecuta en el terminal móvil 880 accede a la funcionalidad de la tarjeta de memoria no volátil 820 a través del canal seguro delegado 890, la tarjeta de memoria no volátil 820 asigna al menos un privilegio de sesión a la aplicación 882 que se ejecuta en el terminal móvil 880. Este privilegio de sesión define los datos de la funcionalidad de la tarjeta de memoria no volátil 820 a la que puede acceder la aplicación 882 que se ejecuta en el terminal móvil 880. A modo de ejemplo, una aplicación de terminal móvil puede acceder a un fichero de memoria, como un fichero de pelicula o un fichero mp3, que esté protegido, y los privilegios para acceder a este fichero están asociados a la credencial de sesión usada por la aplicación del terminal móvil. Estos privilegios (que no se ilustran en la figura 8) pueden ser del mismo nivel que los asignados por la funcionalidad de la tarjeta de memoria no volátil 820 a la aplicación que se ejecuta en la UICC 810, o de un nivel inferior.
La delegación del canal seguro 840 solamente es válida hasta que se termina el canal que fue delegado. El canal seguro se termina cuando una de las entidades desea acabar la comunicación por medio de un comando especifico de canal seguro (es decir, comando de terminar canal seguro) o cuando una de las entidades se da cuenta de que la otra entidad no se encuentra operativa o cuando una de las entidades se da cuenta de que ha ocurrido un error en las comunicaciones o ha ocurrido una cuestión de seguridad en el canal seguro u otros. Esto quiere decir que las credenciales de sesión que se obtienen por medio de la aplicación 882 que se ejecuta en el terminal móvil 880, en la que confia la aplicación que se ejecuta en la UICC 810, solamente se pueden usar durante la sesión actual. En el caso de que la aplicación de confianza 882 que se ejecuta en el terminal móvil 880 las requiera en otra sesión, se requiere la obtención de una nueva credencial de sesión o de nuevas credenciales de sesión provenientes de la aplicación que se ejecuta en la UICC 810 (entidad de confianza) .
El segundo canal seguro 850 se establece entre una aplicación que se ejecuta en la tarjeta de circuito integrado universal 810 y una aplicación 882 que se ejecuta en el terminal móvil 880. Esta aplicación 882 requiere el acceso a un contenido protegido 825 localizado dentro de la tarjeta de memoria no volátil 820. En un ejemplo en particular, esta tarjeta de memoria no volátil 820 es una tarjeta TrustedFlash 820. De manera preferible, este canal seguro delegado 890 se establece entre la aplicación que se ejecuta en el terminal móvil y la tarjeta TrustedFlash 820 a través de una aplicación proxy 887 localizada dentro del terminal móvil 880. De esta manera, el proxy actúa como un conversor de protocolo, convirtiendo el protocolo usado en la comunicación entre la aplicación que se ejecuta en la UICC 810 y la aplicación que se ejecuta en el terminal móvil 880 al protocolo usado entre la funcionalidad de la tarjeta TrustedFlash y la aplicación que se ejecuta en el terminal móvil 880, y viceversa.
El procedimiento de transferencia segura de datos entre la aplicación 882 que se ejecuta en el terminal móvil
880 y la funcionalidad de la tarjeta TrustedFlash 880 se explica a continuación con relación al diagrama de flujo de la figura 9.
En primer lugar, en el bloque 901, la aplicación 882 que se ejecuta en el terminal móvil 880 intenta leer el contenido de una partición pública de la tarjeta TrustedFlash 820, para la que la aplicación 882 ha establecido una conexión con una funcionalidad de la tarjeta TrustedFlash 820 usando la funcionalidad de sistema de ficheros estándar del terminal móvil.
Si ese contenido no está protegido o no está encriptado, la aplicación 882 puede acceder y usar ese contenido. Esto se indica en los bloques 902 903.
Si, sin embargo, el contenido está protegido por medio de encriptado, no se permite a la aplicación 882 acceder a ese contenido protegido 825. Entonces, la cuestión que surge es si la aplicación 882 tiene o no la credencial o las credenciales requeridas para registrarse a la funcionalidad de la tarjeta TrustedFlash 820 (que protege el contenido 825). Esto se indica en el bloque 904.
Si la aplicación 882 tiene esas credenciales requeridas, se registra - establece un canal . seguro usando la credencial para la fase de autenticación con la funcionalidad de la tarjeta TrustedFlash que protege el contenido - en la funcionalidad de la tarjeta TrustedFlash 820 que protege ese contenido. De esta manera se crea un canal seguro entre la aplicación 882 y la funcionalidad de la tarjeta TrustedFlash 820. Esto se indica en el bloque 905. A través de ese canal seguro, la aplicación 882 puede recuperar ese contenido en abierto sin codificar, como se muestra en el bloque 906. Finalmente, la aplicación 882 puede usar ese contenido para cualquier propósito, como se indica en el bloque 907.
Si, por el contrario, la aplicación 882 no tiene esas credenciales requeridas, no se puede registrar en la funcionalidad de la tarjeta TrustedFlash 820 que protege el contenido deseado 825. Después, se comprueba si la aplicación que se ejecuta en la UICC 810 posee o no esas credenciales requeridas. Si la aplicación que se ejecuta en la UICC 810 no posee esas credenciales requeridas, entonces la aplicación 882 no puede acceder al contenido deseado. Esto se indica en los bloques 908 909.
Si, por el contrario, la aplicación que se ejecuta en la UICC 810 posee esas credenciales requeridas (la manera en la que la aplicación que se ejecuta en la UICC 810 ha conseguido esas credenciales requeridas se encuentra fuera del alcance de la presente descripción) , la aplicación 882 establece un canal seguro 850 con la aplicación que se ejecuta en la UICC 810. Esto se indica en el bloque 910. A través de este canal seguro 850, la aplicación 882 solicita a la aplicación que se ejecuta en la UICC 810 la delegación de otro canal seguro con la funcionalidad de la tarjeta
TrustedFlash 820 que protege el contenido deseado 825, como se indica en el bloque 911.
Si la aplicación 882 no tiene la credencial o las credenciales para establecer ese otro canal seguro con la funcionalidad de la tarjeta TrustedFlash 820, se deniega dicho establecimiento solicitado, como se indica en los bloques 912 913.
Si, sin embargo, la aplicación 882 tiene esos derechos, la aplicación que se ejecuta en la UICC 810 establece un canal seguro 840 con la funcionalidad de la tarjeta TrustedFlash 820 (que protege el contenido deseado 825) . Este establecimiento del canal seguro 840 entre la aplicación que se ejecuta en la UICC 810 y la funcionalidad de la tarjeta TrustedFlash 820 comprende la autenticación mutua entre las dos y la generación de claves de sesión (por parte de ambas). Esto se indica en el bloque 914.
Una vez que este canal seguro 840 se ha establecido, la aplicación que se ejecuta en la UICC 810 envia a la aplicación 882, a través del canal seguro 850 entre la aplicación 882 y la aplicación que se ejecuta en la UICC
810, las credenciales de sesión requeridas del canal seguro
840. Estas credenciales de sesión son de manera preferible claves de sesión (temporales, o lo que es lo mismo, que duran mientras la sesión correspondiente se mantenga viva) .
Esto se muestra en el bloque 916.
Anterior al envió de estas credenciales de sesión requeridas, se hace una negociación opcional entre la aplicación que se ejecuta en la UICC 810 y la funcionalidad de la tarjeta TrustedFlash 820, como se indica por medio del bloque 915, para decidir qué credenciales de sesión y qué privilegios de sesión se dan a la aplicación 882 para delegar el canal seguro 840. Esto se indica por medio del bloque 915.
Finalmente, una vez que el canal seguro 840 es delegado a la aplicación 882, esta aplicación 882 recupera el contenido protegido 825 a través del canal seguro delegado. Como se indica en el bloque 917, la aplicación 882 puede usar dicho contenido 825 para cualquier propósito.
El establecimiento del canal seguro (bloque 914) entre la aplicación que se ejecuta en la UICC (810) y la funcionalidad de la tarjeta TrustedFlash 820 se puede llevar a cabo antes de la petición (bloque 911) por parte de la aplicación 882 para establecer un canal seguro con la funcionalidad de la tarjeta TrustedFlash 820. El establecimiento del canal seguro (bloque 914) entre la aplicación que se ejecuta en la UICC y la funcionalidad de la tarjeta TrustedFlash 820 también se puede llevar a cabo antes del establecimiento (bloque 910) por parte de la aplicación 882 de un canal seguro con la aplicación que se ejecuta en la UICC (810) .
Las varias realizaciones de la invención obviamente no están limitadas a las realizaciones especificas descritas en este documento, sino que también abarcan cualquier variación que pueda ser considerada por cualquier persona experta en la técnica (por ejemplo, con relación a la elección de componentes, configuración, etc.), dentro del alcance general de la invención como se define en las reivindicaciones anejas. De acuerdo con esto, la invención que se reivindica como se cita en las reivindicaciones anejas no está limitada a las realizaciones descritas en este documento.

Claims

REIVINDICACIONES
1. Un procedimiento de transferencia segura de datos entre entidades, que comprende:
el establecimiento de un primer canal seguro (740, 840) entre una primera entidad (710, 810) que tiene al menos una primera credencial (7101, 8101) y una segunda entidad (720, 820) que tiene al menos una segunda credencial (7201, 8201);
el establecimiento de un segundo canal seguro (750, 850) entre la mencionada primera entidad (710, 810) y una tercera entidad (780, 880), la mencionada tercera entidad (780, 880) siendo de confianza para la mencionada primera entidad (710, 810);
a través del mencionado segundo canal seguro (750, 850) entre la mencionada primera entidad (710, 810) y la mencionada tercera entidad (780, 880), delegar (790, 890) el mencionado primer canal seguro (740, 840) desde la mencionada primera entidad (710, 810) a la mencionada tercera entidad (780, 880) para transferir datos entre la mencionada segunda entidad (720, 820) y la mencionada tercera entidad (780, 880) .
2. El procedimiento de acuerdo con la reivindicación 1, en el que el paso de establecer el mencionado primer canal seguro (740, 840) comprende:
la autenticación de la primera entidad (710, 810) por parte de la segunda entidad (720, 820) y viceversa, usando las respectivas credenciales (7101, 8101) de las mencionadas primera y segunda entidades; Ia generación de claves de sesión por parte de cada una de las mencionadas primera entidad (710, 810) y segunda entidad (720, 820) respectivamente;
el establecimiento del mencionado primer canal seguro (740, 840) .
3. El procedimiento de acuerdo con la reivindicación 2, comprendiendo de manera adicional la asignación de privilegios desde la primera entidad (710, 810) a la segunda entidad (720, 820) y viceversa.
4. El procedimiento de acuerdo con cualquiera de las reivindicaciones anteriores, en el que el mencionado paso de delegar el mencionado primer canal seguro (740, 840) comprende los pasos de:
solicitar por parte de la mencionada tercera entidad (780, 880) la delegación de un derecho para usar el mencionado primer canal seguro (740, 840) ;
pasar desde la mencionada primera entidad (710, 810) a la mencionada tercera entidad (780, 880) las credenciales de sesión requeridas para el uso del mencionado primer canal seguro (740, 840) y para habilitar a la mencionada tercera entidad (780, 880) para que pueda comunicarse con la mencionada segunda entidad (720, 820) .
5. El procedimiento de acuerdo con la reivindicación 4, en el que las mencionadas credenciales de sesión requeridas son al menos una clave de sesión del mencionado primer canal seguro (740, 840) .
6. El procedimiento de acuerdo con cualquiera de las reivindicaciones anteriores, en el que el mencionado paso de delegar el mencionado primer canal seguro (740, 840) comprende el paso de la negociación entre la mencionada primera entidad (710, 810) y la mencionada segunda entidad
(720, 820) para crear al menos una credencial de sesión para la mencionada tercera entidad (780, 880) .
7. El procedimiento de acuerdo con la reivindicación 6, comprendiendo de manera adicional el paso de crear al menos un privilegio de sesión para la mencionada tercera entidad (780, 880) .
8. El procedimiento de acuerdo con la reivindicación 7, en el que, cuando la mencionada tercera entidad (780, 880) accede a la mencionada segunda entidad (720, 820) a través del mencionado canal seguro delegado (790, 890), la mencionada segunda entidad (720, 820) asigna al menos un privilegio de sesión a la mencionada tercera entidad (780, 880), donde el mencionado, al menos uno, privilegio de sesión define los procesos y/o los datos de la mencionada segunda entidad (720, 820) a los que se permite el acceso por parte de la tercera entidad (780, 880) a través del mencionado canal seguro delegado (790, 890) .
9. El procedimiento de acuerdo con cualquiera de las reivindicaciones anteriores, en el que la mencionada primera entidad es una aplicación que se ejecuta en una tarjeta de circuito integrado universal (810), la mencionada segunda entidad es una funcionalidad de una tarjeta de memoria no volátil (820) y la mencionada tercera entidad es una aplicación (882) que se ejecuta en un terminal móvil (880) .
10. El procedimiento de acuerdo con la reivindicación 9, en el que la mencionada funcionalidad de una tarjeta de memoria no volátil (820) es firmware, hardware o una combinación de los mismos.
11. El procedimiento de acuerdo con la reivindicación 9, en el que la mencionada tarjeta de memoria no volátil (820) es una tarjeta TrustedFlash.
12. El procedimiento de acuerdo con la reivindicación 11, en el que la mencionada tarjeta TrustedFlash (820) está situada dentro del mencionado terminal móvil (880) .
13. El procedimiento de acuerdo con la reivindicación 11, en el que se establece el mencionado segundo canal seguro (850) entre la mencionada aplicación que se ejecuta en la mencionada tarjeta de circuito integrado universal (810) y la mencionada aplicación (882) que se ejecuta en el mencionado terminal móvil (880) , donde la mencionada aplicación (882) que se ejecuta en el mencionado terminal móvil (880) requiere el acceso al contenido protegido (825) localizado dentro de la mencionada tarjeta TrustedFlash (820).
14. El procedimiento de acuerdo con la reivindicación 11, en el que se establece el mencionado canal seguro delegado (890) entre la mencionada aplicación que se ejecuta en el mencionado terminal móvil (880) y la mencionada funcionalidad de la mencionada tarjeta TrustedFlash (820) a través de una aplicación proxy (887) situada dentro del mencionado terminal móvil (880) .
15. Un sistema que comprende una primera entidad (710, 810) , una segunda entidad (720, 820) y una tercera entidad (780, 880) , comprendiendo el mencionado sistema:
un medio para establecer un primer canal seguro (740, 840) entre la mencionada primera entidad (710, 810) y la mencionada segunda entidad (720, 820) ;
un medio para establecer un segundo canal seguro (750, 850) entre la mencionada primera entidad (710, 810) y la mencionada tercera entidad (780, 880) , siendo la mencionada tercera entidad (780, 880) de confianza para la mencionada primera entidad (710, 810) ;
un medio para delegar el mencionado primer canal seguro (740, 840) a través del mencionado segundo canal seguro
(750, 850) entre la mencionada primera entidad (710, 810) y la mencionada tercera entidad (780, 880) .
16. El sistema de acuerdo con la reivindicación 15, en el que la mencionada primera entidad es una aplicación que se ejecuta en una tarjeta de circuito integrado universal
(810), la mencionada segunda entidad es una funcionalidad de una tarjeta de memoria no volátil (820) y la mencionada tercera entidad es una aplicación (882) que se ejecuta en un terminal móvil (880).
17. El sistema de acuerdo con la reivindicación 16, en el que la mencionada tarjeta de memoria no volátil (820) es una tarjeta TrustedFlash.
18. El sistema de acuerdo con la reivindicación 17, en el que la mencionada tarjeta TrustedFlash (820) está situada dentro del mencionado terminal móvil (880) .
19. Un programa de ordenador que comprende un código de programa de ordenador adaptado para realizar los pasos del procedimiento de acuerdo con cualquiera de las reivindicaciones de la 1 a la 14 cuando el mencionado programa se ejecuta en una tarjeta inteligente, un ordenador, un procesador digital de la señal, una matriz de puertas programable en campo, un circuito integrado especifico de la aplicación, un microprocesador, un microcontrolador o cualquier otra forma de hardware programable.
PCT/ES2008/000087 2008-02-18 2008-02-18 Transferencia segura de datos WO2009103824A1 (es)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP08736691A EP2262164A1 (en) 2008-02-18 2008-02-18 Secure data transfer
US12/309,288 US20110131640A1 (en) 2008-02-18 2008-02-18 Secure transfer of data
PCT/ES2008/000087 WO2009103824A1 (es) 2008-02-18 2008-02-18 Transferencia segura de datos

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/ES2008/000087 WO2009103824A1 (es) 2008-02-18 2008-02-18 Transferencia segura de datos

Publications (1)

Publication Number Publication Date
WO2009103824A1 true WO2009103824A1 (es) 2009-08-27

Family

ID=40082766

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/ES2008/000087 WO2009103824A1 (es) 2008-02-18 2008-02-18 Transferencia segura de datos

Country Status (3)

Country Link
US (1) US20110131640A1 (es)
EP (1) EP2262164A1 (es)
WO (1) WO2009103824A1 (es)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2299747A4 (en) * 2008-07-10 2014-06-25 Sk Planet Co Ltd PERSONALIZED SERVICE SYSTEM BASED ON USE OF INTELLIGENT CARD, METHOD AND INTELLIGENT CARD THEREFOR
EP2175393B1 (en) * 2008-10-13 2019-03-06 Vodafone Holding GmbH Data exchange between protected memory cards
KR20100133184A (ko) * 2009-06-11 2010-12-21 삼성전자주식회사 고체 상태 드라이브 장치
CN101645776B (zh) * 2009-08-28 2011-09-21 西安西电捷通无线网络通信股份有限公司 一种引入在线第三方的实体鉴别方法
EP2362573A1 (en) * 2010-02-19 2011-08-31 Irdeto B.V. Device and method for establishing secure trust key
DE102010013202A1 (de) * 2010-03-29 2011-09-29 Giesecke & Devrient Gmbh Verfahren zum sicheren Übertragen einer Anwendung von einem Server in eine Lesegeräteinheit
US8824487B1 (en) * 2010-04-29 2014-09-02 Centurylink Intellectual Property Llc Multi-access gateway for direct to residence communication services
US9092149B2 (en) 2010-11-03 2015-07-28 Microsoft Technology Licensing, Llc Virtualization and offload reads and writes
US20120131635A1 (en) * 2010-11-23 2012-05-24 Afore Solutions Inc. Method and system for securing data
WO2012107058A1 (en) * 2011-02-11 2012-08-16 Nec Europe Ltd. Method and system for supporting user authentication to a service
US9146765B2 (en) 2011-03-11 2015-09-29 Microsoft Technology Licensing, Llc Virtual disk storage techniques
US10373152B2 (en) * 2011-12-13 2019-08-06 Visa International Service Association Integrated mobile trusted service manager
US9817582B2 (en) 2012-01-09 2017-11-14 Microsoft Technology Licensing, Llc Offload read and write offload provider
US9071585B2 (en) 2012-12-12 2015-06-30 Microsoft Technology Licensing, Llc Copy offload for disparate offload providers
US9251201B2 (en) 2012-12-14 2016-02-02 Microsoft Technology Licensing, Llc Compatibly extending offload token size
CN104104646B (zh) * 2013-04-02 2017-08-25 中国银联股份有限公司 基于安全载体主动式命令的安全性信息交互系统、设备及方法
KR102452184B1 (ko) * 2014-11-28 2022-10-06 삼성전자주식회사 의료 데이터 통신 방법
US10263959B2 (en) * 2014-11-28 2019-04-16 Samsung Electronics Co., Ltd. Method for communicating medical data
CZ2015472A3 (cs) * 2015-07-07 2017-02-08 Aducid S.R.O. Způsob navazování chráněné elektronické komunikace, bezpečného přenášení a zpracování informací mezi třemi a více subjekty
US10951591B1 (en) * 2016-12-20 2021-03-16 Wells Fargo Bank, N.A. SSL encryption with reduced bandwidth

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002033884A2 (en) * 2000-10-17 2002-04-25 Sun Microsystems, Inc. Method and apparatus for providing a key distribution center
US20020147917A1 (en) * 2001-04-05 2002-10-10 Brickell Ernie F. Distribution of secured information
US20040034774A1 (en) * 2002-08-15 2004-02-19 Le Saint Eric F. System and method for privilege delegation and control
WO2006061754A1 (en) * 2004-12-07 2006-06-15 Philips Intellectual Property & Standards Gmbh System and method for application management on multi-application smart cards
US20070136501A1 (en) 2005-12-08 2007-06-14 Chang Robert C Media card command pass through methods

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0566811A1 (en) * 1992-04-23 1993-10-27 International Business Machines Corporation Authentication method and system with a smartcard
US6298441B1 (en) * 1994-03-10 2001-10-02 News Datacom Ltd. Secure document access system
EP1166238B1 (de) * 1999-04-07 2003-09-10 Swisscom Mobile AG Verfahren und system zum bestellen, laden und verwenden von zutritts-tickets
US7565326B2 (en) * 2000-05-25 2009-07-21 Randle William M Dialect independent multi-dimensional integrator using a normalized language platform and secure controlled access
FR2812486B1 (fr) * 2000-07-28 2002-12-27 Gemplus Card Int Securisation de session avec un moyen de traitement de donnees sous la commande de entites
US8020196B2 (en) * 2002-10-25 2011-09-13 Randle William M Secure transmission and exchange of standardized data
EP1533971A1 (en) * 2003-11-18 2005-05-25 STMicroelectronics S.r.l. Method and system for establishing secure communication
US8265695B2 (en) * 2005-04-29 2012-09-11 Telecom Italia S.P.A. Method for the management of a peripheral unit by a sim card in wireless communication terminals, and peripheral unit for implementing the method
US20060294366A1 (en) * 2005-06-23 2006-12-28 International Business Machines Corp. Method and system for establishing a secure connection based on an attribute certificate having user credentials

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002033884A2 (en) * 2000-10-17 2002-04-25 Sun Microsystems, Inc. Method and apparatus for providing a key distribution center
US20020147917A1 (en) * 2001-04-05 2002-10-10 Brickell Ernie F. Distribution of secured information
US20040034774A1 (en) * 2002-08-15 2004-02-19 Le Saint Eric F. System and method for privilege delegation and control
WO2006061754A1 (en) * 2004-12-07 2006-06-15 Philips Intellectual Property & Standards Gmbh System and method for application management on multi-application smart cards
US20070136501A1 (en) 2005-12-08 2007-06-14 Chang Robert C Media card command pass through methods

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
STEINER J G ET AL: "Kerberos: An Authentication service for open network system", PROCEEDINGS OF THE WINTER USENIX CONFERENCE, XX, XX, 9 February 1988 (1988-02-09), pages 1 - 15, XP002253328 *

Also Published As

Publication number Publication date
US20110131640A1 (en) 2011-06-02
EP2262164A1 (en) 2010-12-15

Similar Documents

Publication Publication Date Title
WO2009103824A1 (es) Transferencia segura de datos
JP4723251B2 (ja) 機器固有の機密保護データの安全な組み込みと利用
US8505075B2 (en) Enterprise device recovery
ES2672340T3 (es) Sistema y método para asegurar las comunicaciones Máquina a Máquina
US9609024B2 (en) Method and system for policy based authentication
ES2554491T3 (es) Aparatos y método de aplicación de una directiva de ordenador
US9467430B2 (en) Device, method, and system for secure trust anchor provisioning and protection using tamper-resistant hardware
US8789195B2 (en) Method and system for access control and data protection in digital memories, related digital memory and computer program product therefor
JP4847967B2 (ja) 多目的コンテンツ制御を備えたメモリシステム
US9838870B2 (en) Apparatus and method for authenticating network devices
US8306228B2 (en) Universal secure messaging for cryptographic modules
ES2800295T3 (es) Método de transferencia de datos y dispositivos criptográficos
ES2634024B1 (es) Método seguro para compartir datos y controlar el acceso a los mismos en la nube
JP2008524753A5 (es)
BR102012007970B1 (pt) Aparelhos e métodos para armazenamento de clientes de acesso eletrônico
US8397281B2 (en) Service assisted secret provisioning
ES2665887T3 (es) Sistema de datos seguro
EP3886355B1 (en) Decentralized management of data access and verification using data management hub
Loutrel et al. A smartcard for authentication in WLANs
Yoon et al. Security enhancement scheme for mobile device using H/W cryptographic module
WO2012013833A1 (es) Ststemas y metodos para usar claves criptografiicas

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 12309288

Country of ref document: US

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

Ref document number: 08736691

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2008736691

Country of ref document: EP