Methods and systems for distributing cryptographic data to authenticated recipients

[0001] The invention relates to the distribution of cryptographic data. More specifically, the methods and systems described in the text relate to the distribution of cryptographic data to authenticated recipients.

[0002] Conventional digital rights management systems are generally proprietary systems that offer security features - e.g., through one or more of the elements, such as encryption, access control and authentication - shared data objects stored in the system that can be accessed by system users. However, such systems generally do not include securing data objects once they have been made available to people outside the system, or securing data objects created outside the system.

[0003] Individuals may perform cryptographic functions without using a digital rights management system, such functions generally require a high level of technical complexity not available to the average person. Moreover, even for users with appropriate knowledge, standard cryptographic techniques have a number of well-known disadvantages. For example, symmetric key cryptography (e.g., Advanced Encryption Standard, The Advanced Encryption Standard (AES) used in the United States) allows password protection of data objects, but it does not prevent authorized users from sharing the password with unauthorized users, and it depends on the strength of the password. As another example, we can cite asymmetric key cryptography (also called public key cryptography), which is the basic and well-known technology used in a number of security projects; public key cryptography, however, depends on the user's ability to access another user's public key with whom the user wants to share the secured data object. Since public key maintenance is not yet generally accepted, this method is not available to many people - even a person with high technological skills will not be able to implement and perform this function wanting to share data objects with people who do not have public keys.

[0004] EP 1 903 467 A2 is a document describing the system and method of granting and obtaining rights to an object between devices. US 2007/043680 is a document describing how to transfer a digital license between the first platform and the second platform. US 2008/313699 is a document describing the management of information rights.

[0005] None of the examples known in the art provide an access control manager using a user identifier provided in information describing an encrypted data object to select an identity provider from a range of identity providers to authenticate an identified user.

[0006] An access control management system enabling the system to select an identity provider based on the role information received from the author of the message would provide a better, smooth experience for the recipient of the data.

SUMMARY OF THE INVENTION [0007] The methods and systems described in the text provide the function of distributing cryptographic data to authenticated recipients through secured or unsecured channels. According to one aspect of the present invention, a method is provided that comprises: receiving by an access control management system, from a first client device, information associated with an encrypted data object, which information includes identifying a role assigned to a user authorized to access the encrypted data object; receiving by the access control management system from a second client device requests for information related to the encrypted data object; verification by the access control management system that the user of the second client device is identified in the information received related to the encrypted data object; verification by the access control management system that the user of the second client device has been assigned the role identified in the received information; selection by the access control management system of the identity provider from a number of identity providers, based on the user identifier provided in the received information related to the encrypted data object, the user identifier associated with the user of the second client device; a request from the access control management system from the selected identity provider to authenticate the user of the second client device; and sending by the access control management system to the second client device of the received information associated with the encrypted data object in response to the authentication of the user of the second client device by the identity provider. A permanent storage medium is also readable by the computer on which the instructions are stored, which, if implemented, provide the method described above, and an access control management system consisting of memory and a processor, which access control management system operates to implement the described method.

BRIEF DESCRIPTION OF THE DRAWINGS [0008] The above description and other objects, aspects, characteristics and advantages of the description will become more obvious and better understood with reference to the further part of the description analyzed together with the attached drawings, in which:

Figures 1A-1C are block diagrams showing embodiments of computers useful in connection with the methods and systems described in the text;

Fig. 2A is a block diagram showing an embodiment of a system for distributing cryptographic data to authenticated recipients;

Fig. 2B is a block diagram illustrating an embodiment of a cryptographic data distribution system including a series of access control management systems;

Fig. 2C is a block diagram illustrating an embodiment of a cryptographic data distribution system including an application generating secure document information;

Fig. 3 is a flowchart showing an embodiment of a method of distributing cryptographic data to authenticated recipients; and

Fig. 4 is a flowchart showing another embodiment of a method of distributing cryptographic data to authenticated recipients.

DETAILED DESCRIPTION OF THE INVENTION [0009] For some embodiments of the invention, the methods and systems described in the text relate to the distribution of cryptographic data to authenticated recipients. However, before we present a detailed description of these methods and systems, a description of the network in which such methods and systems can be implemented will be provided.

[0010] Referring now to Fig. 1A, it shows an embodiment of a network environment. In short, the network environment consists of one or more clients 102a-102n (also commonly referred to as local device (devices) 102, client (clients) 102, client node (s) 102, computer (computers) ) client 102, client device (clients) 102, computing device (s) 102, device (s) 102, endpoint (s) 102, node (s) endpoint 102), communicating with one or more remote devices 106a-106n (also generally referred to as server (s) 106, device (s) 106, or computing (computing) device (s) 106) through one or more networks 104.

[0011] Although Figure 1A shows the network 104 between clients 102 and remote devices 106, clients 102 and remote devices 106 may be part of the same network 104. The network 104 may be a local area network (LAN), such as a company intranet, area network metropolitan (MAN), or wide area network (WAN) such as the Internet or the World Wide Web. In some embodiments, several network 104 is used between clients 102 and remote devices 106. In one of these embodiments, the network 104 '(not shown) may be a private network and the network 104 may be a public network. In another of these embodiments, the network 104 may be a private network and the network 104 'may be a public network. In yet another embodiment, networks 104 and 104 'may be private networks.

[0012] The network 104 may be any type and / or form of a network, and it may include any of: a point network, a transmission network, a wide area network, a local network, a telecommunications network, a data communication network, a computer network, an ATM network Asynchronous Transfer Mode, SONET networks (Synchronous Optical Network), SDH networks ( Synchronous Digital Hierarchy, synchronous digital hierarchy), wireless network and wired network. In some embodiments, the network 104 may include a wireless link, such as an infrared channel or a satellite band. The network topology 104 may be in the form of a bus, star or ring network topology. The network 104 may have any network topology known to those having skill in the field capable of handling the operations described in the text. The network may include mobile networks using any protocol or protocols used for communication between mobile devices, including AMPS, TDMA, CDMA, GSM, GPRS or UMTS. For some embodiments of the invention, different types of data may be transmitted using different protocols. For other embodiments of the invention, the same types of data may be transmitted using different protocols.

[0013] The client 102 and remote device 106 (generally referred to as computing devices 100) can be any workstation, desktop, laptop or notebook, server, handheld computer, cellular phone or other portable telecommunications device, media player, system for games, a mobile computing device or any type and / or any form of a computing, telecommunications or media device, capable of communicating with any type and form of network, with adequate processor power and memory capacity, enabling the implementation of operations described in the text. The client 102 may execute, operate or otherwise provide an application that may be any type and / or form of software, program or executable commands, including without limitation, any type and / or form web browser, web client, client-server application , ActiveX control or Java applet, or any other type and / or form with executable commands that can be executed on client 102.

[0014] In one embodiment, the computing device 106 provides a network server function. In some embodiments, the web server 106 is an open source web server, such as APACHE servers hosted by the Apache Software Foundation of Delaware. For other embodiments, the web server implements software owned by various companies, such as Internet Information Services products provided by Microsoft Corporation of Redmond, Washington, Oracle iPlanet web server products provided by Oracle Corporation of Redwood Shores, California, or BEA WEBLOGIC products supplied by BEA Systems, Santa Clara, California.

[0015] In some embodiments, the system may include several logically grouped remote devices 106. In one of these embodiments, the logical group of remote devices may be referred to as a server farm 38. In another of these embodiments, the server farm can be managed as one entity.

[0016] Figs. 1B and 1C are block diagrams of a computing device 100 useful in practicing the customer 102 or remote device 106 embodiment. As shown in Figs. 1B and 1C, each computing device 100 has a central data processing unit 121 and a main memory assembly 122. As shown in Fig. 1B, computing device 100 may have a carrier 128, installation device 116, network interface 118, I / O controller 123, screens 124a-n, keyboard 126, indicator device 127, such as a mouse, and one or more other I / O devices 130a -n. Media 128 may include, without limitation, the operating system and software. As shown in fig. 1C, each computing device 100 may also include additional optional components such as memory slot 103, bridge 170, one or more input / output devices 130a-130n (generally designated by reference numeral 130), and cache memory 140 communicating with the processor 121.

[0017] Processor 121 is any logic circuit responding to and processing commands retrieved from the main memory assembly 122. In many embodiments, the processor 121 is in the form of a microprocessor assembly, such as: assemblies manufactured by Intel Corporation based in Mountain View, California; teams manufactured by Motorola Corporation based in Schaumburg, Illinois; teams manufactured by Transmeta Corporation based in Santa Clara, California; teams produced by International Business Machines from White Plains, New York; or assemblies manufactured by Advanced Micro Devices from Sunnyvale, California. Computing device 100 may be based on any of these processors, or on any other processor capable of operating as described in the text.

[0018] The main memory assembly 122 may be one or more of the memory chips capable of storing data and providing access to any storage location for the microprocessor 121. The main memory 122 may be based on any available memory chips capable of working as described in the text. In the embodiment of the invention shown in Fig. 1B, the processor 121 communicates with the main memory 122 via the system bus 150. Fig. 1C shows an embodiment of a computing device 100 in which the processor communicates directly with the main memory 122 via a memory socket 103. Fig. 1C also shows an embodiment in which the main processor 121 communicates directly with the cache memory 140 using an additional bus, sometimes referred to as the rear bus. In other embodiments, the main processor 121 communicates with the cache 140 using system bus 150.

[0019] In the embodiment of the invention shown in Fig. 1B, the processor 121 communicates with various I / O devices 130 via local system bus 150. The processor 121 can be connected to any of the I / O devices 130 using different buses, such as the VESA VL bus, ISA bus, EISA bus, MicroChannel Architecture (MCA) bus, PCI bus, PCI-X bus, PCI-Express bus, or NuBus bus. In the case of embodiments of the invention in which the I / O device is an image display 124, the processor 121 may use an Advanced Graphics Port (AGP) socket to communicate with the display 124. Fig. 1C illustrates an embodiment of a computer 100 in which the main processor 121 communicates also directly with the I / O device 130b, for example using HYPERTRANSPORT, RAPIDIO or INFINIBAND communication technologies.

[0020] Computing device 100 may be equipped with a wide range of 130a-130n I / O devices. Input devices include keyboards, mice, trackpads, trackballs, microphones, scanners, cameras and drawing tablets. Output devices include video displays, speakers, inkjet printers, laser printers and dye sublimation printers. The I / O devices can be controlled by the I / O controller 123, as shown in Figure 1B. The I / O device may also have a recording medium and / or installation media 116 for the computing device 100. In some embodiments, the computing device 100 may provide USB connections (not shown) for connecting a USB portable data storage device such as a USB Flash drive line manufactured by Twintech Industry, Inc. based in Los Alamitos, California.

[0021] Referring still to Figure 1B, the computing device 100 can support any suitable installation device 116, such as a floppy disk drive capable of accommodating media such as 3.5-inch floppy disks, 5.25-inch floppy disks or disks ZIP, CD-ROM drive, CD-R / RW drive, DVD-ROM drive, various format tape drives, USB device, hard disk or any other device suitable for the installation of software and programs. Computing device 100 may also include a data carrier, such as one or more hard disks, or redundant series of independent disks for storing the operating system and other software on them.

[0022] The computing device 100 may also have a network interface 118 enabling connection to the network 104 via a series of connections, including but not limited to standard telephone lines, LAN or WAN links (e.g., 802.11, T1, T3, 56kb, X.25, SNA, DECNET), broadband connections (e.g. ISDN, Frame Relay, ATM, Gigabit Ethernet, Ethernet10 over-SONET), wireless connections or a combination of any or all of these connections. Connections can be established using a number of protocols (e.g. TCP / IP, IPX, SPX, NetBIOS, Ethernet, ARCNET, SONET, SDH, Fiber Distributed Data Interface (FDDI), RS232, IEEE 802.11, IEEE 802.11a, IEEE 802.11 b, IEEE 802.11g, IEEE 802.11n, CDMA, GSM, WiMax and direct asynchronous connection). In one embodiment of the invention, the computing device 100 communicates with other computing devices 100 'through any type and / or any form of gateway or tunneling protocol, such as Secure Socket Layer (SSL) or Transport Layer Security (TLS). The network interface 118 may be a built-in network adapter, network interface card, PCMCIA network adapter, card bus network adapter, wireless network adapter, USB network adapter, modem or any other device suitable for connecting the computing device 100 to any type of network capable of communicating and implementation of operations described in the text.

[0023] In some embodiments of the invention, the computing device 100 may have or be connected to a series of display devices 124a-124n, each of which may be of the same type and / or form. As such, any of the I / O devices 130a-130n and / or I / O controller 123 may be any type and / or form of hardware, software or a combination of hardware and software, supporting, enabling or providing the computing device 100 with the connection and use of a number of devices displaying 124a-124n. A person with typical skills in the field will recognize and appreciate the fact that it is possible to configure the computing device 100 so that it has multiple display devices 124a-124n.

[0024] In further embodiments, the I / O device 130 may be a bridge between the system bus 150 and an external communication bus such as USB bus, Apple Desktop Bus, RS-232 serial connection, SCSI bus, FireWire bus, FireWire bus 800, Ethernet bus, AppleTalk bus, Gigabit Ethernet bus, Asynchronous Transfer Mode bus, HIPPI bus, Super HIPPI bus, SerialPlus bus, SCI / LAMP bus, FibreChannel bus, or Serial Attached small computer systems interface bus.

[0025] Computing device 100 of the type shown in Figures 1B and 1C generally works under the control of operating systems that control task scheduling and access to system resources. Computing device 100 can work in any operating system, such as any of the versions of the MICROSOFT WINDOWS operating systems, various editions of the Unix and Linux operating systems, any version of the MAC OS for Macintosh computers, any built operating system, any real-time operating system, any system open source operating system, any commercial operating system, any operating system for mobile computing devices, or any other operating system that can work on a computing device and perform the operations described in the text. Typical operating systems include, but are not limited to, WINDOWS 3.x, WINDOWS 95, WINDOWS 98, WINDOWS 2000, WINDOWS NT 3.51, WINDOWS NT 4.0, WINDOWS CE, WINDOWS XP, WINDOWS 7 and WINDOWS VISTA, all manufactured by Microsoft Corporation based in Redmond, Washington; MAC OS, manufactured by Apple Inc., based in Cupertino, California; OS / 2, manufactured by International Business Machines based in Armonk, New York; or any type and / or form of Unix operating system.

[0026] The computing device may be any workstation, desktop, laptop or notebook, server, portable computer, cellular telephone or other portable telecommunications device, media player, gaming system, mobile computing device or any type and / or any forms by a computing, telecommunications or media device capable of communication, with adequate processor power and memory capacity, enabling the implementation of operations described in the text. In some embodiments, the computing device 100 may have various processors, operating systems and input devices compatible with the device. In other embodiments, the computing device 100 is a mobile device, such as a mobile phone supporting JAVA or a digital personal assistant (PDA). Computing device 100 may be a mobile device, such as devices manufactured, for example and without limitation, by Motorola Corp. based in Schaumburg, Illinois; Kyocera of Kyoto, Japan; Samsung Electronics Co., Ltd., based in Seoul, South Korea; Nokia from Finland; Hewlett-Packard Development Company, LP and / or Palm, Inc., based in Sunnyvale, California, USA; Sony Ericsson Mobile Communications AB based in Lund, Sweden; or Research In Motion Limited, based in Waterloo, Ontario, Canada. In yet other embodiments, the computing device 100 is a smartphone, a Pocket PC, a Pocket PC Phone, or other portable device that supports Microsoft Windows Mobile.

[0027] In some embodiments, the computing device 100 is a digital audio player. In one of these embodiments, the computing device 100 is a digital audio player, such as the Apple IPOD, IPOD Touch, IPOD NANO, and IPOD SHUFFLE product lines manufactured by Apple Inc., based in Cupertino, California. In another of these embodiments, the digital audio player can act as both a portable media player and a mass storage medium. In other embodiments, the computing device 100 is a digital audio player, such as players manufactured, for example, and without limitation, by Samsung Electronics America, based in Ridgefield Park, NJ, Motorola Inc. based in Schaumburg, IL, or Creative Technologies Ltd. based in Singapore. In yet other embodiments, the computing device 100 is a portable media player or digital audio player that supports file formats such as, among others, MP3, WAV, M4A / AAC, WMA Protected AAC, AEFF, Audible audio books, file formats audio without losing Apple quality and video formats .mov, .m4v and .mp4 MPEG-4 (H.264 / MPEG-4 AVC).

[0028] In some embodiments, the computing device 100 is a combination of devices, such as a cell phone connected to a digital audio player or portable media player. In one of these embodiments, the computing device 100 is a device from a series of Motorola devices being a combination of digital audio players and mobile phones. In another of these embodiments, the computing device 100 is a device from the iPhone smartphone line manufactured by Apple Inc., based in Cupertino, California. In yet another of these embodiments, the computing device 100 is a device implementing the open source platform for Android mobile phones distributed by the Open Handset Alliance; device 100 may be, for example, a device such as devices provided by Samsung Electronics based in Seoul, South Korea, or HTC Headquarters based in Taiwan, PRC. In other embodiments, the computing device 100 is a tablet, such as, without limitation, the iPad series tablets, manufactured by Apple Inc .; PlayBook, manufactured by Research in Motion; Cruz series manufactured by Velocity Micro, Inc., based in Richmond, VA; Folio and Thrive series produced by Toshiba America Information Systems, Inc., based in Irvine, CA: series

Galaxy manufactured by Samsung; HP Slate series manufactured by Hewlett-Packard; and the Streak series manufactured by Dell, Inc., based in Round Rock, TX.

[0029] In one embodiment, the methods and arrangements described in the text provide a function that allows the user to specify persons who can access the data object regardless of whether the recipients are members of the same access control management system as the user or any control management system. access. In another embodiment, the methods and arrangements described in the text provide a function that enables the user to distribute the secured data object through an unsecured channel, and to distribute cryptographic data that allows access to the secured data object through a separate, secure channel, with authentication, access control and secure creation channels are implemented by the access control management system; an authenticated user can authenticate himself through an external identity provider, receive cryptographic data from the access control management system, and access the data object. In such an embodiment, the methods and arrangements described in the text provide separability of access control and authentication once data storage and distribution.

[0030] Referring now to Fig. 2A, the block diagram illustrates one of the embodiments of a system for distributing cryptographic data to authenticated recipients. In short, this system includes access control management system 202, identity provider 204, device 106an, client device 102 an, encrypted data object 206 and information 208 related to encrypted data object 206. In some of the embodiments, the client devices 102a-n are clients 102 as described above with reference to Figs. 1A-C. In other embodiments, access control management system 202 and identity provider 204 are performed on device 16a-n. Devices 106a-n may be remote devices 106 as described above in Figs. 1A-C. In further embodiments of the invention, devices 106 and customer devices 102 exchange data via networks 104, as described above with reference to Figs. 1A-1C.

[0031] Referring now to Fig. 2B, the block diagram illustrates an embodiment of a cryptographic data distribution system including a number of access control management systems. As shown in FIG. 2B, the system 200 of FIG. 2A includes a series of 202a-n access control management systems (generally referred to as 202 access control management systems), and a number of 204a-n identity providers (generally referred to as 204 identity providers ). As described in more detail below with reference to Fig. 3, the user of the client device 102a may select the same or different access control management systems 202 for different recipients of the encrypted data object, and each access control management system 202 may select the same or different providers 204 authenticating different recipients. [0032] Referring now to Fig. 2C, the block diagram illustrates an embodiment of a cryptographic data distribution system 200 including a secure object information generator 210 and a secure object information reader 212. In one embodiment, the secure object information generator 210 is a software application executed on the client device 102a, with which the user of the client device 102a can generate information 208 associated with the encrypted data object 206; for example and without limitation, a secure object information generator can be provided as a stand-alone software application, or as a plug-in or add-on to software executed on a client device 102a. In another embodiment, the user of the client device 102a performs the secure object information generator 210 to encrypt the document, thereby generating the encrypted data object 206.

[0033] In one embodiment, the data object can be any type of document, any type of media file or other data object. In another embodiment, the data object is data in a native format that supports encryption (e.g. PDF, compressed files, files created using a text editor such as the MICROSOFT WORD application, for example). In yet another embodiment, the data object is data in a format that does not natively support encryption.

In one embodiment, the encrypted data object 206 includes a document in a self-description format (e.g., eXtended Markup Language (XML)) supporting strong symmetric encryption, digital signatures through asymmetric encryption, unique identifiers and data objects (e.g., documents , images, multimedia, documents in Portable Document Format (PDF). In another embodiment, the encrypted data object 206 includes a unique identifier, display name, and identification of the type of data object.

[0035] In some of the embodiments, the encrypted data object 206 has an access control circuit identifier 202. In one of these embodiments, the secure object information generator 210 includes an identifier (which may be provided, for example and without limitation, in the form of a homogeneous resource locating element), and the computing device 102b uses the identifier to request information 208 from the management system access control 202. In another of such embodiments, the access control management identifier 202 is included in the unencrypted portion of the encrypted data object 206, such as the unencrypted header.

[0036] In some embodiments, the secure object information generator 210 is equipped with a data object encryption function. In one of these embodiments, the secure object information generator 210 includes at least one encryption engine that encrypts or decrypts data objects. In other embodiments, the secure object information generator 210 generates an identifier for the encrypted data object 210 and includes the identifier in information 208 sent to the access management system 202. In other embodiments, the secure object information generator 210 requires that the control management system Access 202 generated an identifier for the encrypted data object 206.

[0037] In one embodiment, the secure object information generator 210 processes the data object to generate the encrypted data object 206 and information 208 associated with the encrypted data object 206. The information 208 may be, for example, a registration load containing information such as an encryption key used to encrypt data object 206, and an access control list specifying users who may receive an encryption key to decrypt data object 206. In one of the embodiments, information 208 includes at least one user identification element authorized to receive the encryption key, for example information 208 includes an email address for each authorized user.

[0038] In some embodiments, information 208 includes the identifier of computing devices authorized to receive information 208. For example, the user of the first computing device 102a may specify that the second user may receive information 208 only on the specific device (for example, denying the second user access to information 208 from the mobile device or public point); alternatively, the user of the first computing device 102a may specify that any user of the specific device may access information 208 (e.g., allowing all members of the department in which the secured device is located to access information 208). In one of these embodiments, the information 208 includes the identification of the authorized device, which may be any device 102 or 106, as described above with reference to Fig. 1A1C. in another of these embodiments, information 208 includes the identification of the authorized device in accordance with the Trusted Platform Module specification propagated by the Trusted Computing Group based in Beaverton, OR, USA. In yet another of these embodiments, when authorizing a device that complies with the Trusted Platform Module specification as the recipient of information 208, the user of the first computing device 102a may indicate that access control management system 202 does not need to authenticate users of the authorized device because the device itself has some characteristics that enable the user to trust the security of the device.

[0039] In one embodiment, the information 208 includes a group of authorized users instead of or in addition to specific user authorization; information 28 may identify a specific department, company, entity or other number of users authorized to receive information 208. In another embodiment, the information 208 includes an indication that the authorized user may delegate access; for example, the sending user may specify that the receiving user (such as a doctor) may delegate access to other users (such as a nurse, hospital manager, resident, or other work colleague), and the sending user may specify the characteristics of authorized persons to whom the authorized user may delegate access (e.g. any person whose email address has the ending "@ HipotetycznySzpital.org").

[0040] For some embodiments, the information 208 includes a time limit; for example, the user may specify that the identified second user may receive information 208 at specified times (e.g., during presentations, consultations, joint ventures, and any time frame). Information 208 may be generated separately from the encrypted data object 206 and may be transmitted separately from the encrypted data object 206.

[0041] In one embodiment, information 208 includes a specification of data protection mechanisms implemented for encrypted data object 206, including whether the encrypted data object 206 can be copied, pasted, emailed or otherwise distributed to other unauthorized recipients, print and / or take screenshots with or without added, hidden "watermarks" in the data object, enabling backward tracking of data to the application 210 or 212 which has opened data object 206, which are functions that the system can disable when the encrypted data object 206 is then opened by an authorized user. For example, the user of the first computing device 102a may prevent "screen printing" on operating systems normally supporting the screen printing function; if the user wants to disable the screen printing function, the information 208 can be accompanied by commands activating the existing digital rights management program containing countermeasures, in which case countermeasures will be activated when the authorized recipient decrypts the encrypted data object 206.

[0042] In some embodiments, the secure object information reader 212 allows the user to access information 208 generated by the secure object information generator 210. In some embodiments, and as will be described in greater detail below, the secure object reader 212 has a function that allows the user to communicate with access control management system 202 and identity provider 204 to authenticate, necessary to receive information 208 . In other embodiments, the secure object information generator 210 includes at least one encryption engine that encrypts or decrypts data objects. In other embodiments, the secure object information generator 210 and the secure object information reader 212 are provided in the form of application plugins, internet services or stand-alone applications.

[0043] Access control management system 202 allows access control using decentralized identity management, based on external identity providers authenticating the user identity. In one embodiment, the access control management system 202 is provided with the function of accessing information 208 generated by the secure object information generator 210 The access control management system 202 may, for example, include a secure object information reader 212 receiving and processing information 208 .

[0044] In one embodiment, the access control management system 202 has an identity provider selection element 214 identifying a series of identity providers 204 and selecting one of a series of identity providers 204 to authenticate the user of the client device 102b. For example, identity provider selection element 214 may receive a list of user identifiers from the secure object information reader 212 and analyze each said user identifier to determine access to the respective identity provider 204 to authenticate each said user identifier; for example, by analyzing the domain name contained in the user identifier and sending to the database a request to identify the identity provider 204 associated with the domain name being analyzed. In another embodiment, the access control management system 202 uses an interface with the identity provider 204, by which the access control management system can request authentication. The access control management system 202 may, for example, create an interface with the identity provider 204 providing an interface in accordance with the generally accepted identity standard, such as OpenID, information card (InfoCard) or SAML. In yet another embodiment, the access control management system 202 has a function to enable communication with identity providers using different communication standards.

[0045] Access control management system 202 has a function to check whether the user of the second client device 102b is identified in the received information associated with the encrypted data object. Access control management system 202 may have a function to analyze the information 208 received to determine whether the information 208 includes a user identifier. As another example, access control management system 202 may be provided having the function of analyzing the access control list contained in the information 208 received to determine whether the user is on the access control list.

[0046] In some embodiments, the access control management system 202 supports Role-Based Access Control (RBAC). RBAC is an existing access control framework in which file access is controlled based on the roles assigned to users instead of based on the user's personal identity. For some embodiments of the access control management system 202, information 208 includes specific properties or roles, and the access control management system 202 makes access control decisions based on whether the user has the property or role corresponding to the authorization.

[0047] In some embodiments, the access control management system 202 includes a transaction log in which the system records the identification of at least one of the elements: transactions, users, groups, roles, information 208 associated with each user, policies and business rules. In one of these embodiments, the access control management system 202 assigns unique identifiers to data objects and sends the unique identifier to the secure object information generator 210, generating information 208. By tracking access requests, valid and invalid, it is possible to collect statistics about it, who gains access to the data and for how long, and from where unauthorized access attempts are made. This feature can allow data owners or managers to understand what data objects are useful and who they can add or remove to or from access control lists.

[0048] Referring now to Fig. 3, the block diagram illustrates one of the embodiments of a method 300 for distributing cryptographic data to authenticated recipients. Briefly, the method 300 includes receiving by the access control management system, from the first client device, information associated with the encrypted data object (302). The method 300 includes receiving by the access control management system, from a second client device, a request for information related to the encrypted data object (304). The method 300 includes verifying by the access control management system whether the user of the second client device is identified in the information received associated with the encrypted data object (306). The method 300 includes authentication by the access control management system, together with the identity provider, of the user of the second client device (308). The method 300 includes sending by the access control management system to the second client device received information related to the encrypted data object (310).

[0049] Referring now to Fig. 3, in more detail and in connection with Figs. 2A-2C, the access control management system receives information related to the encrypted data object (302) from the first client device. In one of the embodiments, before sending information 208 to the access control management system 202, the user of the first client device 102 starts the secure object information generator 210 to encrypt data object 206 and generate information 208.

[0050] In one embodiment, the secure object information generator 210 generates information 208 based on information provided by the user of the first client device 102a. In another embodiment, information 208 includes data object identifier 206, cryptographic data associated with the encrypted data object 206 (e.g. encryption key encrypted data object 206), and identification of each person authorized to receive cryptographic data. In yet another embodiment, information 208 includes data object identifier 206 and cryptographic data associated with the encrypted data object 206 (e.g., the encryption key of the encrypted data object 206). In this embodiment, the user of the first client device 102a may provide identification of each person authorized to receive cryptographic data, regardless of information 208. In some embodiments, the secure object information generator 210 includes an encryption engine used to generate cryptographic data. In other embodiments, the secure object information generator 210 executes an encryption engine on a computing device 102a that generates cryptographic data.

[0051] In some embodiments, the access control management system 202 receives information 208 from the first client device 102a via an interface connecting the secure object information generator 210 implemented on the first client device 102a with the secure object information reader 212 performed in the access control management system 202. In one of these embodiments, for example, the secure object information generator 210 performed on the first client device 102a and the secure object information reader 212 use the Secure protocol for communication

Socket Layers (SSL) or Transport Layer Security (TLS). In other embodiments, the access control management system 202 and the first client device 102a establish a secure connection to transmit information 208 independently of the secure object information generator 210 and the secure object information reader.

[0052] In some embodiments, the access control management system 202 receives an indication that the first client device 102a has selected the access control management system 202 from a series of access control management systems 202a-n to store information 208 associated with the encrypted data object 206. In one case among these embodiments, the access control management system 202 receives an indication from the first client device 102a.

[0053] In some embodiments, the access control management system 202 authenticates the user of the first client device 102a. For example, the access control management system 202 may authenticate the user of the first client device 102a upon receiving notification that the first client device 102a has selected the access control management system 202 from a series of access control management systems 202a-n to store information 208 associated with the encrypted data object 206. In such embodiments, the access control management system 202 authenticates the user of the first client device 102a together with the identity provider 204. In another of these embodiments, the access control management system 202 identifies the second identity provider 204b to authenticate the user of the first client device 102a. In other of these embodiments, the access control management system 202 uses the interface provided by the secure client information reader 212 to communicate with the secure client information generator 210 performed on the first client device 102 using the interface and authenticating the user of the first device client 102a via the interface. For example, access control management 202 may use Secure Socket Layers (SSL) or Transport Layer Security (TLS) to communicate with the first client device 102a.

[0054] In one embodiment, the access control management system 202 and the first client device 102a exchange a common secret key. In another embodiment, the first client device 102a encrypts information 208 associated with the encrypted data object 206 using a common secret key. In yet another embodiment, the first client device 102a sends encrypted information 208 to access control management 202. In some embodiments, the secure object information generator 210 executed on the first client device 102a includes a public key associated with the access control management system 202, by which the first client device 102a can establish a secure connection with the access control management system 202. In other embodiments, the access control management system 202 creates a secure connection channel with the first client device 102a by using well-known key exchange protocols.

[0055] In one embodiment, the access control management system 202 receives information 208 containing the access control list associated with the encrypted data object 206. In another embodiment, the access control management system 202 receives information 208 containing a cryptographic key to be used in as part of decrypting the encrypted data object 206. In yet another embodiment, the access control management system 202 stores the received information 208.

[0056] In some embodiments, the access control management system 202 receives information including a user identifier associated with a user of the second client device 102b. In one of these embodiments, the access control management system 202 selects the identity provider 204a by which it authenticates the user of the second client device 102b from the series of identity providers 204a-n based on the received user identifier.

[0057] In one embodiment, the access control management system 202 provides a connection interface with a user of the first client device 102a able to modify information 208 recorded by the access control management system 202. In another embodiment, the user of the first client device 102a generates a modified information version 208 and sends the modified version to access control management system 202. For some embodiments, the ability to modify an existing list of authorized users as part of information 208 enables users to quickly add or remove access - for example, when hiring and firing employees, or providing consultants with short-term access to secure data.

[0058] In one embodiment, the access control management system 202 stores the received information 208 in a database. In some embodiments, the database is a database that complies with the ODBC standard. For example, the database may be in the form of an ORACLE database, manufactured by Oracle Corporation based in Redwood Shores, CA. In other embodiments, the database may be Microsoft ACCESS database or Microsoft SQL server database, manufactured by Microsoft Corporation based in Redmond, WA. In yet other embodiments, the database may be a freely selectable database based on an open source database, such as the family of free MYSQL database products distributed by MySQL AB Corporation based in Uppsala, Sweden. For other embodiments, the sample databases include, without limitation, structured write databases (e.g., NoSQL databases and BigTable databases), HBase databases distributed by The Apache Software Foundation based in Forest Hill, MD, databases MongoDB distributed by 10Gen, Inc., based in New York, NY, and Cassandra database distributed by The Apache Software Foundation based in Forest Hill, MD. In further embodiments, the database may be any type or form of database.

[0059] The access control management system receives from the second client device a request for information related to the encrypted data object (304). In one of the embodiments, the second client device 102b sends the request to the access control management system 202 upon receiving the request to send the request from the first client device 102a. In one embodiment, the first client device 102a sends encrypted data to the second client device 102b. The user of the first client device 102a may send a command to the user of the second client device 102b, for example and without limitation, using electronic communication, such as an e-mail message (e.g., "e-mail") or a message sent using the short message service protocol ( e.g. "text message"). For example, the user of the first client device 102a may send a message to the user of the second client device 102b containing an encrypted data object and a command to download the cryptographic data necessary to decrypt the document from the access control management system 202 (e.g., using the URL provided in the message providing a link to access control management system 202). As another example, when a user of the second client device 102b attempts to access the encrypted data object 206, the user is instructed to execute the secure information reader of the object 212, which can automatically start the user authentication process and establish a secure connection with the access control management 202. In some embodiments, the user of the second client device 102b includes the identity provider identifier 204 in the information request 208.

[0060] In some embodiments, the user of the second client device 102b does not need to have an account or any type of dependency on access control management 202; the user-dependency of the second client device 102 with the identity provider is sufficient to authenticate the user, as described in more detail below. In one embodiment, when the user of the second client device 102b has no relationship with either the access control management system 202 or the identity provider 204, the access control management system 202 sends a message to the other client device 102b (e.g., message e-mail) containing a secure link to the access control management system 202 and enabling the user of the second client device 102b to create an account. However, many popular email account providers also act as identity providers (e.g., popular providers such as Google, Inc., based in Mountain View, CA, USA and AOL, Inc., based in Dulles, VA, USA, have implemented OpenID standard, so they are also identity providers 204).

[0061] The access control management system also checks if the user of the second client device is identified in the information received associated with the encrypted data object (306). In one embodiment, the information received 208 includes an access control list identifying users to whom the access control management system 202 may transmit information 208 [0062] In some embodiments, the access control management system 202 has a function to check whether the user of the second client device 102b is identified in the information received 208. In one of such embodiments, the function provided by the access control management system 202 is distributed to several devices 106. For example, and without limitation, the access control management system 202 may implement the role-based user evaluation of the second client device 102b; the access control management system 202, e.g., perform the first element to verify that the user of the second client device is identified in the information received 208 and he can perform the second element to verify that the role of association with the user is the role specified in the information 208. For example, information 208 may specify that cardiologists at a particular hospital may receive a subset of information 208 (e.g., a cryptographic key) and the user of the second client device 102b may indicate that he is a doctor at a particular hospital; the first item can check if the hospital is listed in information 208, and the second item can check if the doctor is a cardiologist at that hospital. In such an embodiment, the first element and the second element may be implemented on the same or different devices. For example, the first element may be performed on device 106a with access control management 202 and the second element may be performed on device 106c located in the hospital and communicating with device 106a. In another example, the access control management system 202 implemented on the device 106a is provided with the functions of the first element and the second element. In some embodiments, the access control management system 202 includes a policy information point. In some embodiments, the access control management system 202 includes a policy decision point. For further embodiments of the access control management system 202, the first element and the second element may perform the function of evaluation and enforcement policies [0063] The access control management system authenticates, together with the identity provider, the user of the second client device (308). For embodiments such as the examples shown in Fig. 2B, the system

200 may include a number of identity providers 204, of which access control management 202 identifies an identity provider 204 capable of authenticating a user of a second client device 120b. In one embodiment, access control management 202 determines whether the identity provider 204 stores user authentication information of a second client device 102b, based on the user ID. For example, information 208 may include a user identifier.

[0064] In one embodiment, the access control management system 202 sends to the identity provider 204 a user authentication request of the second client device 102b; then the identity provider 204 communicates with the second client device 102b to authenticate the user. For example, the identity provider 204 may request that the user of the second client device 102b send the username and password of the identity provider 204 to complete the authentication process. Identity Provider 204 may use any method of user authentication; for example and without restrictions, the identity provider 204 may implement authentication techniques based on biometric parameters, hardware tokens, one-time password keys and smartphone codes, as well as authentication techniques based on the identities of customer devices.

[0065] In one embodiment, according to the above discussion, the access control management system 202 retrieves the user identifier (such as email address) from information 208 and identifies the identity provider 204 that can authenticate the user of the second client device 102b based on the identifier user. In one such embodiment, the access control management system 202 uses the domain name in the user identifier (e.g. the portion of the email address following the @ symbol to search for the identity provider 204. In another such embodiment, the access control management system 202 accesses the database to search for the identity provider 204 (e.g., the database in the management system) access control 202 or managed by a third party) In this type of embodiment, the access control management system 202 receives information with the possibility of personal identification (e.g. the email address of the user of the second client device 102b, before user authentication. In another embodiment, the user of the second client device 102b provides access control management system 202 with identity provider identifier 204; for example, the identifier may be a URL directing access control management 202 to identity provider 204 to initiate the authentication process. In one example of such an embodiment, the access control management system 202 does not receive information with the ability to personally identify the user of the other client device 102b (e.g., email address) until the authentication process is completed. In another embodiment, the user of the second client device 102b provides an access control management system 202 with a URL (e.g. fully qualified OpenID URL address) directing access control management system 202 to the resource controlled by identity provider 204, which access control management system 202 can use to initiate the authentication process. For one example of such an embodiment, the discovery of the identity provider 204 is not required because the identity provider 204 is explicitly specified in the URL. In the case of another example of such an embodiment, the user of the second client device 102b provides access control management system 202 with information identifying the user (e.g., URL or portion thereof).

[0066] For some embodiments, if a person other than the target user accesses the user's client device 102, opens the secure object information generator 210 or secure object information reader 212 and attempts to open data object 206, the person will need to know the information identifying the user, stored by the identity provider 204 (e.g. user email password), or meet authentication criteria to get authenticated. In this way, protection against hackers or thieves trying to access protected files is provided.

[0067] In some embodiments, the implementation of the methods and systems described in the text adds an additional layer of protection by separating the locations where the following elements are located: (1) encrypted data object 206, (2) information 208, and (3) authentication information with which the user of the second client device 102b authenticates to the identity provider 204; for example, neither the encrypted data object 206 nor the authentication information is stored in the access control management system 202.

[0068] The access control management system sends the received information related to the encrypted data object (310) to the second client device. In one embodiment, the access control management system 202 establishes a secure connection to the second client device 102b at the time the user authenticates the second client device 102b. In some embodiments, the secure object information reader 212 executed on the second client device 102b includes a public key associated with the access control management system 202, by which the second client device 102b can establish a secure connection with the access control management system 202. In other embodiments, the access control management system 202 creates a secure connection channel with the second client device 102b by using well-known key exchange protocols. In further embodiments, the second client device 102b sends the encrypted data object identification 206 to the access control management system 202 requesting information 208, via the created communication channel.

[0069] In some embodiments, the access control management system 202 sends all received information 208 to the second client device 102b. In some embodiments, the access control management system 202 sends a subset of the information received 208 to the second client device 102b. For example, in the case where the information 208 contains an access control list and a cryptographic key, the access control management system may simply send the cryptographic key to the second client device 102b, or the access control management system 202 may send both the access control list and the cryptographic key . In one embodiment, the second client device 102b decrypts the encrypted data object 206 using the cryptographic key contained in the received information 208 associated with the encrypted data object 206. In some embodiments, the user of the second client device 102b does not gain access to the cryptographic key. but the key is provided to trusted services and applications in memory 122. In one of these embodiments, the cryptographic key is not stored on the data carrier 128 of the second client device 102b, preventing the user of the second client device 102b from directly accessing the cryptographic key. In other embodiments, the cryptographic keys are provided in the form of a permanent ticket (similar to an online cookie). In this way, users can decrypt the encrypted data object 206 to view it, even in the absence of network access to the access control management system 202. In one of these embodiments, a locally available authentication mechanism is used that can also protect the ticket stored on the data carrier 128; such a mechanism can be provided directly by a secure PKI hardware token that the user uses to directly authenticate with the client device 102, or at least to unblock the ticket.

[0070] In some embodiments, the access control management system 202 uses the same identity provider that requests access to information 208. In other embodiments, the access control management system 202 uses different identity providers 204 to authenticate different users. In one of these embodiments, the access control management system 202 selects the first identity provider 204a to authenticate the user of the second client device 102b. In another of such embodiments, the access control management system 202 receives from the third client device 102c a request for information 208 associated with the encrypted data object 206. In yet another of these embodiments, the access control management system 202 checks if the user of the third client device 102c is identified in the information received associated with the encrypted data object. In other such embodiments, the access control management system 202 authenticates the user of the third client device 102c together with the second identity provider 204b. In yet another of these embodiments, the access control management system 202 sends the received information 208 associated with the encrypted data object 206 to the authenticated user of the third client device 102c.

[0071] Still referring to Fig. 3, and in connection with Figs. 2A-2C, system 200 may include a number of 202a-n access control management systems. In some embodiments, the user of the first client device 102a selects different access control management systems 202 for different recipients of the encrypted data object 206. In one of such embodiments, the second access control management system 202b receives information 208 associated with the encrypted data object 206 from the first client device 102a. In another of such embodiments, the second access control management system 202b receives a request from the third client device 102c information 208 associated with the encrypted data object 206. In yet another of such embodiments, the second access control management system 202b checks if the user of the third client device 102c is identified in the received information 208 associated with the encrypted data object 206; for example, the second access control management system 202b may check if the user of the third client device 102 is identified in the received information 208 as described above with reference to Fig. 3 (306). In another of these embodiments, the second access control management circuit 202b authenticates the user of the third client device 102c; for example, the second access control management system 202b may authenticate the user of the third client device 102 according to the above description associated with Fig. 3 (308). In one embodiment, the second access control management system 202b authenticates the user of the third client device 102c with the identity provider 204. In another embodiment, the second access control management system 202b authenticates the user of the third client device 102c with the second identity provider 204b . In yet another of such embodiments, the second access control management system 202b sends to the user of the third client device 102c the received information 208 associated with the encrypted data object 206; for example, the second access control management system 202b may authenticate the user of the third client device 102 as described above with reference to Fig. 3 (310).

[0072] Referring now to Fig. 4, the block diagram illustrates one of the embodiments of a method 400 for distributing cryptographic data to authenticated recipients. The method 400 includes generating by the first client device (i) an encrypted data object, and (ii) information related to the encrypted data object (402). Method 400 includes selecting one of a series of remote access control management systems (404) by the first client device. Method 400 includes sending by the first client device information associated with the encrypted data object (406) to a system selected from a series of remote access control management systems. Method 400 includes sending the first client device of the encrypted data object (408) to the second client device. Method 400 includes requesting by the second client device information related to the encrypted data object (410) from a system selected from a series of remote access control management systems. Method 400 includes verification by a system selected from among access control management systems whether a user of the second client device is authorized to receive information related to the encrypted data object (412). Method 400 includes user authentication of the second client device (414) Method 400 includes sending by the system selected from a series of remote access control management systems information associated with the encrypted data object to the second client device. Method 400 includes decrypting the encrypted data object by the second client device together with information related to the encrypted data object (418).

[0073] Referring now to Fig. 4, and in connection with Figs. 2A-2C and 3, the first client device 102a generates (i) an encrypted data object 206 and (ii) information 208 associated with the encrypted data object 206 (402) . In one embodiment, the user of the first client device 102a performs the secure object information generator 210 to encrypt the data object, generate the encrypted data object 206, and information 208 associated with the encrypted data object 206. In some embodiments, the secure object information generator 210 provides an interface through which the user of the first client device 120a can determine the allowed recipients of the information 208; The secure object information generator 210 may, for example, provide a graphical user interface into which a user may enter email addresses or other information identifying each authorized recipient.

[0074] The first client device 102a selects one of a series of remote access control management systems 202 (404). In some embodiments, the secure object information generator 210 executed on the first client device 102a records the identification of available access control management systems 202. In one of these embodiments, the user of the first client device 102a determines the access control management system 202 to be used. In another of such embodiments, the user of the first client device 102a may customize the identification of available access control management systems 202 (e.g., by adding, removing or modifying the access control management systems 202 included in the identification). In other embodiments, the access control management system 202 provides identification by which the user of the first client device 102a can customize the identification of available access control management systems 202 (e.g., by publishing the URL).

[0075] The first client device 102 sends to the system selected from a series of remote access control management systems 202 information 208 associated with the encrypted data object 206 (406). In one embodiment, the secure object information generator 210 transmits information 208 to the selected access control management system 202. In another embodiment, the access control management system 202 receives information 208 as described above with reference to Fig. 3 (302).

[0076] The first client device 102a sends to the second client device 102b, an encrypted data object 206 (408). The user of the first computing device 102a may distribute the encrypted data object 206 by any means, including, for example and without limitation, attaching the object to an email, sending it to a "cloud" service (e.g. by saving the encrypted data object 206 to the third party file sharing and saving service), and publishing the object on the website. In some embodiments, existing e-mail systems are used to send the encrypted data object 206 as an e-mail attachment. In one of such embodiments, the email layout is used to send email with the encrypted data object 206 when the email layout supports the encrypted data object 206 as an important type of email content; for example, existing email layouts can be modified to recognize the type of email content by updating or supplementing, such as additional features or a software plug-in.

[0077] The second client device 102b sends to the system selected from a series of remote access control management systems 202 information related to the encrypted data object 206 (410). In one embodiment, the access control management system 202 receives a request as described above with reference to Fig. 3 (304).

[0078] A system selected from among remote access control management systems 202 checks if the user of the second client device 102b is authorized to receive information 208 associated with the encrypted data object 206 (412). In one embodiment, the access control management system 202 verifies the user as described above with reference to Fig. 3 (306).

[0079] A system selected from a series of remote access control systems 202 authenticates the user of the second client device 102b (414). In one embodiment, the access control management system 202 authenticates the user as described above with reference to Fig. 3 (308).

[0080] A system selected from a series of remote access control management systems 202 sends to the second client device 102b information associated with the encrypted data object 206 (416). In one embodiment, the access control management system 202 sends information 208 as described above with reference to Fig. 3 (310).

[0081] The second client device 102b decrypts the encrypted data object 206 by information 208 associated with the encrypted data object 206 (416). In one embodiment, the secure object information reader 212 executed on the second client device 102b decrypts the encrypted data object 206.

[0082] In some embodiments, the first client device 102a selects a second from a series of remote access control management systems 202 and transmits information 208 associated with the encrypted data object 206 to a second system selected from a series of remote access control management systems 202. In one of in such embodiments, the first client device 102a sends the encrypted data object 206 to the third client device 102c. In another of such embodiments, the third client device 102c requests from the second selected access control management system 202b information 208 associated with the encrypted data object 206. In yet another of these embodiments, the selected second access control management system 202 checks if the user of the third client device 102c is authorized to receive information 208 associated with the encrypted data object 206 and authenticates the user. In yet another of such embodiments, the selected second access control management system 202b sends to the third client device 102c information 208 associated with the encrypted data object 206. The third client device 102c decrypts the encrypted data object 206 with information 208 associated with the encrypted data object 206.

[0083] For some embodiments, the methods and arrangements described in the text provide an electronic file protection function. In one embodiment, the implementation of the methods and systems described in the text provides the function of combining an access control management system with an identity provider, increasing the ability of the access control management system to authenticate persons requesting access to cryptographic data. In the case of another embodiment, the implementation of the methods and systems described in the text provides a function that disconnects the access control management system and the data recording system, reducing the load of the access control management system related to data saving and increasing the flexibility provided by the system to users using the decentralized file saving system. In yet another embodiment, the implementation of the methods and layouts described in the text provides users with the function of sharing encrypted data objects with persons who have no established trust relationship with the access control management system or who have a trust relationship with an access control management system other than the relationship used by the data distributor user. In yet another embodiment, the implementation of the methods and layouts described in the text provides the function of creating secure data objects with access rights managed by the access control management system, while authentication services are provided by a third party identity provider. In some embodiments, the implementation of the methods and layouts described in the text allows clients to securely exchange data using means known to typical computer users (i.e. email addresses and account passwords) to provide control (with a high degree of certainty and flexibility) of access to exchanged data.

[0084] It should be understood that the systems described above may provide several pieces of each element, and these elements may be provided in the form of a stand alone device, or in the case of some embodiments in the form of several devices in a distributed system. The phrases "in one embodiment", "in another embodiment" and the like generally mean that a particular characteristic, structure, step or characteristic following the phrase occurs in at least one of the embodiments of the present invention and may occur in more than one embodiment of the present invention. However, such phrases do not necessarily refer to the same embodiment.

[0085] The above-described systems and methods may be implemented in the form of a method, device or production product utilizing programming and / or engineering techniques to produce software, firmware, hardware or a combination thereof. The techniques described above can be implemented in one or more computer programs executed on a programmed computer equipped with a processor, a data carrier read by the processor (including, for example, temporary and non-volatile memory and / or data recording elements), at least one input device and at least one output device. The program code can be applied to input data entered using an input device to perform the described functions and generate output data. Output data can be delivered to one or more output devices.

[0086] Any computer program falling within the scope of the claims set out below may be implemented in any programming language, such as assembler language, machine language, high level procedural programming language or object oriented programming language. The programming language can be, for example, LISP, PROLOG, PERL, C, C ++, C #, JAVA, or any compiled or interpreted programming language.

[0087] Any such computer program may be implemented in a product which is a computer program, materially placed on a data carrier, read by the device in order to implement the program by the processor. The steps of the method according to the invention can be carried out by a computer processor implementing a program materially located on a data medium read by the computer in order to perform the functions according to the invention, by operating on input data and generating output data. Suitable processors include, for example, microprocessors for general and special applications. In general, the processor receives commands and data from read-only memory and / or from random access memory. Data carriers suitable for the purposes of material placement of computer program commands on them include, for example, all forms of computer-readable devices, firmware, programmed logic components, hardware (e.g. integrated circuits, electronic devices, computer-readable fixed memory assemblies, non-volatile memory such as semiconductor memory, including EPROM, EEPROM and flash memory devices, magnetic disks such as internal hard drives and portable disks; magneto-optical discs and CD-ROMs. Any of these carriers can be supported or embedded in specially designed integrated circuits or a series of programmable FPGA field gates. The computer can also generally receive programs and data from a data carrier, such as an internal disk (not shown) or a portable disk. These elements are also found in a conventional desktop computer or workstation, as well as in other computers suitable for the implementation of computer programs implementing the methods described in the text, which can be used in conjunction with any digital printing engine or marking engine, graphic monitor or other output raster device capable of creating colored pixels or shades of gray on paper, foil, screen or other output medium. The computer may also receive programs and data from a second computer providing access to programs via a network transmission cable, wireless transmission media, signals propagated through space, radio waves, infrared signals, etc.

[0088] After describing specific embodiments of the methods and systems for distributing cryptographic data to authenticated recipients, it will now be apparent to a person having ordinary skill in the art that other embodiments realizing the concepts of description are also possible. The description should therefore not be regarded as limited to certain embodiments, but as limited only by the scope of the claims set out below.