[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2013123548A2 - Système et procédé de cryptographie - Google Patents

Système et procédé de cryptographie Download PDF

Info

Publication number
WO2013123548A2
WO2013123548A2 PCT/AU2013/000145 AU2013000145W WO2013123548A2 WO 2013123548 A2 WO2013123548 A2 WO 2013123548A2 AU 2013000145 W AU2013000145 W AU 2013000145W WO 2013123548 A2 WO2013123548 A2 WO 2013123548A2
Authority
WO
WIPO (PCT)
Prior art keywords
user
key
box
data
encrypted
Prior art date
Application number
PCT/AU2013/000145
Other languages
English (en)
Other versions
WO2013123548A3 (fr
Inventor
David Geoffrey Hook
Richard Hans Harvey
Peter Kai Dettman
Original Assignee
Lock Box Pty Ltd.
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
Priority claimed from AU2012900626A external-priority patent/AU2012900626A0/en
Application filed by Lock Box Pty Ltd. filed Critical Lock Box Pty Ltd.
Priority to EP13752183.7A priority Critical patent/EP2817917B1/fr
Priority to US13/969,071 priority patent/US8842841B2/en
Publication of WO2013123548A2 publication Critical patent/WO2013123548A2/fr
Priority to US14/455,300 priority patent/US20140351586A1/en
Priority to IL234215A priority patent/IL234215B/en
Publication of WO2013123548A3 publication Critical patent/WO2013123548A3/fr

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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • 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/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Definitions

  • the present invention relates to the field of security of electronic data and/or communications.
  • the invention relates to data security and/or privacy in a distributed and/or decentralised network environment.
  • the invention relates to enabling private collaboration and/or information sharing between users, agents and/or applications.
  • embodiment(s) of the present invention enable the sharing of key(s) and or content between a first user and/or agent and a second user and/or agent. Furthermore, embodiment(s) of the present invention have application in sharing encrypted information via information sharing services.
  • the inventors have identified a number of limitations with using third party "cloud” service or storage providers for sharing information, especially if user information is confidential, sensitive or private. These limitations include security, privacy and control. In particular, the reliance on a trusted third party(s) (TTP) and/or passwords.
  • TTP trusted third party
  • Cloud providers include Sofi are-as-a-Service (SaaS) providers, Platform- as-a-Service (PaaS) providers, Infrastructure-as-a-Service (laaS) providers and any other providers that offer information sharing services such as customer management services, storage services, messaging services, file sharing services, electronic data vaults, virtual data rooms, collaboration tools, screen sharing tools, content management systems, social websites, social networks, instant messaging, group-chat, forums, network management, content syndication, gaming, remote systems control and monitoring, geo-location, Voice over IP (VoIP), telephony, video conferencing, identity services and/or any other information sharing middleware or "cloud” based applications.
  • SaaS Sofi are-as-a-Service
  • PaaS Platform- as-a-Service
  • laaS Infrastructure-as-a-Service providers and any other providers that offer information sharing services such as customer management services, storage services, messaging services, file sharing services, electronic data vaults, virtual data rooms, collaboration tools, screen sharing tools, content management systems,
  • Controls - Server-side security relies on "controls" to prevent mishaps, breaches and/or abuse in the delivery of services.
  • controls are considered rarely adequate because of the complexities of too many people (staff, administrators, contractors, help desk personal etc.) having too many privileges (running, maintaining, administering, supporting etc.) across too many systems (including technologies, platforms, versions, topologies, business units, organisations etc.) with enforcement mostly by voluntary procedures (e.g. operations, development, testing, incident handling, patching, configuration, recovery, auditing).
  • Controls are considered to cost money and effort, often with little perceived business benefit, and so are rarely broad, strong or given priority. Even if they are in place, they cannot guarantee against mistakes, malicious behaviour or being deliberately bypassed (or disabled) if they get in the way of "business imperatives”.
  • administrators may always have the means to view user information and/or override any controls that users put on their information.
  • administrators may have the means to access user data and/or be able to manipulate security data such as alter information about users, impersonate users, set controls, change rights, alter groups, change memberships, view log files, access keys, reset passwords, utilised network inspection devices etc. They may even have means to avoid controls/detection and/or cover-up inappropriate activity.
  • service provider may sell, track, archive, backup, aggregate, resell, correlate, target and/or otherwise take advantage of end-user information.
  • service provider Terms of Service may claim a right to use or access user data for any purpose that the service provider deems necessary to run their service.
  • Figure 1 a illustrates a typical prior art system. Users authenticate themselves to a Provider using a password and sharing of Data relies on the Provider enforcing access controls appropriately on the Data. Such systems are not considered to have strong security or privacy as they use passwords (with consequential risks as described above) and/or rely on the Provider as a TTP (with consequential risks as described above) and/or use password reset for recovering credentials (with consequential risks as described above).
  • FIG. 1 b illustrates a typical prior art system commonly used for personal or backup reasons.
  • PBE Password Based Encryption
  • FIG. 1 c illustrates a typical prior art system that allows users to encrypt and decrypt information with the assistance of a Key Server.
  • Centralisation of keys is often used to overcome difficulties with key management including key generation, storage, duplication, distribution, access, protection, rollover, rotation, recovery, removal, and revocation.
  • this centralisation requires that a TTP maintains the Key Server (with consequential risks of having effective controls as described above).
  • Key Servers inherently have very concentrated control (possession of many keys) which may make them a target for attack.
  • the TTP controlling the Key Server may not necessarily be trusted in wider environments, for example, with diverse and/or large numbers of users and/or multiple collaborating organisations, especially over the wider internet.
  • many Key Servers only require password related authentication (with consequential risks as described above).
  • FIG. 1 d shows an example of prior art systems that make use of public key cryptography (PKC) to enable users to share data encryption keys.
  • PLC public key cryptography
  • Web of Trust (WoT) system may make use of endorsers to support trust in public keys.
  • Public Key Infrastructure may make use of one or more trusted organisations to have reliable and secure processes to support trust in certificates containing public keys.
  • such systems rely on a trusted third party(s) to facilitate the issuance and/or endorsement and/or distribution of public keys and/or certificates. This may give rise to a number of problems, for example:
  • PKI and WoT systems may have limitations in their trust models.
  • a Certification Authority (CA) issues certificates containing public keys and users have no choice but must trust the practices and procedures of the organisation running the CA, in particular the proof-of-identity that was used to issue a user their (public key) certificate.
  • users In the case of WoT, users must trust other users who endorse/notarise/counter-sign self-signed public keys.
  • PKI and WoT systems may have issues with security.
  • Security issues with PKI relate to its dependence on a centralised TTP (risks described above).
  • Security problems with WoT relate to the unreliable nature of "crowd sourced" trust as well as the difficulty of revoking public keys that have been compromised.
  • WoT model allows anyone to issue certificates, the discovery and distribution generally relies on centralized keyservers or certificate repositories or public directories to store certificates and respond to queries and which introduces the problem that these keyservers/repositories/directories need to be run by a TTP (with consequential risks as described above).
  • PKI and WoT systems may have issues with privacy.
  • Privacy issues in PKI relate to personal data divulged to the PKI Service during certificate issuance and/or as a result of certificates being publically available, such as in a directory and/or public website.
  • Privacy issues relating to WoT relate to the visibility of counter signed signatures, especially if made visible in a directory and/or public website, which can reveal entire social networks about the owner.
  • PKI and WoT systems may have issues with cost, complexity and/or adoption.
  • adoption may be limited because of regional and/or organisational restrictions that CA's have to verify identity.
  • adoption may be restricted because of limitations in the technology and/or the very technical and manual nature of communities having to build up their trust relationships.
  • prior art encryption approaches may have many limitations. For example, the management of trust, credentials, certificates, keys etc.
  • Password Based Encryption (PBE) approaches are considered to have numerous problems relating to managing passwords.
  • Keyserver approaches are considered to have numerous problems relating to the difficulty of securing and managing all the keys in a single or relatively small number of places.
  • Public/private key approaches are considered to have numerous problems relating to trusting a central server to reliably obtain a trusted public key(s) or certificate(s).
  • a method of, apparatus and/or application adapted to enable the provision of keys between a first user and a second user for enabling data security, comprising providing a first key adapted for enabling encryption of data, encrypting a first further key and enabling access to the encrypted first further key by the second user and providing to at least the second user, the first key encrypted with the first further key and in a manner independent of the data.
  • a trust layer adapted to enable communication via the data store of the encrypted data between the users and/or to enable the exchange of encrypted certificates
  • control layer adapted to manage symmetric keys and other system information protected by encryption
  • the first aspect is predicated on the realisation that, unlike prior art systems which tend to have relatively centralised administration where keys are distributed and controlled by a trusted third party or security and privacy is achieved by a secured communication system (including secured intermediaries), the inventors have found that security and privacy can be achieved in a more decentralised system including relatively untrusted environment(s) by empowering users to provide keys and control the access to data and keys themselves by the use of encryption applied to the data as well as the keys. Because data and keys are encrypted, the environment, through which users exchange data or keys, is not dependent on the security and privacy of intermediate systems and thus are workable in a decentralised manner. Keys and data may be independent of each other, Furthermore, security and privacy are enhanced by providing a layered architecture.
  • the present invention may reflect any one or any combination of layers of credential management, trust management, key management and content management.
  • embodiments of the present invention establish trust between users directly by virtue of mutual exchange of certificates.
  • embodiments of the present invention utilise user-to-user verification.
  • the trust is not bound to the public key, but to the user-to-user interaction.
  • the public key or the certificate may be kept private between the users.
  • a method of, apparatus and/ or application adapted to enable user access to another application or system or service comprising, in conjunction with at least one credential stored in an encrypted form and in a manner accessible by the user, facilitating a user access request, and providing a response which facilitates decryption of the stored credential corresponding to the response.
  • a method of, apparatus and/ or application adapted to enable at least two agents to access encrypted data in a distributed network environment comprising: using a first key to encrypt first data in the first data store; enabling a first agent to access the first data store via a first key; providing the first key to a second agent; replicating the first encrypted data in the second data store; and enabling the second agent to access the replicated first data in the second data store via the first key.
  • this further aspect is predicated on the realisation that agents in a distributed network may access encrypted data by replicating the encrypted data to end- system data stores.
  • information remains encrypted at-rest, particularly on end-systems, protected by appropriate keys and only decrypted as required .
  • a number of advantages are disclosed in Sections 2.2.5, 3.2.3, 4.6.1 , 4.8, 5.1.2 and 5.4 of the following description.
  • a method of, apparatus and/or application adapted to provide at least one certificate in a distributed network environment, wherein the distributed network comprises at least a first certificate store and a second certificate store, in which a first agent is enabled to access the first certificate store; the first agent distributing the certificate(s) to a second agent and enabling the second agent to store the certificate(s) in the second certificate store.
  • this second further aspect is predicated on the realisation that agents may automatically distribute, update and/or remove certificates in end-system certificate stores in order to enable certificate-based applications. This may occur independent of any centralised authority.
  • agents may automatically distribute, update and/or remove certificates in end-system certificate stores in order to enable certificate-based applications. This may occur independent of any centralised authority.
  • a method of, apparatus and/or application adapted to provide at least one symmetric key between at least two agents in a computer network, the first key being used to enable access to encrypted information in a data store, comprising enabling a first agent to obtain a first key; the first agent enables the second agent to obtain the first key; the second agent using the first key to access the encrypted information; and the first agent managing the lifecycle of the keys used to enabled access to the encrypted information.
  • this third further aspect is predicated on the realisation that each data owner may effectively be a key publisher and/or key authority. Since embodiments of the present invention provide a virtual peer-based system over arbitrary storage systems, keys may be distributed by data owners without the need for centralised key- servers and/or administrators. A number of advantages are disclosed in Sections 3.3.8, 4.4, 4.6.2 and 5.2 of the following description.
  • a computer network architecture and/or method comprising at least a first agent and a second agent interlinked by a separate data store to enable the exchange of encrypted first data between the first agent and the second agent, the first agent using the data store to pass encrypted control information to the second agent, the first and second agent thereafter exchanging the encrypted first data.
  • a method of, apparatus and/or application adapted to encrypt information for sharing between a first agent and a second agent, in a system using asymmetric cryptography and via a data store, comprising the first agent generating a first key; the first agent encrypting the first key with a public key of the second agent; the first agent providing the encrypted first key to the data store, the encrypted first key being retrievable by the second agent; the first agent encrypting the information with the assistance of the first key; and the encrypted information being provided to the data store.
  • a method of, apparatus and/or application adapted to facilitate communication between user(s) using a data storage service comprising providing end-to-end encryption in respect of system information.
  • agents may use protocols to decentralise management and may use end-to-end encryption to protect system data using substantially the same mechanisms normally used to manage and protect end-user data.
  • the techniques used for the end-to-end sharing of user content may be applied to the end-to-end transfer of management messages and/or security information such as keys, certificates and/or capabilities.
  • a number of advantages are disclosed in Sections 2.3, 2.5.2/ 3.1 , 3.2, 3.3, 3.4, 3 5.4, 3.5.5, 4.2, 4.3, 4.4, 4.6, 5.1 and 5.2 of the following description.
  • a method of and/or communication system apparatus adapted to use asymmetric cryptography enabling communication of encrypted data between at least two users via a data store, comprising a first layer adapted to establish the existence of certificate-based credentials for each user; and a second layer adapted to enable communication via the data store of the encrypted data between the users and to enable the exchange of encrypted certificates.
  • this seventh further aspect is predicated on the realisation that the establishment of certificate-based credentials may be managed by a credentials layer which may enable another layer related to the exchange of encrypted information and this information may include certificates.
  • Other layers may also be provided as herein disclosed.
  • a method of, apparatus and/or application adapted to manage encrypted information in a data store by an intended user comprising providing the intended user with a key, providing the intended user with cryptographic authorisation and the authorisation being necessary to communicate with the data store.
  • this eighth further aspect is predicated on the realisation that a data store may granted based on a cryptographic authorisation such as an attribute certificate, rather than checking that the requesting user is a user in an authorisation list.
  • a cryptographic authorisation such as an attribute certificate
  • a method of, apparatus and/or application adapted to provide introduction message(s) between two users for establishing secure communications between the two users; comprising a first user obtaining a first certificate for incorporation into the introduction message; encrypting at least a portion of the introduction message with an access code; storing the encrypted introduction message; communicating the access code to a second user; using the access code, and the second user decrypting the portion of the encrypted introduction message in order to enable communication with the first user.
  • this ninth further aspect is predicated on the realisation that in establishing bilateral relationships which may include the encrypted exchange of certificates and the initiation of this exchange may make use of an out-of-band means between a first user and a second user which may also include a verification process.
  • the certificates may be private certificates and/or unrelated certificates.
  • This verification process may enable a vetting process for example to establish proof of identity.
  • a method of, apparatus and/ or application adapted to enable the sharing of storage data between a first user and a second user comprising, in a data store, providing first storage data, stored in at least two separate parts, the at least two parts both being individually encrypted, one part including a key adapted for enabling the encryption of the second part, and the at least two parts being accessible by the first and the second users via the data store.
  • relatively autonomous co-operating peer-oriented agents may securely and/or privately exchange and/or transfer data (the requirement) using asymmetric and/or end-to-end cryptography (the enablers) to provide collaboration and/or privacy-enabling capabilities (the functions) with strong security, privacy, control and/or decentralised management (the benefits) over minimal-trust and/or relatively “blind” and/or third-party storage and/or transport and/or certificate services (the environment).
  • agents may use encryption, keys and protocols to enforce, control and/or manage security and/or privacy (e.g. identity, access, authorisation, membership, confidentiality, integrity, representation, credentials etc.) supported by optional facilitating system services (e.g. certificate signing, revocation, credential backup, enrolment, storage, notifications etc).
  • encryption, keys and protocols to enforce, control and/or manage security and/or privacy (e.g. identity, access, authorisation, membership, confidentiality, integrity, representation, credentials etc.) supported by optional facilitating system services (e.g. certificate signing, revocation, credential backup, enrolment, storage, notifications etc).
  • agents enable end users and/or applications to leverage strong client-side cryptography for strong security, privacy and control of data, in a way that is easy to use for those users and/or applications.
  • This may encompass transparent handling and recovery of certificate- based credentials, decentralised management and advanced cryptographic capabilities e.g. rotating keys, digital signatures, client-side key management, revocation etc.
  • Administration - requirements may be minimal as management and/or control may be decentralised and performed by agents and/or the end user (instead of via centralised administrators as is the case in prior art).
  • Anonymity - may be preserved as end users and/or agents may only be known via a "label" not necessarily associated with anyone or anything.
  • the system may provide further levels of anonymity, for example, with the use of self-generated certificates and/or attribute certificates supplied by a box owner to perform specific actions.
  • Applications - may leverage the certificate management and/or key-management aspects of the present invention to add an extra layer of privacy, security, control, management etc (without relying on centralised infrastructure as is the case in prior art).
  • Availability - may be significant by making use of third party "cloud” storage and/or sharing services as well as geographic replication (unlike prior art peer-to- peer services which may require end-systems to be online for certain management functions).
  • Authenticity - may be possible using digital signatures which allows for proof of originator of information being shared and/or exchanged. This may be very important to ensure that information being exchanged hasn't been forged, substituted or falsely planted .
  • Balance of power - may reside with the end-users (as opposed to centralised administrators). This is because information is protected using encryption and the end user and/or agent uses keys to control nearly all aspects of management with the relative inability of central administrators of intermediate systems to override or compromise user data, influence user interactions or take advantage of user content.
  • Boundaries - may be very tightly defined. For example security boundaries may be limited to the set of users that have keys (and not implicitly defined by any network, server or other system administrators as is the case in prior art). Trust boundaries may be limited to the set of contacts that a given user has personally verified (as opposed to the domain defined by a third party in prior art). Information sharing boundaries may be compartmentalised to the particular information stored in a given box or workspace (unlike prior art which simply sets third-party changeable boundaries via rules, such as access control lists).
  • Compartments - may be enforced through the use of encryption and keys so that any compromise is strictly limited to that particular box or, in the case of a user compromise, the community(s) that that user belongs (unlike prior art in which a compromise may allow access to significant amounts of data and/or user information).
  • Control - may be significant as a data owner has exclusive power to authorise access to encrypted information through the delivery of keys to authorised parties. This control effectively cannot be overridden or intercepted by administrators, intermediate service provider(s), hackers or any other party.
  • Credential recovery - may be achieved without necessarily being dependent on a centralised third party. This is because after revocation, a user needs to convince the same people who originally invited them to share information, to do so again. This also reduces the risks of social engineering attacks as even if a user is revoked and an attacker takes their place, the attacker still needs to convince other people in each sharing domain they are the person that has been revoked.
  • Decentralisation - may be significant .as nearly all control, processing, trust and management is effectively pushed "outwards" to the client application. This enables decentralised management including decentralised access, authorisation, certificate, content, credential, entitlements, identity, key, provisioning, privacy, privilege, recovery, rights, role, security, storage and trust management. This may have further benefits such as reducing central administration costs, reducing central help desk demands etc.
  • Centralised services may only need to provide optional facility services. Their functions may be limited to certificate signing, revocation checking and/or storage of encrypted information. Efficiency - may be achieved in several ways as a result of having client-side processing. Examples include compressing end-user data, performing most processing and cryptographic functions client-side, automating the distribution of certificates and handling of revocation, minimising the use of public key operations through the use of wrapping keys etc.
  • Enforcement - may be strong and end-to-end without relying on centralised infrastructure. This is because data is "armoured” client-side with strong encryption so that data is considered protected anywhere, anytime whether “in transit” or “at rest” across any intermediate system.
  • Heterogeneous - operation may be possible as different types of technologies, providers and components may be integrated seamlessly together.
  • embodiments of the present invention may include certificates from different certificate authorities, storage from different storage providers, authentication using different types of credentials (e.g. from identity systems, smart card systems, PKI ' s, WoTs), different types of data stores (e.g. cloud servers) and/or different applications (e.g. file sharing systems, document systems, messaging systems, collaboration systems, instant messaging systems, conferencing systems, queuing systems etc).
  • Integrity - may be assured through the use of digital signatures. For example to ensure that shared information has not been modified or tampered with.
  • Loose Coupling - from infrastructure or third parties may be achieved as the system may be considered relatively "host-proof, "location-proof and/or “provider-proof. For example, it may be relatively easy to replace intermediate storage and/or transport and/or remote service providers.
  • Management - may be decentralised and strictly contained to the participants in any sharing group or community. This avoids the use of "super users" or any other overriding administrative or management or centralised roles. Membership - need not be centrally administered as end-users may dynamically build groups in context of the sharing required via the distribution of keys. This capability-based approach may remove many types of complexities with centrally managed groups e.g. unpredictable, transient, complex, overlapping, disjoint, dormant, out-dated etc.
  • Multi-tenancy - may be safely achieved because each key or permit is completely independent of other keys or permits. Therefore content being shared by any set of users by virtue of possession of a key or permit, is effectively isolated and independent from all other content and other sets of users regardless of how and where it is stored intermediate to end-systems.
  • Offline protection - may be achieved via end-systems locally storing encrypted information. Recovery of encrypted data while offline is also possible because even if credentials are lost, data may still be recovered by obtaining relevant box keys or sharing keys from other box members or at-rest keys if they were backed up to a box.
  • Overlay - concepts may be applied to existing applications and/or infrastructure with an extra "layer" of strong security, privacy and/or control. For example, encrypting messages before sending them via an email or instant message system, encrypting a stream before sending them via a voice or screen sharing session etc.
  • Passphrase recovery - may be achieved without involving a centralised provider. This may be implemented via a passphrase recovery code entrusted to a custodian, such as via a box, which avoids giving the power of credential reset to any intermediate provider.
  • the passphrase recovery code may be provided by email and/or mobile text (Short Message Service, SMS) and is relatively safe because, on its own, it is considered not useable without the corresponding encrypted passphrase blob which is stored in any manner accessible by the end user. This may significantly reduce help desk costs, as password resets may constitute much of the cost of support.
  • Peer-based operation - may be attained because agents may be relatively autonomous while still being able to utilise intermediate store-and-forward and/or storage mechanisms. Embodiments of the present invention may require minimal need for Trusted Third Parties (TTPs) which may give significant security and privacy advantages
  • Provisioning - may be controlled with the use of sub-boxes. This may give the benefits of managed-users being setup and contained inside a contained and/or private world which is controlled by the business, including allocating of credentials, privileges etc.
  • Policies - may be defined and enforced client-side (rather than server-side). This means that intermediate system administrators are relatively powerless to change or override them.
  • Protection - may be substantial as end users may protect their own information using end-to-encryption. This means that information stored or in transit in the "cloud” exist only as encrypted “blobs” making it meaningless to intermediate administrators, service providers, hackers or other transitory party.
  • Privacy - may be enforced instead of being reliant on promises by intermediate providers. This is because the use of end-to-end encryption and other techniques effectively makes intermediate providers "blind" to what information is being shared, who is sharing with whom , and any other behavioural or social network patterns between participants.
  • Privileges - may be bestowed without the need for explicit enforcement by intermediate parties.
  • attribute certificates may be used to convey rights such as read-only, upload/download, update or any other privileges without a central party needing to maintain or affect those privileges.
  • Recovery - of keys may be decentralised, self-enforcing, and more secure than centralised approaches of prior art. This is because regaining credentials is not sufficient to regain previous access. Regaining access further requires obtaining keys to each box that a user previously had access to. Regaining box keys is then dependent on re-establishing trust with the owner of the box, or at least one box member in the case of a box-owner trying to regain access back to their own box. This layered, iterative and decentralised approach may be considered preferable to prior art centralised key server approaches which may rely on all- powerful administrators.
  • Resilience - of the system may be noteworthy as the system may be relatively resistant to rogue clients and/or rogue service providers.
  • Abuse of client-side features requires access to a user's machine.
  • Abuse of server-side services may only obtain unauthorised access to encrypted data or deny service. In neither of these cases it is considered that the actual plain-text data would be compromised.
  • Responsiveness - may be obtained via asynchronous notifications. This means that interactions such as make contact, invitations, changes in content etc. may appear in near real-time and/or relatively instantaneously.
  • Revocation - may be used to enhance assurance of credentials. Further, revocation may be managed by end users. Many prior art systems may not provide for revocation, or may only provide revocation in a cumbersome way, for example WoT systems. Providing " revocation, particularly timely revocation, is considered essential to handle the case that credentials are lost or compromised. Also, the ability for end-users to get trusted custodians to invoke revocation is far preferable to prior art systems that rely on central administrators who may be susceptible to social engineering attacks and other risks.
  • Rights management - may be enforced client-side by leaving information encrypted locally and having a special application, such as a reader, that only decrypts information, optionally in parts, as required. In this case, policy based rights management may be enforced.
  • Risk - may be significantly reduced as security need not necessarily depend on every link, machine, network, administrator and other infrastructure intermediate to end-systems. In essence, this is because the data is "locked-down" (data- centric security) rather than relying on every piece of infrastructure intermediate to end-systems to be “locked-down” (infrastructure-centric security).
  • Scalability - may be significant as most processing is performed client-side and so significant central hardware is not required to support relatively large numbers of users.
  • encryption is relatively efficient through the use of symmetric keys and the limiting of public key operations through the use of wrapping keys
  • making use of third party storage for user information and/or messages, which the agent interacts with directly means that only a relatively small amount of system information may need to be kept centrally, e.g. credential backup, registration information, etc. This may greatly reduce the amount of information managed by the system services that needs to be stored , failed over, backed up, archived etc.
  • Secrecy - may be inherent in the system as information being exchanged is hidden by encryption and/or interactions between parties may be relatively difficult to deduce. Secrecy may be enhanced by using anonymised certificates and/or avoiding using an external notification service such as email.
  • Security - of the system may be relatively strong through the use of strong cryptography and best-practice operations, such as end-to-end encryption, strong cryptographic keys, certificate-based authentication, mutual (client authenticated) Secure Sockets Layer (SSL) / Transport Layer Security (TLS), duty specific credentials (i.e. separate certificates for signing, encryption, communications and certificate management) , multi-factor vetting of contacts etc.
  • strong cryptography and best-practice operations such as end-to-end encryption, strong cryptographic keys, certificate-based authentication, mutual (client authenticated) Secure Sockets Layer (SSL) / Transport Layer Security (TLS), duty specific credentials (i.e. separate certificates for signing, encryption, communications and certificate management) , multi-factor vetting of contacts etc.
  • Self-Management - may be authoritative as nearly all management is performed client-side and is peer-based. This may be in contrast to most prior art where any management actions or control settings by end-users may be overridden by centralised administrators.
  • Trust - may be more tightly controlled yet more encompassing than may be the case in prior art systems. Trust may be tightly defined via bi-lateral exchanges between users on an "as needs" basis. Trust may be relatively independent of technology as certificates being exchanged may not be necessarily related, associated or compatible. This means that embodiments of the present invention can work with multiple PKI's and or WoT systems simultaneously without the need for CA cross certification, border CAs or trust translation mechanisms by third parties.
  • Virtualisation - may be achieved in several ways. Because each agent may act as a server e.g. a certificate server, a key server etc each agent may be considered a "virtual appliance" which has the benefits of server functionality without necessarily a group of administrators looking after it. Also, because agents can overlay any remote service e.g. storage service, with a layer of security and privacy, then the result may be considered a "virtual private cloud” which has the benefits of trusted users having their own “private cloud” without the expense or difficulty in building such a "private cloud” as known in the prior art.
  • a server e.g. a certificate server, a key server etc each agent may be considered a "virtual appliance" which has the benefits of server functionality without necessarily a group of administrators looking after it.
  • agents can overlay any remote service e.g. storage service, with a layer of security and privacy, then the result may be considered a "virtual private cloud” which has the benefits of trusted users having their own “private cloud” without the expense or difficulty in building
  • data store comprises one or more medium for storage data.
  • examples comprise, without limitation, disk(s), disk array(s), device(s), peripheral(s), bus(s), service bus(s), repository(s), database(s), memory, memory stick(s), service(s), cloud service(s), storage service(s), sharing service(s), collaboration service(s), network service(s), intermediary service(s), broker service(s) etc.
  • certificate comprises any electronic document which uses a digital signature to bind a public key with an identity.
  • examples comprise, without limitation, digital certificate(s), identity certificate(s), issued certificate(s) for example from a certification authority, self-signed certificate(s), public certificate(s), private certificate(s), trust certificate(s), Certification Authority (CA) certificate(s), X.509 certificate(s), PGP signed keys etc.
  • the word "key”, without limitation, comprises any representation used in association with or operable on an encryption algorithm that enables encryption or decryption of information. Examples comprise, without limitation, cryptographic keys, asymmetric key(s), symmetric key(s), wrapping key(s), master key(s), secret key(s), public key(s), private key(s), authorisation key(s), password key(s), passphrase key(s), one-time password key(s), ticket(s), token(s), etc.
  • the word 'agent' comprises a user, an application, an executable, a function executed by software, a program, a system, a sub-system, a library, a seivice, a plug-in, an extension, a proxy on behalf of another agent, a separate device such as a plug-in device, an expansion card, a network connected device or any other integrated hardware with access to processing means, or any other hardware and/or software entity.
  • Examples comprise, without limitation, analytical agent(s), autonomous agent(s), collaboration agent(s), communications agent(s), control agent(s) , cooperative agent(s), cryptographic agent(s), data-mining agent(s), delegation agent(s), distributed agent(s), intelligent agent(s), interface agent(s), learning agent(s), management agent(s), monitoring agent(s), negotiation agent(s), networking agent(s), peer agent(s), personal agent(s), predicative agent(s), processing agent(s), proxy agent(s), reactive agent(s), self-organising agent(s), simulation agent(s), smart agent(s), social agent(s), etc.
  • the word 'user' may comprise an 'agent' and/or an application associated with content.
  • FIGS. 1 a through 1 d illustrate various prior art arrangements
  • FIG. 2 illustrates an overview of an embodiment of the present invention
  • Figure 3 illustrates a system diagram of an embodiment of the present invention
  • Figure 4a illustrates an overview of the operation represented as layers of a first user according to an embodiment of the present invention
  • Figure 4b illustrates an overview of the operation represented as layers of a second user according to an embodiment of the present invention
  • Embodiments of the present invention may be utilised by apparatus, system(s), user(s) and/or application(s) to privately and/or securely use and/or share and/or transfer information.
  • Such information may be arbitrarily stored for example using remote services and fully controlled client-side, for example within trusted and/or private communities.
  • FIG. 2 illustrates an overall introduction to embodiments of the present invention. More detailed definitions, relationships, operations, use cases and advantages are provided in subsequent sections. In practice, any one or any combination of the details described and/or illustrated may be implemented.
  • security and privacy may be achieved in a more decentralised system including relatively untrusted environment(s) by empowering users to manage credentials, certificates and/or keys on the client-side and control the access to data and keys themselves by the use of encryption applied to the data as well as the keys.
  • data and keys are encrypted , preferably separately, the environment, through which users exchange data or keys, is not necessarily dependent on the security and privacy of intermediate systems and thus are workable in a decentralised manner.
  • Data is not necessarily encrypted with the same keys. Keys may reused to encrypt different data. Different keys may be used to encrypt different sets of data thereby isolating and separating those different sets of encrypted data.
  • keys and encrypted data may be transferred and/or exchanged between users not necessarily in any order.
  • security and privacy are enhanced by providing a layered architecture.
  • Security and privacy are even further enhanced by providing layers which are not necessarily dependent on each other.
  • the present invention may reflect any one or any combination of layers of credential management, trust management, key management and content management.
  • User-to-user encryption is enhanced by an integrated approach such as the layered architecture disclosed herein.
  • Figure 2 Even though Figure 2 only shows two users, the embodiment is equally applicable to any number of users resulting in the possession of a key by each user who wishes to communicate (encryption) together. For example, if a first user and a second user possessed keyl , they could communicate together. If a third user and a fourth user possessed key2, they could communicate together. The first user and third user would need to both possess either keyl or key2 or a fresh key3 in order to communicate with each other.
  • a first user who wishes to establish a trusted relationship with a second user (e.g. User 201 ), provides an initial key (e.g. key A or certificate U 1 ) to the second user.
  • the initial key may be provided in many different forms and/or many different ways.
  • the first user may send the second user an encrypted key (e.g. Encrypted Contact 250), which may exist as an encrypted blob transiting intermediate and/or cloud systems, and also the first user makes contact with the second user out-of- band with the associated bootstrap key (e.g. key A).
  • the first and second users may decide to use an existing key which can be used as a bootstrap key and already in the position of both users (e.g key B not shown but known to both users).
  • the bootstrap key may be a password , or code or public key or public certificate or personal certificate or any other suitable key.
  • the second user may decrypt using the bootstrap key to decrypt the received encrypted blob in order to obtain the initial key (e.g. U 1 ).
  • the first user provides to the second user two communications each via a separate channel. This may provide an increased level of trust and security.
  • the first user may provide the initial key (e.g. U 1 ) directly, for example using any suitable means.
  • the result of the provision of the initial key is that the second user has a key which can be used in the following communication from the second user to the first user.
  • the second user provides a second encrypted key (e.g. Encrypted Accept 251 ), which may exist as an encrypted blob transiting intermediate systems (independent of application, network topology or operating system) using the second user's own key (e.g. Key U2) encrypted with the initial key (e.g. Key U 1 ).
  • the second user thus provides the second encrypted key to the first user.
  • the first user is able to decrypt the second encrypted key by using the initial key or an associated key such as a private key associated with the initial key.
  • the first and the second users have both undertaken mutual decryption and/or verification, for example using a digital signature, from the other user which may be used to confirm the handshake process. Also, both users are in possession of keys (e.g. U 1 and U2) which enables a cryptographically secure channel between them.
  • the first user may provide a third key (e.g. K1 ) to the second user in the form of a third encrypted key (e.g. Encrypted Transfer 252).
  • the third encrypted key is generated using the second key (e.g. U2) to encrypt the third key.
  • the second user is able to decrypt the third encrypted key by using their own key (e.g. U2) or associated key, such as a private key (e.g. u 1 ) associated with their own key.
  • any number of additional layer(s) of key(s) may be used subsequent to the third key as necessary.
  • Embodiments of the present invention are also applicable to one or more further users in which case the steps described above may be undertaken between each further user and the first user (or a user who has or generates the initial key) who generated and/or controls the third key.
  • the further user may initiate communication with the second user (or vice versa) or any other user who has possession of the third key.
  • the handshake process as described above and the encrypted transfer takes place on a user-to-user basis.
  • the sharing of encrypted content may take place between one or more users.
  • two or more users already have in their possession a key which is common to those users, they may share encrypted content (e.g. Encrypted Content 253) even though may not have necessarily have undertaken the handshake process.
  • a first user e.g. User 200
  • a key e.g.
  • the other two or more users may communicate with each other (e.g. Encrypted Content 253) by virtue of having an associated key (e.g. K1 ) even though the other two or more users have participated in a handshake with the first user (e.g. User 200) but may not have participated in an handshake process directly between each other (e.g. User 201 and User 202 not shown).
  • Encrypted Content 253 e.g. Encrypted Content 253
  • the sharing of content may be facilitated and/or enabled by an intermediate service, such as remote services (further defined below) There may be any number of intermediate and/or remote services in any location (further defined below). Sharing may involve any form of sharing, collaborating, transferring, exchanging, communicating , conveying, interacting etc.
  • encrypted content may remain protected whilst being transferred (“in motion") and while it is being stored (“at rest”) regardless of the level of security provided by remote service(s) for the entire time that it is intermediate to agents.
  • This protection is often known as "end-to-end encryption” or “user-to-user encryption”.
  • embodiments of the present invention provide protection and security and privacy of content.
  • An advantage of having encrypted content is that it provides a level of protection against data leaks, administrator abuse, provider resale, government surveillance etc.
  • FIG. 2 also schematically illustrates a key management architecture through the use of layers.
  • a first layer may enable the management of credentials (e.g. Credentials 210, Credentials 21 1 ), for example certificate based credentials.
  • a second layer may enable the management of certificates (e.g.
  • Certificates 220, Certificates 221 also referred to as the trust layer, for example to enable the exchange of certificates.
  • a third layer may enable the management of symmetric keys amongst a trusted community of users (e.g. Encrypted Transfer 252) and may allow every user to control with whom they share encrypted content.
  • a fourth layer may enable the sharing of content (e.g. Content 240, Content 241 ), for example amongst a group of users who have in their possession or who have access to the same key or an associated key(s).
  • Encrypted Content 253 e.g. Encrypted Content 253
  • relevant keys e.g. K1 , U2, U 1 , A
  • encrypted keys may be shared in advance of encrypted content, at the same time, or in arrears.
  • any encrypted content may be encrypted with a transitory wrapping key (WK) and the wrapping key encrypted with the relevant key.
  • WK transitory wrapping key
  • relevant key is known as the key encryption key (KEK) and the encrypted wrapping key (EWK) may form part of the encrypted content.
  • An important realisation in aspects of the present invention is that the sharing of keys may be enabled in a similar way to the sharing of content. That is, by treating a key, and more generally any system information, as just another type of content, the same end-to-end encryption, protection may be achieved.
  • any system content may be exchanged, for example co-ordination of management may be achieved by using sharing and managing messages.
  • This may then enable the decentralised management of general system, security and privacy management such as the management of access, authorisation, certificates, content, credentials, entitlements, identity, key, privacy, privileges, provisioning, recovery, rights, roles, security, storage, trust etc. (further defined below),
  • Embodiments of the present invention may achieve peer-to-peer (P2P) like advantages, such as privacy and security, but without P2P limitations such as requiring peers to be directly connected or necessarily being simultaneously online.
  • P2P peer-to-peer
  • Another advantage is that the content exchanged in embodiments of the present invention may be safely kept in encrypted form as a historical record.
  • a user may control the set of people they trust, for example via the exchange of certificates, and may also control the set of people who have access to information, via the distribution of keys. This allows users to determine their "trusted community" to only those they trust, and not necessarily imposed by any third party (further described below).
  • the ability to manage certificates may enable a relatively large number of certificate enabled applications.
  • the managing of certificates is enabled because each agent effectively becomes a certificate server.
  • Example applications which may make use of certificates includes secure email, secure communications, client-side authentication, document control, document signing etc (further described below).
  • certificates and/or signed public keys need not necessarily be related, for example they may be from different issuers and/or be in different forms, which may have significant advantages for supporting heterogeneous environments.
  • the ability to manage keys may enable a relatively large number of encryption applications. Key management is enabled because each agent effectively becomes a key server. Examples of encryption applications include secure communications, collaboration applications, real-time systems, streaming data systems, data protection systems, etc. (further described below).
  • the ability to intercept applications client-side can be used to protect a relatively large number of "cloud" services and other remote applications.
  • Data protection is enabled as each agent effectively can protect data end-to-end. Examples of data protection applications include cloud storage, collaboration, private portal, secure file sharing, secure publishing, archive and backup, private messaging, privacy applications and any field within any application etc (further described below).
  • the ability to replicate encrypted data to end-systems may be used to enable a relatively large number of "at rest” encryption applications, for example local file encryption, content distribution, rights management, storage overlay, mobile data protection, remote data destroy/purge, redaction etc (further described below).
  • Userl 301 may correspond to User 441
  • User2 302 may correspond to User2 451
  • Remote Services 370 may correspond to Storage Tier 400 •
  • the key used to Wrap 435 may be a copy of the key used to Wrap 425
  • Community Key 455 may be a copy of Community Key 445
  • Contact Code 471 may be a copy of Contact Code 461
  • Shared Box 402 may be an instance of User Boxes 381
  • Contact Boxes 408 and 410 may be instances of Message Boxes 383
  • Home Boxes 41 1 and 412 may be instances of Agent Boxes 382
  • Encrypted File 401 Meta-data 403, Invite Task 405, Make Contact Task 407, Accept Contact Task 409 may be instances of Storage Data 372.
  • One or more users may make use of a system involving embodiments of the present invention.
  • a single user may use the system for backup and/or multiple users may use the system for collaboration and/or sharing information.
  • a user e.g. Userl 301
  • Users may form a relationship with other users using an out-of-band vetting process (e.g. Vetting 303).
  • This vetting process may be used to authenticate or give assurance and/or trust that another party is who they say they are and/or are willing to participate in a given relationship.
  • Examples of relationships that may require verification includes making contact, invitations and managing boxes. The verification may make use of an authentication code or "authcode".
  • An authcode may be kept secret from everyone except the two users establishing a relationship (e.g. a contact code) and/or transferring privileges (e.g. a box change-owner code), 2.1 .2 Pre-trusted relationships
  • a trusted path may be automatically used to facilitate the forming of a relationship.
  • two machines may have a trusted relationship via a closed or Virtual Private Network (VPN).
  • VPN Virtual Private Network
  • the vetting process may use an existing proof-of-identity in place of the authcode.
  • Each user may use an end system (e.g. End System 310) in order to remotely store information and/or communicate and/or share information with other users and their respective end systems.
  • an end system e.g. End System 310
  • An end system (e.g. End System 310, End System 350) may be any type of computing device e.g. desktop, laptop, tablet computer, mobile device or any other apparatus with computing means.
  • the end systems may make use of local storage (e.g. Content Store 320, Agent Store 330).
  • Local storage may include a local disk, portable disk, memory drive, Universal Serial Bus (USB) drive, USB memory stick, network drive etc.
  • USB Universal Serial Bus
  • Content Store 320 and Agent Store 330 are shown logically separated but in implementation may use the same local storage mechanism.
  • Content may comprise any information communicable in a digital form.
  • Content may be in the form of User Content and/or System Content.
  • Examples of User Content may comprise, without limitation, any one or combination of data, information, file(s), code(s), record(s), stream(s), protocol(s), conversation(s), session(s), backup(s), journal(s), audit trail(s), log(s), document(s), presentation(s), spreadsheet(s), user message(s), email(s), post(s), comment(s), multimedia, picture(s), video, music, audio, radio, indicia, ticket(s), entry(s), field(s), index(s), application(s), executable(s), library(s), package(s) or any other electronic information etc.
  • System Content may comprise, without limitation, any one or any combination of system data, application data, meta-data, agent data, task(s), key(s), certificate(s), interaction(s), communication(s), acknowledgement(s), signalling, control information, system message(s), revocation message(s), privilege(s), authorisation(s) etc,
  • Content may also comprise, without limitation, any one and/or any combination of derivation(s) of User Content and/or System Content such as encrypted, obfuscated, compressed, translated, scanned, signed, watermarked, packaged, compiled, aggregated, segmented, transformed, encoded, etc.
  • End systems may contain local content (e.g. Content 31 1 ) which may be useful to and/or shared between users and/or applications.
  • Content may be stored locally (e.g. Content Store 320, Agent Store 330), stored remotely (e.g. Remote Services 370), transferred (e.g. Virtual Protocols 360, Storage Data 372) , processed (e.g. Processing 342) etc,
  • Applications may make use of local content (e.g. Content 31 1 ).
  • Applications may have collaboration, content creation, file management, systems management and/or communications capabilities. Examples may include, without limitation operating system functions, email, instant messaging, forum(s), calendaring, communal editing, social networking, chat, real-time interactions, monitoring, management, control, transaction system(s), document management, virtual file systems, virtual worlds and/or any other client-server applications, web applications, distributed applications, messaging applications, peer-to-peer applications, collaboration applications etc.
  • Applications may include certificate enabled applications which make use of a certificate store (e.g. Certificate Store 314).
  • Applications may also include synchronisation applications which facilitate sharing, for example to synchronise data areas (e.g. Content Store 320, Agent Store 330) with a remote storage "cloud”.
  • Applications may be related to remote services (e.g. Remote Services 370).
  • a portion of an application may be in the end system (e.g. Applications 312), for example a client installation or within a browser, whilst another portion of the application may be in remote services, for example, a server application.
  • Applications may work in conjunction with an agent (e.g. Agent 340), for example, explicitly invoke agent functions, such as to encrypt/decrypt, store/retrieve, upload/download etc.
  • agent e.g. Agent 340
  • agent functions such as to encrypt/decrypt, store/retrieve, upload/download etc.
  • an agent may intercept interactions of applications, for example, to encrypt/decrypt some or parts of the application interacting with another application and/or remote service.
  • a Virtual File System (e.g. VFS 313) may be managed by an agent (e.g. Agent 340).
  • the VFS may make content available to users (e.g. Userl 301 ) and/or applications (e.g . Applications 312) whilst ensuring it remains encrypted (e.g. Content Data 321 ) at-rest, for example, while on-disk (e.g. Content Store 320).
  • Synchronisation applications may also synchronise this encrypted information (e.g. Content Data 321 and/or Agent Data 331 ).
  • VFS virtual file
  • applications may simply read and write information from the virtual disk or virtual folder, with the VFS transparently handling "on-the-fly" encryption .
  • VFS transparently handling "on-the-fly" encryption .
  • users may perceive such an embodiment of the present invention as a "self-encrypting disk”. Users may further value the fact that information always remains in an encrypted form, where ever it resides, and may label this "privacy at rest”.
  • An end system may contain one or more certificate stores (e.g. Certificate Store 314). These stores may be associated with an operating system or may be associated with applications (e.g. Applications 312) such as a browser, email system, instant messaging system etc.
  • An Agent e.g . Agent 340
  • certificates e.g. Contact Certificates 462 into the certificate store for use by other applications.
  • a benefit of an agent managing such certificate stores is that it may automate the obtaining and/or distribution and/or management of certificates.
  • prior art systems may require the manual management of certificates, such as email certificates, authentication certificates, encryption certificates, signing certificates, trust certificates etc.
  • Content storage (e.g. Content Store 320) may store one or more parts of storage data.
  • Content storage may be one or more data stores, for example, one or more disks or other storage device(s). Any one or any combination of storage devices may be attached to the end system, for example a USB device or portable device may be advantages for the purpose of protecting data on that device.
  • Content data may be encrypted forms of content (e.g. Content 31 1 )
  • the encrypted content is encrypted user content.
  • content Prior to encryption , content may be compressed and/or signed. Encrypted content may be created and/or used and/or managed by an agent (e.g. Agent 340) and/or by a Virtual File System (e.g. VFS 313).
  • agent e.g. Agent 340
  • VFS Virtual File System
  • Encrypted content may be kept in a form suitable for "on-the-f!y” encryption and decryption. This may also be known as “at-rest” or “on-disk” encryption. At-rest encryption may use one or more files, for example, one or more encrypted data files. Encrypted content may have associated control-data such as a signature, filename, file size, encryption algorithm, compression type, keys etc. The control-data and/or signature may be kept encrypted and/or may be kept separate files and/or kept as fields in a database (e.g. Agent Store 330).
  • a database e.g. Agent Store 330
  • At-rest encryption may allow an agent and/or a VFS to present a logical view of files and allow any associated file operations e.g. create, view, modify, delete, change permissions etc while maintaining the actual file in an encrypted form while at-rest, for example, on-disk.
  • File encryption may use a mode which makes it suitable for "on-the-fly" encryption and decryption , for example Counter (CTR) Mode.
  • Random access may be implementing using an appropriate cipher that allows implementing a seek to a location in a file to be accomplished via a seek to an associated location in the encrypted file.
  • CTR Counter
  • Signing may use a digital signature or hash-based message authentication code (HMAC). Signatures may be used for data integrity and/or authenticity. Detecting integrity problems may be important to automatically recover from corruption.
  • HMAC hash-based message authentication code
  • Encrypted content may be versioned. That is, for any given file, there may be previous versions, preferably in encrypted form, that are maintained. This may allow users to recover files e.g. that have been accidentally overwritten or contain changes that need to be undone or to resolve two or more people trying to share a file of the same name and or concurrently trying to change the same file.
  • Using shared keys may allow recovery from lost credentials, including the case where data hasn't yet been uploaded. This is because the relevant volume or box or shared or workspaces keys may be obtained from other users, for example through an invitation process.
  • Agent storage may be used to store agent data (e.g. Storage Data 331 ),
  • agent data e.g. Storage Data 331
  • the agent store may be a separate store and/or part of a local store (e.g. Content Store 320) and/or may be a separate device, e.g. a USB device or portable device and/or may be in a memory. If agent data is on a separate device, the user (e.g. Userl 301 ) may remove the agent related information when not using the end system. This may enhance the security of that end system.
  • the agent store may be in memory, for example, when a credential backup service (e.g. Backup Services 393) is being used. This may be used if the persistent security of the end-system cannot be relied on and/or when an 'external authentication system, e.g. Virtual Private Network (VPN) is being used .
  • VPN Virtual Private Network
  • End systems may make use of a keystore (e.g. Keystore 331 ) for storing credentials, such as certificate-based credentials
  • Credentials may be duty specific, for example, separate credentials for encryption, communications, content signing and/or system signing (also known as a registrar credential).
  • Each credential may include a public key within a certificate and an associated private key.
  • the public and private key pair may be generated by the agent.
  • the keystore may be a software keystore or a hardware keystore such as a smart card or High Security Module (HSM).
  • HSM High Security Module
  • the keystore may be protected and/or encrypted, such as using a passphrase, pin, biometrics or any other appropriate means.
  • An agent may make use of a passphrase recovery capability.
  • the agent may generate an encrypted passphrase blob (EPB) using a passphrase recovery code (PRC).
  • EPB may be stored locally (e.g. part of Storage Data 331 ) or in any manner accessible by the agent and/or user.
  • the PRC may be entrusted to a third party, such as stored in a passphrase-recovery box and/or provided to trusted user and/or trusted third party and/or a system passphrase assistance service (e.g. Backup Services 393).
  • Recovery of a forgotten keystore passphrase may be manual or automatic. In the manual case, a first user (e.g.
  • a passphrase assistance service may provide the first user with the PRC via one or more emails and/or Short Message Service (SMS) or other means.
  • SMS Short Message Service
  • the passphrase assistance service may log the event and/or notify other box owners and/or other users in boxes associated with the first user that passphrase assistance was triggered.
  • their agent e.g. Agent 340
  • an agent may require that the user sets a new passphrase, after which the agent may generate a new EPB and store it locally or in any manner accessible by the end user or agent and store the corresponding new PRC in the passphrase-recovery box and/or provide it to other trusted party(s) and/or provide it to the passphrase assistance service.
  • An agent may store other state or recovery data locally (e.g. as part of Storage Data 331 ) or in any many accessible by the end user or agent. This may include some or all of its working data (e.g. Working Data 343) and/or some or all of data stored in the home box (e.g. Home Box 41 1 ) such as state data, user certificates, CA certificates, keys, permits, codes for invites or contacts or change-owner operations etc.
  • Such recovery data may avoid the necessity of having a home box or as a backup for a home box or so that the agent may start-up without necessarily having to access its home box.
  • the agent may also store synchronisation information, for example between the local and remote copies of encrypted content. This information may be kept in a locally (e.g. in Agent Store 330) along with other meta-data about the encrypted content.
  • Agent Store 330 e.g. in Agent Store 330
  • An advantage of this approach is that it may allow the agent to work offline (not connected to any central services) and synchronising to occur at a later time.
  • End systems may contain an agent (e.g. Agent 340).
  • Agent may be in software and/or hardware, may be standalone such as an application, executable, service etc. and/or may be in a component form, such as a subsystem, library, plug-in, extension etc.
  • Agents may be used to facilitate secure and/or private sharing of data with other users, agents, applications, systems, services etc.
  • An agent may be relatively autonomous and have significant ability to manage its own data, privileges, communications and any other management functions.
  • an agent may be considered a "control centre" for collaboration and a set of agents may distribute this control between themselves.
  • agents may be instantiated anywhere, and as such, an agent may be considered a virtual entity, such as a "virtual appliance” and multiple co-operating agents may be considered as forming one or more "virtual worlds" or "virtual private clouds”.
  • An agent may be dynamically loaded, for example downloaded from a website and/or it may be installed locally (e.g. Content Store 320 or Agent Store 330).
  • the agent code is digitally signed to ensure integrity of the agent as a trusted application.
  • An agent may be a separate device such as a plugin device, an expansion card, a network connected device or any other integrated hardware with access or connection to processing means.
  • An agent may include an interface (e.g. Interface 341 ) to a user (e.g. Userl 301 ) or other applications (e.g. Applications 312) or to a Virtual File System (e.g. VFS 313).
  • An Interface to a user may be a graphical user interface (GUI).
  • An interface to other applications may be an application programming interface (API).
  • GUI graphical user interface
  • API application programming interface
  • An agent may include processing capabilities (e.g. Processing 342). This may include operations such as uploading, downloading, compression, decompression, connection management, synchronisation, local/remote conflict management, policy enforcement, cryptographic functions etc.
  • Cryptographic functions may include encryption, decryption, key management, digital signature creating and checking, revocation checking, hash calculations, key generation, key rotation, certification requests, certificate generation, certificate verification, certificate path validation etc.
  • an agent may need to process and act on protocols (e.g. Protocols 360) to/from other agents.
  • An agent may contain working data (e.g. Working Data 343) of which some may be stored locally (e.g. Agent Store 330) and/or remotely in a home box (e.g. one of Agent Boxes 382). Such data may comprise capabilities and/or state information necessary to ensure the security and/or privacy of the user and/or end-system.
  • agent data may comprise, without limitation, policies, privileges, lists, keys, permits, certificates, passwords, passphrases, codes, configuration, state information, system information, location information, meta information, operation progress indicators or any other information that related to the control or management of end-systems and/or interactions with other users (e.g. used by Control Layer 440).
  • agent data may be encrypted and/or stored locally and/or remotely.
  • Working data may be initialised by reading the home box on start-up, for example for other user's certificates, CA certificates, codes, in progress operations etc,
  • Agents may interact via protocols (e.g. Protocols 360). This interaction may be direct or indirect. Direct interactions include direct connections, peer-to-peer systems, file transfer systems, physical means or any other suitable method of transport. Indirect interactions may be via an external messaging and/or queuing services and/or messages and/or tasks stored via a separate remote service (e.g. Remote Services 370) . Agents communicating in an indirect way may be considered as using virtual protocols or virtual peer-to-peer (P2P) mechanisms to communicate.
  • P2P virtual peer-to-peer
  • Agent protocols may be used for exchanging encrypted tasks with other agents, such as invitations, capabilities, certificates, encrypted keys etc. Such tasks may be used for setting up trust relationships, uploading or downloading information, supplying or receiving status, managing notifications, managing cryptographic functions, checking revocation etc.
  • agents may use protocols to decentralise management and may use end-to-end encryption to protect system data using substantially the same mechanisms normally used to manage and protect end-user data.
  • the techniques used for the end-to-end sharing of user content may be applied to the end-to-end transfer of management messages and/or security information such as keys, certificates and/or capabilities.
  • a task or message may be any kind of interaction or communications between agents and/or users including messages, acknowledgements, signalling, information transference etc.
  • a sequence of tasks may form a transaction.
  • All or part of each task or protocol interaction may be signed and/or encrypted.
  • Signing may use a signing credential such as their system signing or registrar private key.
  • Encryption may use an encryption credential of the intended recipient or Password Based Encryption (PBE).
  • a task may use a standard format such as Cryptographic Message Syntax (CMS) which may provide a standard way for signing and/or encrypting a payload and/or providing associated meta-data.
  • CMS Cryptographic Message Syntax
  • Tasks may have a header.
  • a header may have one or more fields for sequencing, addresses, identifiers, tags and/or other meta-data, For example, fields may include task number, task size, task type, encoding, sender, recipients, time stamps, validity period, checksums etc.
  • Tasks may have multiple body parts. For example, a task for several users may have a body part for each recipient, and each body part may be encrypted, for example using the respective encryption certificate of each associated recipient.
  • Tasks may be addressed to one or more recipients. Recipients may be other users of the system or potential users. Note an advantage of embodiments of the present invention is that tasks may be addressed to users who have not yet registered or enrolled or yet known by the system. In this case a contact box may be created in advance of a user registering, ready for when they are able to access it.
  • Tasks may be numbered and/or have a unique identifier, for example to recover from lost messages, to retry if tasks have not been acknowledged within a selectable interval, to prevent replay of tasks, to ensure sequencing, to manage transactions etc.
  • Protocols may consist of a sequence of tasks and/or message exchanges and/or form a transaction.
  • Tasks and/or messages may be exchanged using any suitable means, such as email, instant messaging, a notification service, a collaboration service, a queuing service or any other message related means etc.
  • any one or any combination of remote services e.g. Remote Services 370
  • a refinement of a message box may be a pair of contact boxes which separate forward and reverse interactions.
  • one contact box may be the out-box of a first user and the in-box of a second user, whilst the other contact box may be the out- box of the second user and the in-box of the first user.
  • a transaction using contact boxes may proceed using any one or any combination of the following steps:
  • a lone confirmation message such as one that is sitting in a user's out-box with no corresponding message in the in-box may be deleted (cleaned-up).
  • Contact boxes may be advantageous to increase security, privacy, robustness, reliability, recovery and/or delivery of interactions between two parties, particularly when using remote services which may have little, if any, support for messaging.
  • contact box pairs may implicitly reflect the current state of a conversation between two users. If the contact boxes are empty, then no conversation may be currently taking part. If messages exist, then they may be processed in an idempotent fashion. For example, if a link fails after a contact box message is fully processed but the message that represents the response to the other user has not yet been posted, then this situation may be easily detected and an appropriate response enacted.
  • Remote services e.g. Remote Services 370, Storage Tier 400
  • a remote service may not necessarily understand the concept of boxes and/or the differences in how they are used. This may allow the remote service to be relatively simple and safeguard the information as the remote service may be relatively blind to who is accessing what and why.
  • a remote service may be considered as logically centralised services but need not have any relationship and/or proximity to each other, Additionally, they may be run on different machines and/or run by different providers and/or at different locations and/or may be distributed and/or replicated. Any one or any combination of remote services may reside on a given hardware, computer and/or server and/or service. There may be many such services, not necessarily related or using the same technology, provider or access techniques.
  • the remote services may comprise any one or any combination of "cloud" services or other services.
  • a remote service may make use of any type of electronic storage and/or transfer means. This includes any system of moving information including sharing systems, application systems, collaboration systems, messaging systems, communications systems, queuing services and other transport systems,
  • a remote service may structure stored information in any relevant way.
  • a storage service may store files organised in a hierarchy of directories
  • a management service may store information in a database and present it to users as forms
  • a collaboration service may store information by category and present information to users as commentable and/or editable pages
  • a support service may store and organise information by issue
  • a task service may store and organise information by function etc.
  • a remote service may store storage data (e.g. Storage Data 372) in one or more data store(s) (e.g. Data Store 371 ).
  • storage data e.g. Storage Data 372
  • data store(s) e.g. Data Store 371
  • Storage data may include any information or data exchanged between an agent (e.g . Agent 340) and a remote service (e.g. Remote Services 370).
  • agent e.g. Agent 340
  • remote service e.g. Remote Services 370
  • Storage data may comprise any one or any combination of storage data parts. Storage data parts may be stored in any one or any combination of data stores.
  • a storage data part may contain any type of content. For example, any one or any combination of: certificate(s), key(s), task(s), message(s), authorisation(s), token(s), content, information, data, meta-data, stream(s) , packet(s), box data, application data, application field(s), database field(s) and/or anything communicable in digital form.
  • end-to-end encryption normally used to protect end-user data
  • Storage data may be compressed and/or signed and/or encrypted.
  • storage data is in a standard format such as Cryptographic Message Syntax (CMS) which provides a standard way to sign and encrypt the storage data as well as other optional meta-data.
  • CMS Cryptographic Message Syntax
  • the signing certificate may be included in the storage data in case the recipient is not in direct contact with the author.
  • the remote service may be relatively “blind” to what type of data it is and/or who is sharing it.
  • Information about storage data such as identifiers, locations, filenames, privileges, versions, backups etc. may be maintained separately by a repository service (e.g. Repository Services 391 ) and/or included as meta-data.
  • a repository service e.g. Repository Services 391
  • a data store may make use of any relevant technology that allows data to be “at rest” such as memory, disk(s), tape(s), storage array(s), network array(s), hard disk(s), digital disk(s), portable disk(s), portable memory, disk array(s), network disk(s) etc. and/or provided indirectly e.g. network file server(s), backup service(s) and other third party storage or “cloud” service(s).
  • relevant technology such as memory, disk(s), tape(s), storage array(s), network array(s), hard disk(s), digital disk(s), portable disk(s), portable memory, disk array(s), network disk(s) etc. and/or provided indirectly e.g. network file server(s), backup service(s) and other third party storage or "cloud” service(s).
  • a data store may store information in any form, such as files, database entries, object store, directory or any other method of storing or communicating data in electronic format.
  • a data store may be in a single and/or multiple geographic locations. Data may be spread over any one or any combination of data store(s) and/or in a way that may be distributed and/or replicated .
  • a data store may store unstructured information, for example to enable the sharing of files, documents, photos, videos and other user content. Such information may be explicitly manipulated by users.
  • a data store may store structured information , for example be part of an application such as fields, entries, comments etc. Such information may be implicitly manipulated by users as part of a wider application such as a content management system, a customer relationship system, a sales tracking system, a source code management system etc.
  • Information in a data store may be distributed and/or replicated. This distribution and/or replication may be in accordance with a pre-determined policy. For example, based on any one or any combination of frequency, file size, location, time of day, file type, on demand, workgroup category, version, time of day, on demand, type of content, expiry.
  • Boxes may be created for any required purpose and thus there may be a relatively huge number of possible box types and/or box uses.
  • Box types may be conceptual, in that labelling a box with a given type may be just for agent and/or user and/or application convenience.
  • Box types may have stronger meanings, for example, be handled in a special way by an agent (e.g. Agent 340) and/or by a repository service (e.g. Repository Service 391 ) as described herein.
  • agent e.g. Agent 340
  • repository service e.g. Repository Service 391
  • Box types may generally be categorised into three main areas:
  • User boxes e.g. User Boxes 382, Shared Box 402 relating to user or application information (e.g. Content 31 1 , Content Data 321 , Encrypted File 401 ).
  • Agent boxes e.g. Agent Boxes 382, Shadow Box 404, Home Box 41 1 , Home Box 412 relating to agent information (e.g. Working Data 343, Agent Data 331 ), and/or
  • User boxes may store user data.
  • User boxes may represent different collections of data being shared between, different groups of users. Different box types may contain different types of user data. For example: shared boxes, managed-user boxes and applications boxes.
  • a shared box may be used for sharing user content (e.g. Content 31 1 ).
  • the content itself may be encrypted with a content key and the content key may be encrypted with a box key and associated with the encrypted content.
  • Encrypted content keys may be unique for each of item of content.
  • Each content box may represent a group of content.
  • Content groups may be referred to as a workspace, shared space, file space, user box, content box etc. Content groups may overlap, thereby creating "Views".
  • content box A may include a storage key S1 encrypted with key A
  • content box C may include storage key S1 encrypted with key C.
  • document F1 which has been encrypted with key S1 may be part of both content box A and content box C.
  • a managed-user box may be a client box or sub-box that inherits properties from a parent box.
  • a parent box may have company's staff members while a managed-user box may have members of a company's clients.
  • any of the staff may be able to read and/or write to managed-user boxes, for example because of inheritance, but a given client may only be able to read and/or write to sub-boxes they've been invited to.
  • Under the parent box may be different types of managed-user boxes, for example:
  • a personal client box which may be read or updated by a single client.
  • An all-client box which is visible to all clients under a parent box. For example, a company may publish common material to its clients, such as a newsletter. An all-client box may be read-only to clients. • A shared client box which is visible to multiple clients. For example, when sets of clients, associates, contractors etc need to collaborate under the control of a business,
  • a joint client box for example to allow for multiple logins to the same box, such as a husband and wife.
  • managed-users effectively live in a very private and isolated "world” scoped by the parent-box.
  • Managed-users may be assigned directly to appropriate client boxes, for example by the owner or privileged members, which may avoid requiring specific acceptance by the managed-user.
  • a business may make use of a private portal (described below) in order to provide a simpler interface for those managed-users to login in with.
  • Application boxes may be special types of user boxes (e.g. User Boxes 381 ) which may be used by applications for managing information on behalf of a user.
  • structured information such as fields, XML fields, records, slots, objects, streams etc may be stored as separate files in one or more boxes depending on the access requirements. Access to individual items may achieved be accessing the corresponding file.
  • Example applications include password managers, electronic messaging, instant messaging, chat, forums or any other type of collaboration application.
  • Agent Boxes may be used to store agent or system data. Agent boxes may store different collections of data being controlled by the agent to facilitate the management of information on behalf of users. Different box types may contain different types of agent data. Some examples include home boxes, meta-data boxes, passphrase-recovery boxes, revocation-custodian boxes, personal-box-recovery boxes, credential-backup boxes etc.
  • a "home" box (also called working, hibernate, mobility, state, knowledge, holding, standby, or asset box) may be used for the private use of an agent (e.g. Agent 340). It may be used to store the user's own capabilities and other agent working information , such as certificates, keys, state data and/or configuration. Any or all of these items may be may be digitally signed such as using a signing credential of the owner. Any one or any combination or all of these items may be encrypted (e.g. Encrypt 484 , Encrypt 494) such as using the encryption certificate (public key) of the owner (e .g.
  • a home box may store relatively persistent information such as box keys and/or permits (a collection of keys for a box) of boxes they've been invited to, certificates of user's they have made contact with etc.
  • a home box may store relatively transient information such as copies of messages, copies of codes that have not yet been accepted, for example contact codes, invitation codes, change owner codes etc.
  • a home box may store working data (e.g.
  • Working Data 343) such as configuration information, custodial information, cryptographic seeds, state data or any other run-time data in which the agent (e.g. Agent 340) needs for its ongoing operation.
  • the home box(s) may serve the purpose of remotely storing agent data either as a backup or because it is not desirable to persist such agent data locally.
  • the storage and/or repository service might limit access to encrypted agent data to just the owner, for example, using access controls or appropriate Attribute Certificates (ACs).
  • ACs Attribute Certificates
  • the storage and/or repository service may limit access to particular home boxes and/or particular content in a home box, for example based on location.
  • Home boxes may be an example of a " 1 :0" box because only the owner may read and write to such a box.
  • Home boxes may also be provided as a facility (e.g. part of Backup Services 393).
  • a meta-data box (e.g. Shadow Box 404) (also called a shadow, broadcast, management, command or supervisory box) may be used for storing information about files in a box. For example: locations of files in that box, indexes or keywords e .g. to facilitate searches, icons, thumbnails, requests and acknowledgements of read receipts, history, audit trails, permits, managed-user or client credentials, previous box keys, annotations to files, version information, information about sets of files forming structured/application data etc.
  • the meta-data box may be a separate box from the box it is describing and/or the meta-data (e.g. Meta-data 403) may be an area within the same box (e.g. Shared Box 402).
  • a meta-data box or meta-data area may be considered as a "broadcast” mechanism for members of a box. In implementation, it may consist of a number of "slots" and/or a queue, one for each user, which may have advantages such as avoiding concurrency by multiple writers, facilitate versioning, facilitate transitioning between permits, manage client credentials, facilitate key rollover etc.
  • the meta-data box may be a way of keeping agent system data in a way that keeps the central storage system "blind” from such data and therefore preventing or making it difficult to deduce what activities agents may be performing or co-ordinating.
  • a passphrase-recovery box may be used to store a passphrase recovery code (PRC).
  • PRC passphrase recovery code
  • the setup may be in three parts. Firstly, the first user invites a second user (e.g. User2 302) to their passphrase- recovery box. Secondly, the first user and/or the first user's agent generates a Passphrase Recovery Key (PRC), encrypts it with the box key and stores it in the passphrase-recovery box. Thirdly, the PRC is used to encrypt the keystore passphrase which is stored locally (e.g.
  • PRC Passphrase Recovery Key
  • Agent Store 330 as an Encrypted Passphrase Blob (EPB). If the first user forgets their passphrase, then the second user can give them the PRC which can be used to decrypt the local EPB to regain their keystore passphrase, Preferably on recovery, the first user's agent may require the first user to choose a new passphrase, which may then be encrypted with a new PRC which is stored in the passphrase-recovery box and a new EPB which is stored locally. Note that the PRC may also be provided by a passphrase assistance service. [0188] A revocation-custodian box may be used by a first user to store a pre-signed revocation request and/or revocation passphrase (e.g. as defined in RFC 4310).
  • the revocation request may be signed by the first user's registrar private key.
  • the first user may invite trusted or custodial users to the box.
  • a custodial user may submit the revocation request to the associated revocation service (e.g. Certificate Services 392) to get the first user revoked.
  • the associated revocation service e.g. Certificate Services 392
  • a personal-box-recovery box may be used to allow recovery of single-user boxes after the loss of credentials.
  • an owner of a personal box may safeguard that box by storing the personal-box keys in an encrypted blob encrypted with a recovery key.
  • This recovery key may then be stored in a personal-box-recovery box, encrypted with that box key.
  • the user can get invited back to their personal-box-recovery box, to retrieve the recovery key which can be used to retrieve the encrypted blob in their personal box containing their personal-box keys.
  • a credential-backup box may store encrypted credentials. This may be separate, in conjunction with or in addition to a credential backup (e.g. Backup Services 393).
  • a credential-backup box may store encrypted credentials of managed-users.
  • access to a credential-backup box just like other boxes, may require a mutual (client-side) SSL connection. If such a temporary SSL certificate is used for example from a temporary access service (e.g. Certificate Services 392) such as in the case of retrieving backed-up credentials, then access to the box may be readonly or otherwise restricted.
  • agent boxes There may be many other types of agent boxes, depending on the requirements of agents. These box types may utilise any one or any combination, without limitation, of privileges, read-only access, write-only access, management rights, control restrictions or any other predefined criteria. Examples of other agent box types may include, without limitation, search boxes, overlay boxes, one-way boxes, post boxes, temporary boxes, announcement boxes, broadcast boxes, etc, 2.5.3 Message Boxes
  • Message boxes may be special boxes used to facilitate communications between agents (e.g. within End System 310, End System 350).
  • a message box (also called a task box or control box or “contact” box) may be used for agents to exchange "tasks".
  • Tasks may include messages, indicators, notifications, acknowledgements or any other construct necessary to enable agent-to- agent protocols (e.g. Protocols 360). Protocols may include, for example, to make contact, to establish bilateral relationships, to enable key management, to distribute agent data (e.g. keys, permits, attribute certificates etc), to change ownership, to convey privileges, to manage credentials etc.
  • tasks may be encrypted.
  • a message box may make use of an indicator in the task header in order to facilitate delivery to and/or access from the intended recipient(s). Message boxes may also be provided as facilities (e.g. part of Repository Services 391 ).
  • a "contact” box may be a specialisation of a message box in order to provide reliable messaging using a remote service or storage service.
  • Each contact box may be used for uni-directional messages between two agents/users. In this case, a bi-lateral relationship may require a pair of contact boxes, one in each direction.
  • a pair of contact boxes may provide in-box/out-box functionality such that, between two agents, a contact box represents an in-box for one agent and an out-box for the other agent. Further restrictions may apply, for example agents may only read from their in-box and only write to and delete things in their out-box.
  • Contact boxes may be similar to "1 : 1 " box because there may be just one writer (the owner) and one reader (the recipient) to a contact box.
  • a contact box may be considered as a private (one-way) tunnel between two agents. Note that contact box pairs are logical and that physically they may be separated, for example, a user may store their "forward" contact boxes in their own storage service, thus accessing the "reverse” contact boxes would be via the storage service of the associated user.
  • message boxes e.g. Contact Box 408, Contact Box 410 of Figures 4a and 4b
  • remote service ' e.g. Remote Services 370 of Figure 3
  • Facility or system services may optionally be used to facilitate the operation of end systems (e.g. End System 310, End System 350).
  • agents e.g. Agent 340
  • agents may have capabilities to perform facility services itself and/or in conjunction with other agents.
  • the facility services may be considered as logically centralised services but need not have any relationship to each other. For example they may be run on different machines and/or by different providers and/or at different locations and/or may be distributed and/or replicated. Any one or any combination of facility services may reside on a given computer and/or server and/or service. Communications between end systems (e.g. End System 310, End System 350) and the system services may use communications security such as Secure Sockets Layer (SSL) and/or Transport Layer Security (TLS), Online Certificate Status Protocol (OCSP) etc.
  • SSL Secure Sockets Layer
  • TLS Transport Layer Security
  • OCSP Online Certificate Status Protocol
  • Authentication with one or more of the facility services may use mutual authentication, such as mutual or client-side SSL TLS. If certificate-based authentication is used then appropriate revocation checks may be made e.g. at the time of authentication.
  • a repository service e.g. Repository Services 391
  • remote services e.g. Remote Services 370
  • rich functions such as management, notifications, billing, quotas, business rules, system events etc. are always provided regardless of the capabilities of the underlying remote service.
  • An agent may interact with the repository service instead or as well as one or more remote services.
  • An agent may use a repository service to act as a proxy for a remote service, so it doesn't have to deal directly with that remote service.
  • An agent may use a repository service to limit or simplify the interactions with a remote service, for example, only deal with ''low level" functions of a remote service such as storage and/or using "high level" functions from a repository such as resource management, notifications, meta-data services, messaging, accounting, billing, auditing etc. Agents may further build on repository services to provide their own higher level functions such as near real-lime interactions, near real-time collaboration, on-demand synchronisation, streams etc.
  • the repository services may provide a consistent approach to security, protocols, functionality etc.
  • the repository services may maintain, control, manage and/or co-ordinate activity by instructing agents about how to interact with the remote services to provide appropriate information, parameters, directives etc.
  • this approach may allow the remote service to remain relatively “blind” to or kept relatively “hidden” from users and their activity. It may also allow remote services to be relatively simple, such as allowing the use of storage services which provide little more functionality than a simple remote disk service.
  • a repository service may facilitate and/or maintain information about which storage data parts are in which box and where those associated storage data parts are located. For example, the location, relationships and other associated meta-data of data in a box.
  • a repository service may provide access information to agents. This may be to locate the service e.g. addresses, protocols, ports, etc to authenticate to the service e.g. account details, login parameters, identifiers, references, tokens, etc. and/or to navigate the service e.g. content type, paths, filenames, permissions, authorisations, attribute certificate(s) or any other type of meta information.
  • a repository service may harmonising the meaning and/or effects of actions e.g. add, delete, update, create, rename, recover, change permissions etc. This includes the handling of the associated target object which may be a field, a file or folder or any other object or group of objects.
  • a target may additionally have a path or other identifying representation.
  • a repository service may hide many of the details of the underlying remote services and or data stores.
  • the repository service may manage distribution and/or replication, hide incompatibilities, facilitate seamless transition from one storage provider to another.
  • a repository service may allow splitting and/or aggregating views across storage services. For example, users may maintain their own storage service and therefore a "box" may be a view of each of the files provided by each user in that box. For example, if a first user stores a file, in their own storage service, a second user may download it from the first user's store. If the second user updates the file then the updated file may be stored in the second user's storage service. At this point the repository service may indicate where the latest version is and/or instruct the agent of the first user to delete their older version of the file in the first user's storage service.
  • a repository service may hide and/or manage the separation of encrypted content (e.g. Encrypted File 401 ) from the encrypted content key (ECK). This may allow agents to logically treat an upload (e.g. Upload 423, Store 427) and/or download (e.g. Download 433, Extract 437) as a single service. This may also allow other services such as box-to-box copy, as it would allow a download, re-encryption and upload of just the ECK, and then the repository to associate the new ECK and encrypted content with the new box.
  • Encrypted File 401 e.g. Encrypted File 401
  • ECK encrypted content key
  • a repository service may manage resource information about other system services (e.g. Facility Services 390) and/or remote services (e.g. Remote Services 370). Resource information may include functions such as statistics, auditing, usage, and associations e.g . between users, groups , files, workspace etc. It may further enforce policies such as quotas, accounts, reasonable use etc. The resource service may also collect events for the purpose of trends, analytics, reconciliation, compliance etc.
  • a repository service may manage system information about data stored in remote services. For example system information may include location, authentication, authorisation, identifiers, files, boxes, servers, location, access methods, addresses, sizes, types etc. In addition, the repository services may also manage and/or control information related to distribution, replication, backups, versions and other system information necessary for versioning, recovery, fail-over, fail-back and/or load-sharing.
  • a repository service may manage users.
  • User information maintained may include name, email, telephone numbers, billing information and/or other account information. Users may be controlled by managing which functions they have access to and/or their status in the system. For example, a user may be suspended/un-suspended by settings/unsetting a status and/or by removing/re-instating access to a user's home box.
  • a repository service may provide a "console" to manage users, billing, resources, services, settings etc.
  • User management may include mechanisms to revoke users, suspend/un-suspend users, change notification settings etc.
  • Billing management may include mechanisms to change a user's name, account references, billing sponsor, telephone number etc.
  • Resource management may include mechanisms to delete users, delete boxes etc.
  • Service management may include mechanisms to add/delete services such as user's ability to create boxes, send messages etc.
  • Configuration management may include mechanisms to set default key sizes, default certificate usages, default notifications, default templates etc.
  • a repository service may be used to notify end-users of events, alerts, warnings or other time sensitive information.
  • Events may include changes to content, workspaces, memberships etc.
  • Alerts may include pending invitations, pending contacts, pending administrative requests etc.
  • Warnings may include pending resource limits, pending subscription renewals, pending certificate expiry etc.
  • Notifications may be delivered in many forms and in many ways. Notifications may have a severity level. Notifications may be bunched together, such that if many events occur in a given time period, then a single notification containing relevant events included in that notification.
  • Mandatory events may always be delivered, such as warning(s) or notice of policy change(s).
  • Optional events may need to be subscribed in order to enable them , such as content changes.
  • In-band events may be delivered to any online agent.
  • Out-of-band events may be delivered externally, such as via email, Short Messaging Service (SMS), instant messaging etc.
  • SMS Short Messaging Service
  • a repository may be used for messaging, for example, as an alternative to message boxes (e.g. Message Boxes 383). This may be to add an extra level of access security and/or to reduce dependence on any particular remote service.
  • a repository service may limit access to information through the use of access controls and/or associated Attribute Certificates AC(s).
  • An AC may be issued by a box owner granting certain privileges to that box. For example read, read/write, delegated administration, etc.
  • An AC may include in the X.509 Holder field, an identifier for the SSL certificate or identity certificate to whom the authorisation relates. When used, ACs may be passed at the beginning of a session or may be provided at the time a request is made.
  • a repository service may be used for user audit, such as keeping a history of events for users and/or boxes. Events may include created, read, updated , deleted , restored, renamed, access granted, access withdrawn etc. Such events may include user and/or administrative operations for client boxes, shared boxes, sub-boxes etc. For example client access granted/removed, box created/deleted/renamed etc.
  • the repository service may also retain events for boxes that have deleted.
  • deleted user box events may be associated with the owner and/or deleted sub-box events may be associated with the parent box.
  • a repository service may provide a system audit, for example, by maintaining a log of console activity and/or other deployment changes e.g. changes in configuration.
  • the audit may be kept via a log file and/or by sending events to one or more boxes, which may be useful in order to leverage repository notifications.
  • a repository service may perform maintenance operations to ensure consistency with referenced data to data actually stored. Such maintenance may be periodic and/or performed in the background and/or be batch in nature. For example, repository services may check reference information matches actual information in the remote services and if different, may take actions such as removal of unattached blobs, removal of items marked as deleted and past their recovery date, check integrity of remote items against meta-data in the repository such as size, checksums etc.
  • a repository service may perform clean up actions for example periodically, in the background and/or in batch mode. Examples include removing expired messages from contact/message boxes, removing contact/message boxes that are empty and have no matching user, removal of old versions of files, etc.
  • a repository service may perform automated actions based on pre-defined policy and/or rules and/or schedules. Automated actions may include maintenance, clean-up, distribution, replication, backup an/or any other administrative function. Predefined policy and/or rules may be based on any one or any combination of frequency, file size, location, time of day, file type, on demand, workgroup category, version, time of day, on demand, type of content, expiry, etc.
  • a repository service may also be used to enforce policy and/or restrictions and/or other controls.
  • a library service may enable users to buy a certain number of documents and then download them as needed,
  • the repository service may restrict any given user's download to a set number and/or set value and/or ensure that a given document is only downloaded by a single user.
  • the _ repository service may make further files inaccessible,
  • the repository may maintain an audit, for example, to reconcile activity with a user's account.
  • Other repository services may include commercial services such as accounting, billing, archive, hosting, tracking, auditing services etc.
  • Certificate Services may perform certificate signing, revocation, renewal, temporary access and other certificate management functions. In other embodiments of the present invention, certificates may be self- generated and/or signed by other third parties and/or managed externally.
  • a certificate signing service may be used to sign certificates generated by an agent. Certificates may need to be signed on setup of an agent and/or may be re-issued or renewed after revocation or expiry.
  • the signing service may use one or more trusted Certification Authority (CA) certificate(s) and/or Trust Anchor (TA) certificate(s) which is known by end systems (e.g. End System 310, End System 350) and/or other system services and/or remote services (e.g. Remote Services 370).
  • CA trusted Certification Authority
  • TA Trust Anchor
  • certificates which may be end-entity, CA or TA certificates, may include SSL certificates, signing certificates, encryption certificates, email certificates, system signing or registrar certificates, attribute certificates etc.
  • certificates for system services such as a revocation service, a temporary access service etc.
  • the certificate signing services may have policies, such as relating to settings, behaviours, restrictions and/or notifications.
  • Settings may include rules about generating certificates such as key size, key usages, validity period, encryption algorithms etc.
  • Behaviours may include rules about how the certificate signing service handles boundary cases such as whether to allow the renewal of expired certificates, whether to keep copies of issued certificates etc.
  • Restrictions may include rules about what email addresses to allow or proof of identity is required .
  • Notifications may include rules about what to send e.g. warning(s) about expiring certificates, when to send e.g. at decreasing periods as the expiry gets closer, how to send e.g. via email, SMS or other type of notification, etc.
  • a revocation service may be used to manage revocation of certificates. This service may be accessed via the Online Certificate Status Protocol (OCSP) service and/or make available a Certificate Revocation List (CRL). The location and/or access point of the revocation service may be specified within each certificate issued.
  • OCSP Online Certificate Status Protocol
  • CTL Certificate Revocation List
  • a temporary access service may be used in the case that client-side, for example SSL, certificates are required for short term access to a system service (e.g. Backup Services 393).
  • This temporary access service may require authentication, such as a name and passphrase previously setup by an agent.
  • the temporary access service may protect itself from passphrase guessing such as restricting the number of incorrect passphrase attempts (e.g. a maximum of five every twenty four hours), and/or introducing increasing delays for each successive incorrect passphrase attempt (with the delays being reset on a correct login or after a period of time). If the temporary access service uses an email address for the name, it may check that the user owns this email address by sending a token or link or other information to that email address for use in obtaining temporary access.
  • Temporary access certificates may be short lived i.e. expire in a relatively short amount of time.
  • the temporary access service may also be used to obtain random SSL certificates which may be endorsed via attribute certificates to facilitate anonymous access (further described below),
  • certificate services may include certificate management services, certificate billing services, smart card or other hardware issuing services, directory services etc.
  • Backup Services may be used for backup and/or mobility such as access from multiple locations and/or multiple devices.
  • Example of backup services include: credential backup services, hibernate services, passphrase assistance services and key escrow services.
  • a credential backup service may store encrypted credentials.
  • the encrypted credentials may be in the form of an encrypted keystore containing those credentials and/or the credential backup service may also be known as a keystore backup service.
  • the encrypted backup may include encrypted credentials as well as an encrypted passphrase blob (EPB).
  • EPB encrypted passphrase blob
  • Such a backup may be encrypted with a passphrase and/or a derived passphrase and serve the purpose of providing credentials if they haven't been stored locally and/or if the credentials have been lost. Since retrieving a backup of credentials may mean that an agent can ' t use their issued SSL certificates, a temporary access certificate may need to be used (e.g. one of Certificate Services 392).
  • the credential backup service may be implemented as boxes.
  • the credential backup service may allow writing of new credentials. If a user connects with a temporary SSL certificate, then the credential backup service may enforce read-only access or other restricted.
  • the credential backup service may be used in conjunction with an external authentication service.
  • the authentication service may be a Virtual Private Network (VPN) and/or the delivery of the credentials or encrypted credentials or keystore or encrypted keystore may use an authentication extension protocol such as Protected Access Credentials (PAC) extension.
  • VPN Virtual Private Network
  • PAC Protected Access Credentials
  • a passphrase assistance service may provide a copy of a passphrase recovery code (PRC) via one or more emails and/or SMS and/or other means.
  • the PRC may be encrypted with a code and the encrypted PRC and/or code sent in one or more messages e.g. the encrypted PRC via email and the code via SMS.
  • This allows a user to copy and paste a relatively complex string from an email into the agent's user interface, but be able to enter a relatively simple string from another email and/or an SMS message.
  • this service may be relatively safe because obtaining the passphrase recovery code (PRC) may be useless without the corresponding encrypted passphrase blob (PRB) which is stored locally on the end-user's machine or in any manner accessible by the user or agent.
  • PRC passphrase recovery code
  • PRB encrypted passphrase blob
  • the triggering of the passphrase assistance service may be logged and/or send notifications, such as to box owners and/or other users in boxes that the recovering user belongs.
  • a hibernate service may be used for home box information (e.g. Home Box 41 1 , Home Box 412). For example, this may be to add an extra level of access security and/or to reduce dependence on any particular remote service.
  • the hibernate service may allow multiple home boxes, for example that contain different types of home box information, and/or restrict access to certain items in each home box. Access may be restricted according to policy, for example location, time of day, possession of authorisation tokens, time since last access etc. For example, a user may be able to download all their home box (encrypted) keys if they are located in the US, but may only be able to download particular (encrypted) keys if they are located overseas.
  • a key escrow service may store copies of encryption private keys. Because of the seriousness of allowing private keys to exist outside a user's control, it is important that a number of associated safeguards are in place such as strong security, monitoring, auditing, procedures, independence etc (further described below).
  • the key escrow service may require policies in the CA and/or agent, for example, the agent providing their private key encrypted with the escrow server's public key to the CA, the CA providing the user certificate and encrypted private key to the escrow service, the escrow service verifying the private key matches the user's public key, after which the CA may provide the encryption certificate back to the user. Note that justifying key escrow for backup reasons may not be necessary as embodiments of the present invention may have many mechanisms for recovery and to ensure the safety of encrypted content (further described below).
  • Other backup services may include backup facilities for the system services themselves, for example certificate backup services, replication services, distribution services etc.
  • any one or any combination of the details described and/or illustrated may actually be implemented. It is important to note that operations may be primarily performed client-side, such as by an agent (e.g. Agent 340), and that central services may have a minimal role of providing facilities (e.g. Facility Services 390) and remote services (e.g. Remote Services 370).
  • agent e.g. Agent 340
  • central services may have a minimal role of providing facilities (e.g. Facility Services 390) and remote services (e.g. Remote Services 370).
  • the purpose of a storage tier may be to manage storage data parts (e.g. Storage Data 372). For example, to store and/or retrieve content that may be useful for users and/or agents.
  • the storage tier may consist of one or more data stores and/or applications that store data and/or any other digital information.
  • the storage tier may also include messaging means, in which case, any one or any combination of message boxes (e.g. Contact Box 408, Contact Box 410) may be part of a messaging system.
  • the storage tier may include local storage (e.g. Content Store 320, Agent Store 330).
  • content stored in the storage tier is- encrypted.
  • This approach may enhance the security and/or privacy of the system. For example, storing encrypted data may prevent data leaks, unauthorised access or abuse by any intermediate storage provider. This approach may also ensure that the storage provider is relatively "blind" to who is interacting and/or what is being stored and/or exchanged. Note, in practice, any number of storage means and/or providers may be used.
  • the storage tier may be little more than a "remote disk” or “remote buffer” and may be relatively simple.
  • the storage services need not necessarily be required to perform higher level functions such as user management, notifications, data management etc. especially if used in conjunction with a repository service.
  • Parts of the storage tier may also be embedded in applications, such as fields in a management application and/or records in a database application and/or entries in a customer relationship system and/or transactions in an interactive application and/or any other application involving storage or transport means.
  • Storage data (e.g. Storage Data 372) may be stored in parts.
  • Storage data parts may include encrypted content, encrypted associated key(s), and/or other data. Collections of storage data parts may be organised into logical collections called boxes. Box data may include any one or any combination of storage data part(s).
  • Box data may comprise encrypted content and/or a digital signature and/or an encrypted wrapping key (EWK) and/or other meta-data
  • the box data may be in a standard format such as Cryptographic Message Syntax (CMS) in order to provide a standard way to sign and/or encrypt the box data and/or associated meta-data.
  • CMS Cryptographic Message Syntax
  • the box data may include the signing certificate of the originator, in case the recipient is not in direct contact with the originator.
  • Meta-data may include descriptive and/or identification information such as size, filename, path, algorithms, authors, recipients, certificates, checksums, versions, etc. If a EWK is used, then the EWK may be stored separately from the encrypted content.
  • Box data may be signed (e.g. Sign 424, Sign 443, Sign 446, Sign 464, Sign 476). If the box data is compressed then the compressed form may be signed (e.g. Sign 424). Any appropriate signing key (e.g. one of Private Keys 482) and/or message authentication code (MAC) may be used to sign the payload. For example:
  • the owner's signing private key may be used to sign data being stored in a user box (e.g. User Boxes 381 , Shared Box 402) or an agent box (e.g. Agent Boxes 382, Shadow Box 404, Home Box 41 1 ).
  • a user box e.g. User Boxes 381 , Shared Box 402
  • an agent box e.g. Agent Boxes 382, Shadow Box 404, Home Box 41 1 .
  • the owner's registrar private key may be used to sign data being stored in a message box (e.g. Message Boxes 383, Contact Box 408, Contact Box 410).
  • a message box e.g. Message Boxes 383, Contact Box 408, Contact Box 410.
  • Having different signing keys for message data may be advantageous to ensure that user/agent data cannot be accidentally or maliciously be interpreted as a control message.
  • Box data may include one or more signing certificates of the originator.
  • user signing certificates should be included with user data so that recipients may verify the signature of the originator even if the recipient does not have the required certificate, for example, they have not made contact, the signing was done with an old or revoked certificate etc.
  • system signing certificates or registrar certificates should not be included in message data, for example to ensure that messages are current and/or authentic etc.
  • Box data may be encrypted (e.g. Encrypt 426, Encrypt 444, Encrypt 447, Encrypt 463, Encrypt 475, Encrypt 484, Encrypt 494). Encryption may encompass box data that is compressed and/or signed.
  • the box data may be directly encrypted using a primary key or may be indirectly encrypted by generating and using a secondary wrapping (e.g. Wrap 425, Wrap 435).
  • the wrapping key may be random and/or unique and/or one-time and/or a symmetric key.
  • the wrapping key may be encrypted with the primary key (known as a Key Encryption Key, KEK) to form an encrypted wrapping key (EWK) and may be appended to the encrypted box data or stored (e.g. Store 427) separately (e.g. Shadow Box 404).
  • KEK Key Encryption Key
  • Primary keys used to encrypt box data payload may be any one or any combination of the following forms:
  • a recipient's encryption certificate e.g. Encrypt 447, Encrypt 475) tasks (e.g.
  • Sharing Layer 420 The purpose of a sharing layer (e.g. Sharing Layer 420) may be to manage collaboration and/or storing and/or sharing of data between users and/or applications and/or agents. Note that though examples may describe "users", they equally apply to automated "applications" and so the term “user” should also be read as “application” as appropriate.
  • Shared data may be compressed and/or digitally signed and/or encrypted and/or be structured in a standard form such as CMS.
  • sharing management may primarily be performed and controlled client-side, such as by an agent (e.g. Agent 340).
  • Agent may interact with other system services (e.g. Facility Services 390) and/or remote services (e.g. Remote Services 370)
  • sharing may be achieved via different means, such as direct connection, peer-to-peer, physical delivery etc.
  • a repository service (e.g. Repository Services 391 ) may be used to manage and/or assist in the management of shared data.
  • a repository service may maintain storage related information such as the names of files, their sizes, permissions, locations, access methods, authorised users etc.
  • An agent and/or repository service may organise data into partitions or "boxes" and may restrict access to these boxes to authorised users only, Boxes may comprise data encrypted with the same box key.
  • the sharing layer may make use of a repository service (e.g. Repository Services 391 ) and/or one or more underlying remote or storage services,
  • the agent may interact directly with the repository service for management and control functions and/or separately with the remote service for the actual storing and/or retrieving of data.
  • This may allow the repository services to look after most higher level functions, such as security, versioning, access control, privileges, naming, recovery, backup etc while the remote service(s) may look after simpler storage related functions such as add, delete, append, upload, download, delete, rename etc. This may allow the storage services to be relatively simple and/or reduce dependence on a particular remote service or storage service or technology.
  • repository services may provide a co-ordination function, such as where data is located and how to get to it, with agents taking care of particular details, such as interpreting the files stored in the box, the keys and/or permits, the relationship to other boxes e.g. sub-boxes etc.
  • a first user e.g. Userl , 301 , Userl 441
  • application e.g. Applications 312
  • an associated first agent e.g. Agent 340
  • content e.g. Content 31 1 , File 421 .
  • Content may be compressed (e.g. Compress 422). Compression may be beneficial when the payload is relatively large and/or it is not already in a compressed form e.g. file formats for archives, publishing documents, pictures, audio, video etc.
  • Content may be signed (e.g. Sign 424) such as with the user's signing private key (e.g. one of Private Keys 482). If content is a stream, then Message Authentication Codes (MACs) may be inserted into the content, The user's signing certificate may be included in the content (e.g. Encrypted File 401 ), for example if the content is associated with a CMS format.
  • Sign 424 such as with the user's signing private key (e.g. one of Private Keys 482).
  • MACs Message Authentication Codes
  • the user's signing certificate may be included in the content (e.g. Encrypted File 401 ), for example if the content is associated with a CMS format.
  • the content may be encrypted (e.g. Encrypt 426) preferably using a wrapping key or content key (e.g. Wrap 425).
  • the content key may be encrypted by a box key (e.g. from Permit 442).
  • the encrypted content key (ECK) may be appended or prepended to the encrypted content or be stored separately e.g. added (e.g. Store 427) to the meta-data (e.g. Meta-data 403).
  • the encryption of the content and/or the content key may be performed using any other suitable key, such as a community key (e.g. Community Key 445) or box key or a certificate.
  • the encrypted content (e.g. Encrypted File 401 ) may be uploaded (e.g. Upload 423) to a remote service (e.g. Remote Services 370).
  • the first agent may use a repository service to obtain information about which remote service to use and/or notify other users that content has been uploaded .
  • a reference to the encrypted content may be as simple as a Uniform Resource Identifier (URI) or Uniform Resource Locator (URL) for example to a public area of a "cloud" or other remote service.
  • URI Uniform Resource Identifier
  • URL Uniform Resource Locator
  • a second user e.g. User2 302, User2 451
  • application associated with the second end system e.g. End System 350
  • the second agent may use a repository service (e.g. Repository Services 391 ) to obtain the location and other necessary information for accessing the remote service.
  • the second agent may decrypt the downloaded content. This may involve decrypting an ECK (e.g. Wrap 435) and then using the content key to decrypt the content.
  • ECK e.g. Wrap 435
  • the ECK may be extracted (e.g. Extract 437) from meta-data (e.g. Meta-data 403) which may be stored in the shared box together with the encrypted content (e.g. Shared Box 402) and/or a separate box (e.g. Shadow Box 404).
  • the decryption of the content and/or the ECK may be performed using a key associated with the original encryption e.g. a community key (e.g . Community Key 445) or box key or a certificate. Note that decryption may be deferred until the associated key is available, for example, if the owner delays the release of keys such as to ensure all members gain access to the content at the same time.
  • the second agent may check (e.g. Check 434) the signature and/or revocation status.
  • the signature may be checked against a signing certificate (e.g. one of Contact Certificates 472) of the sender or a signing certificate provided with the content, such as associated with a CMS format.
  • Revocation may be checked using a certificate service (e.g. Certificate Services 392) for example via OCSP. If a signing certificate has been revoked and/or has expired, then the agent may check if the signature was valid before the date of the revocation and/or expiration.
  • MACs Message Authentication Codes
  • content e.g. Content 31 1
  • content Data 321 may be stored locally as encrypted content (e.g. Content Data 321 ).
  • Access to encrypted content such as by a user (e.g. Userl 301 ) or applications (e.g . Applications 312), may be via a virtual file system (e.g. VFS 313) and/or an agent (e.g. Agent 340).
  • the VFS and/or agent may use "on-the-fly" or real-time cryptography to decrypt on reading and encrypt on writing.
  • the content may be re-encrypted (e.g. Content Data 321 ).
  • the re-encryption may involve different parts for content, signature and other meta-data.
  • Such parts may be stored in files and/or in a local database (e.g. Agent Data 331 ).
  • encryption may be in three parts:
  • Re-encrypting the content may allow random read/writes to the file using an appropriate cipher. If a file is re-encrypted, then it may be named using a random string to prevent "leakage" of information from the filename.
  • the named file may encode information, such as a unique ID used by a repository service (e.g. Repository Services 391 ) to facilitate recovery and/or synchronisation, for example if associated meta-data or database records are lost and needs rebuilding.
  • the encrypted signature may allow for the checking of integrity and/or authenticity. Because a file may be opened and closed locally many times, an efficient signature mechanism may be used such as a Hash-based Message Authentication- Code (HMAC). Anytime a file is opened and closed the HMAC may need to be recalculated, though an optimisation may be to allow changes to accumulate over a given period of time before (re-)calculating the HMAC. If a downloaded file is opened for read/write or write, then the signature may be removed and replaced with a HMAC.
  • HMAC Hash-based Message Authentication- Code
  • the encrypted meta-data may contain the first and second keys as well as other control information, such as a Unique Identifier (UID), filename or any other necessary information.
  • the first key may be the same as the second key.
  • the third key may be a local key such as a volume key protected by the user's credentials or a local box key or meta-data key for the associated box, If a local key or volume key is used, then it may be backed up as meta-data (e.g. Meta-data 403). This backup enables another member of the box to provide a user who was revoked or lost their credentials with their volume key in order to recover any documents encrypted on their local machine that had not been shared at the time of credential loss.
  • Meta-data 403 meta-data
  • the upload process may be similar to the one described above, except that the step involving file encryption and/or signing may be skipped as this may have already occurred at-rest, for example on-disk.
  • the encrypted control file may be updated with new meta-data that may be provided by the repository service.
  • a file that has uploaded successfully may appear to be the same as a downloaded one. Upload may need to be manually approved by a user if it is digitally signed.
  • Automatic upload and/or download may be controlled by a policy.
  • any policies in place are approved by the user.
  • Such a policy may include predetermined criteria such as controlling upload/download based on time of day, file size, link stability, idle time, frequency, time of day, on demand, workgroup category etc.
  • Applications may use shared boxes (e.g. User Boxes 381 ) to manage shared data on behalf of users.
  • shared boxes e.g. User Boxes 381
  • Applications may store structured data such as spreadsheets, databases, records or any other single or collection of objects.
  • a password application may store individual items in different files and/or boxes so as to manage access to different fields by different people.
  • collaboration applications such as electronic messaging, instant messaging, forums etc, may be built where each element may be stored in different files and/or boxes to manage access by different groups.
  • Agents may use shared boxes (e.g. Agent Boxes 382) to share agent data on behalf of users or applications. Note that the use of a shared box for agent system data may be advantageous to keep remote services "blind" from activities of agents and/or from interfering with the co-ordination and/or other system information exchanges between agents.
  • shared boxes e.g. Agent Boxes 382
  • the agent may store the meta-data (e.g. Meta-data 403) in a shared box (e.g. Shared Box 402) and/or in an associated box such as a meta-data box (e.g. Shadow Box 404).
  • the shared box or the meta-data box may be organised into "slots" and/or a queue, for example, one for each user. This may be useful, for example, to manage concurrent writes by multiple users, to allow versioning of permits, to distribute client or managed-user credentials especially with multiple privileged members or delegated administrators etc.
  • the agent may manage its own agent box. For example: the creation and management of passphrase-recovery box and/or a revocation-custodial box. A user may still invite/un- invite other trusted users, but the contents of the box(s) may be hidden from users and managed by the agent. (Further description about Keystore Passphrase Recovery and Credential Revocation Messages are covered below in the Credentials Layer section.) 3.2.6 Shared Content Management
  • Agents may use shared meta-data (e.g. Meta-data 403) to facilitate content management.
  • Meta-data 403 shared meta-data
  • Agents may facilitate search. For example, by storing and/or maintaining an index file, e.g. with keywords, for content they upload. Users within the box, may download such index files, decrypt them and use them to search for information within the box,
  • Agents may facilitate annotations, For example, by storing and/or maintaining an associated commentary file when they upload. Such annotations may be attached to files and/or recent actions and/or the box itself. Annotations may range from simple comments to more complex things, such as instructions and/or workflow commands.
  • Agents may facilitate versioning. For example, by storing and/or maintaining update histories when content is uploaded. This may be used so to manage multiple copies or co-ordinate activities on content.
  • Agents may facilitate locking. For example, by using a lock file to help manage concurrent editing of files.
  • Agents may facilitate read-receipts. For example, if agents use meta-data to sign-off that they have downloaded and/or read a given piece of content. This may be useful for applications that implement reliable-messaging and/or non-repudiation services.
  • Agents may facilitate distributed storage. For example, users may each choose their own remote service or storage provider for reasons such as geography, performance, service level agreements (SLAs), cost or other reasons.
  • users with their own storage services may have the restriction that only themselves can write to that storage service with others just having read-only access.
  • repository services may present a "box" as a logical view of the sum of shared information from each of the user's selected storage provider.
  • agents may need to co-operate such that if a user updates a file in their own area, the agent, responsible for the previous version of the file may need to delete it from that agent's own area.
  • Agents may facilitate navigation. For example, by presenting hierarchies of folders.
  • Agents may facilitate file recognition. For example, by storing visual representations of files and/or documents such as thumbnails, icons, labels and/or other attributes such as files size, type, application, keywords, privileges etc.
  • control layer 440 The purpose of a control layer may be to allow agent- to-agent interactions (e.g. Protocols 360). For example, to allow tasks to be securely and privately exchanged between agents and/or users and/or applications.
  • the control layer may be used to convey capabilities, keys, certificates, authorisations, Attribute Certificates (ACs), delegated privileges, permits etc.
  • the control layer may also enable decentralised management between agents such as key management, box management, box invitations, key recovery, box ownership changes etc.
  • control interactions may primarily be performed and managed client-side, such as by an agent(s) (e.g. Agent 340).
  • Agent may interact with other system services (e.g. Facility Services 390) and/or remote services (e.g. Remote Services 370).
  • the control layer may make use of message boxes (e.g . Message Boxes 383) and/or meta-data boxes (e.g. Shadow Box 404) for facilitating agent-to-agent interactions.
  • interaction between agents may be achieved via different means, such as via email, messaging, peer-to-peer or other transport systems.
  • the control layer may be secured using certificates exchanged in the trust layer (e.g. Trust Layer 460). In this way, agents may have a highly secure and private tunnel protected by asymmetric cryptography such as Public Key Cryptography (PKC) for communicating between each other.
  • PLC Public Key Cryptography
  • the control layer may also be called a channel, path, tunnel or private communications means.
  • the control layer may also be secured by other means, such as peer-to-peer, direct connections, SSL connection etc.
  • Applications may have their own control layer. For example, if the agent manages certificates in an operating system or application system certificate store (e.g. Certificate Store 314) then this may enable applications (e.g. Applications 312) with their own control layer and associated protocols and/or messaging system to communicate with other associated applications e.g. Secure/Multipurpose Internet Mail Extensions (S/MIME) for email, Extensible Messaging and Presence Protocol (XMPP) for collaboration, etc
  • S/MIME Secure/Multipurpose Internet Mail Extensions
  • XMPP Extensible Messaging and Presence Protocol
  • Control messages or "tasks" may be conveyed using a message box and/or task box and/or "contact" box (e.g. one of Message Boxes 383) and/or any other suitable messaging means.
  • a remote service e.g. * Remote Services 370
  • repository service e.g. Repository Services 391
  • the service may further restrict user's ability to read or write tasks, for example to only read/write to appropriate "slots" and/or a queue or write tasks to an appropriate out-box and/or read tasks from an appropriate in-box.
  • a pool for each user a given user may be the only one able to read or delete from their own pool, but may be able to write to any other pool.
  • pairs of contact boxes an in-box for one user may be the out-box for another user and vice versa for the corresponding contact box pair.
  • An agent may use any one or any combination of means to write tasks to a contact box.
  • the agent might directly write to the remote service (e.g. Remote Services 370) and/or write via a repository service (e.g. Repository Services 391 ).
  • a notify service e.g. one of Repository Services 391
  • Remote services and/or repository services may ensure that access by users is only for their particular in-box. For example: by using SSL mutual authentication.
  • Contact boxes e.g. Message Boxes 383
  • Tasks may be signed, for example using the registrar private key of the sending user.
  • the receiving user may check the signature, for example, against the registrar certificate of the sending user.
  • the receiving user may also check for revocation of the sending user, for example using a revocation service (e.g. part of Certificate Services 392).
  • Tasks may be encrypted. Encryption may use an encryption credential of the intended recipient or Password Based Encryption (PBE). Encryption may use a transitory wrapping key.
  • PBE Password Based Encryption
  • a conceptual area for sharing information may be known as a workspace or shared box (e.g. Shared Box 402).
  • a user and/or application via their agent who creates the workspace may be known as the owner (e.g. User 441 ).
  • An owner may invite other people (e.g. User2 451 ) to the workspace using an "invitation" process.
  • keys for example the creation of keys when a workspace is created, the transference of keys on invitation, the rotating of keys on un-invite etc.
  • keys may be unique and/or symmetric keys.
  • the owner may perform one or any combination of the following:
  • a permit e.g. Permit 442
  • the permit contains the box key or because the permit contains a map or other mechanism from which the box key may be derived.
  • meta-data box e.g. Shadow Box 404
  • meta-data e.g. Meta-data 403
  • the owner may invite the second user to the box by sending them a box key and/or permit and/or community key, for example contained in an invite task (e.g. Invite Task 405).
  • the invite task may be signed (e.g. Sign 446) such as with the user's registrar private key (e.g. one of Private Keys 482).
  • the task may be encrypted (e.g. Encrypt 447) such as using an encryption certificate from the second user (e.g. one of Contact Certificates 462).
  • the task may be encrypted via a wrapping key.
  • the encrypted task may be uploaded to a contact box (e.g. Contact Box 408).
  • the repository service may notify the recipient (e.g. User2 302, User2 451 ) that an item is in their contact box.
  • the recipient user and/or application may use an associated agent to download the invite task from the remote or storage service and extract its contents.
  • the recipient's agent may use a repository service (e.g . Repository Services 391 ) to obtain the location and other necessary information for accessing the remote or storage service.
  • a repository service e.g . Repository Services 391
  • the recipient's agent may decrypt (e.g. Decrypt 457) the invite task, for example using their encryption private key (e.g. one of Private Keys 492), to obtain the community key (e.g. Community Key 455) and/or the permit (e.g. Permit 442), for example, using the recipient's encryption private key (e.g. One of Private Keys 492). This may involve decrypting a wrapping key and then using the wrapping key to decrypt the task. If the task is signed, then the recipient's agent may check the signature and/or revocation status (e.g. Check 456). The_ signature may be checked using a signing certificate (e.g. one of Contact Certificates 472) of the sender. Revocation may be checked using a certificate service (e.g. Certificate Services 392) for example via OCSP.
  • a signing certificate e.g. one of Contact Certificates 472
  • Revocation may be checked using a certificate service (e.g. Certificate Services 392) for example via OCSP.
  • the recipient's agent may store the box key and/or community key and/or permit in their home box (e.g. Home Box 412), preferably encrypted, such as with the recipient's personal encryption certificate (e.g. one of Personal Certificates 493) and/or via a home-box key.
  • their home box e.g. Home Box 412
  • the recipient's personal encryption certificate e.g. one of Personal Certificates 493
  • a "community” may represent the set of users and/or applications (e.g. A, B and C) sharing one or more resources (e.g. in Shared Box 402).
  • the owner e.g. A
  • the owner may have distributed community keys (e.g. Community Key 445) or permits (e.g. Permit 442) to the other users (e.g. B and C). If the owner needs to "un-invite” a user (e.g. B) then since they can't "take back" the community key or box key, then a new key may be needed so that all future encryptions are safe from the un-invited user. Generating the new key and distributing it may be known as key rotation.
  • the community key (e.g. Community Key 445) may be used to encrypt (e.g. Encrypt 426) content. If the community key is rotated, then this may require the re-encryption of previously stored content.
  • another layer of keys may be introduced such as a "permit" which may be encrypted.
  • a permit e.g . Permit 442
  • a permit may contain one or more box keys used to encrypt the content.
  • a new box key may also be created and added to the permit.
  • new content may be encrypted with the latest box key and/or old content may be decrypted using previous box keys.
  • a user may "un-invite" themselves from a box (leave the box) in which case they inform the owner and the owner rolls over the box keys i.e. distributes new keys/permits to the other users.
  • a permit may be used to obtain keys necessary to decrypt shared data. Keys may be directly stored in a permit and/or may be indirectly stored using a random map from which the keys can be derived. Storing multiple keys in a permit may be advantageous if box keys are rotated as having a history and/or version of box keys may avoid having to re-encrypt keys used to encrypt existing content Using a random map may be advantageous to provide key material, for example if the end system has difficulty generating cryptographically strong random numbers.
  • Permits may be distributed to other users associated with a shared box directly via contact boxes and/or indirectly via a shared location.
  • a shared location e.g. Shadow Box 404
  • the owner may store the permit and/or other relevant box information as metadata (e.g . Meta-data 403).
  • the meta-data may be signed (e.g. Sign 443) such as with the owner's registrar private key (e.g. one of Private Keys 482).
  • the meta-data may be encrypted (e.g. Encrypt 444) such as using the community key and/or using a wrapping key and/or using a certificate (e.g. Certificates 462).
  • the encrypted meta-data may be uploaded to the shared box (e.g. Shared Box 402) and/or to a meta-data box (e.g. Shadow Box 404).
  • a recipient may retrieve a permit and/or other relevant box information from a contact box (e.g.
  • the recipient may be able to decrypt (e.g. Decrypt 454) the task that contains the permit, via a wrapping key if used, and may check (e.g. Check 453) the signature for validity and/or revocation.
  • An agent may discard permits that are no-longer in use, such as associated with a deleted box or a box the user no-longer has access to such as being uninvited.
  • the trigger to remove a permit may be a task from another agent and/or a message from a repository service (e.g. Repository Services 391).
  • a sequence of tasks may form a transaction,
  • a transaction may have an end message, for example, a confirmation message or declined message.
  • transactions should be recoverable. For example a missing message needs to be re-stored or an extra message may be safely deleted (cleaned-up). In this way, transactions may have an idempotent property.
  • a completed transaction may be indicated by a confirmation message.
  • a lone confirmation message may be cleaned-up.
  • a transaction may be aborted using a declined message.
  • a declined message indicates that the other user no longer wishes to participate in a conversation. These can arrive at any time and should result in the originating user removing whatever message was declined from their out-box, A lone declined message may be cleaned-up.
  • Transactions may be at the trust layer (e.g. Trust Layer 460) and/or the control layer (e.g. Control Layer 440). 3.3.7 Decentralised Management
  • Transactions may allow agents to perform decentralised management. This is because transactions, together with end-to-end encryption " , may allow agents to interact in a peer-oriented manner with little, if any, participation in the management activity from intermediate services.
  • transactions may be single step, two steps, multi-step, or complex.
  • Examples of single step transactions include:
  • Client Update - A sends Client Update (with permit, credentials) to B
  • Certificate Update - A sends Certificate Update (with certificates) to B [0321 ]
  • Examples of two-step transactions include:
  • Examples of complex transactions include:
  • key management may be centralised, such as in a key server.
  • a key server there may be one or many administrators who have significant power and/or control over the operation of the key server and/or the management of the keys.
  • This centralised power may have many, and sometimes severe, associated security risks and impact the level of privacy of users.
  • decentralised key management may be achieved by realising that agents themselves can be an authority of keys. This is because agents may perform most key management processing client-side in a decentralised fashion, especially the generation, distribution, and rollover of keys.
  • an agent may extend transactions and/or perform other relevant processing in order to provide decentralised key management. For example, any one or any combination of the following may be performed:
  • Collections of keys may be maintained.
  • a collection of box keys may be known as a permit.
  • previous box keys may be included in the permit so that data encrypted using the old box keys can still be decrypted.
  • the box key may be rotated and added to a new permit which is then distributed to the remaining members.
  • invites and un- invite may only be issued by the owner. However, the owner may delegate invite and/or un-invite privileges to other members in that box. Also, a user may be able to un-invite themselves e.g. by requesting an un- invite to the owner.
  • box keys may be rotated for each box they were a part of. This may involve each owner and/or delegated administrator and/or privileged member distributing new permits and/or community key to other users in each box that the revoked user is no longer a part of.
  • Keys may have a lifetime, for example defined by policy. If keys exceed this lifetime then they may be rotated. Triggers for rotation may include time since created, time since last used, number of uses, location, changes in delegation, detection of duress etc.
  • any member of a box may be allowed to re-invite back the owner.
  • sub-box messages may be encrypted with a temporary key, which may be included in the initial make contact message
  • Multiple invites may be sent to a user who has not yet registered or has not yet accepted a contact request.
  • an additional key may be included in the make contact message and used to encrypt any invites that were made after the initial make contact request, but before it has been responded to.
  • Content may be made available before distributing keys. That is, the distribution or publishing of keys, for example a permit, may occur after content has been made available. This may be for applications that need to synchronise the access of material at the same time, for example exams, tenders, entertainment etc.
  • Permits may be discarded when no longer required. This may involve deleting a permit from a user's home box. For example, if a user is uninvited from a box, the user voluntarily leaves a box, if a box is deleted etc.
  • the trigger for removing a permit may be a task from another agent and/or a message from a repository service.
  • certificate management may be centralised, such as in a PKI or corporate infrastructure. In this case, there may be one or many administrators who have relatively significant power and/or control over the life-cycle of certificates and/or associated infrastructure such as a user directory. This centralised power may pose significant security risks and/or may reduce the level of privacy of users.
  • decentralised certificate management may be achieved by realising that agents themselves can be an authority for the life-cycle of certificates. This is because most of the life-cycle of certificates may be performed client-side, especially the obtaining, distribution, and renewal of certificates. As such, agents may treat their own certificates as private certificates and choose to only distribute them as required to trusted contacts.
  • the centralised role of certificate services e.g. Certificate Services 392
  • Certificate Services 392 may be largely reduced to signing certificates and providing a revocation facility.
  • an agent may extend transactions and/or perform other relevant processing in order to provide decentralised certificate life-cycle management. For example, any one or any combination of the following may be performed:
  • Signing certificates may be sent along with any message, task or confirmation, for example, in case signing certificates are in the process of being renewed.
  • messages are signed using a registrar credential.
  • Data or messages may contain multiple signatures, for example, if certificates are being renewed or rolled over. Thus, a receiver may need to check for any signature that matches any appropriate certificate that it possesses and/or were contained in the data or message.
  • Certificate Updates may be initiated (pushed) to multiple agents. For example, if rolling over certificate(s) in the case they've been renewed or refreshing certificates in the case an agent wants to ensure contacts have the latest certificates.
  • the process of Certificate Update task may involve sending certificate(s) to one or more or all contacts that the agent has.
  • the Certificate Update task may include more than one certificate, for example, signing, encryption, email, and/or registrar certificates.
  • Certificate Updates may be requested (pulled) by agents, especially if the agent suspects that it does not have the latest certificate(s) from another agent. For example, in the case that an agent receives a task for which it does not have a certificate which can validate any of the signatures, As another example, if the signature used to verify a message had a lower serial number than the highest one actually used in the message.
  • an agent may store the new certificates in their home box.
  • the agent may first check that the certificate update is, in fact, newer than that which is already stored, for example, by checking issuer and serial numbers and/or issuance dates. The check may be based on information in the associated registrar certificate.
  • the information written to the home box may be in an encrypted form, for example, by using the agent's encryption certificate or home box key.
  • a privileged user invites a user to a box to which the owner has not directly made contact with
  • an exchange of certificates between the owner and the invited user may occur e.g. via the delegated administrator and/or privileged member passing between the owner and/or invited user the other's certificates and/or triggering, such as via a message, to one or both of the owner and/or invited user the need to exchange certificates.
  • a change owner transaction may have additional checks, such as to check that the target party is in the box and has direct contacts with each of the people in the box. This may be to ensure that the new owner has appropriate certificates for users of the box.
  • the Certificate Update task may be signed using the expiring registrar certificate.
  • the signing provides the new credentials with their "cryptographic provenance"
  • the agent may replace the old certificate(s) with the corresponding new ones in its list of contacts and/or store them in its home box.
  • the Certification Signing Request may be signed by the box owner or delegated administrator's or privileged member's registrar certificate. • If an owner endorsed a temporary SSL certificate of a member using an attribute certificate and the member is subsequently un-invited then the owner may revoke the attribute certificate, for example, by advising an OCSP server.
  • client credentials need to be created, then the owner or delegated administrator or privileged member creating the client may use their registrar credentials to sign the certificate request.
  • the number of certificates requested may be less than that required for a full user, for example, it may not be necessary to request a registrar and/or email certificate for a client or managed-user.
  • client certificates need to be renewed , then the owner or delegated administrator or privileged member may distribute the new credentials (pairs of private key and renewed certificate) to the other parent box users e.g. directly or via a meta box, and/or leave a message in the client's home box indicating that new credentials are available. After login, the client may then read the new credentials, save them to credential backup and/or delete the old credentials.
  • client's box may be deleted or marked as deleted.
  • client may be revoked which may involve and/or cause any associated boxes to be deleted, such as their home box and/or their credential backup box, as well as any associated authorisations.
  • a delayed invitation may involve a double check on confirmation that a user really wants to invite them to a passphrase-recovery box and/or a revocation-custodial box.
  • access management may be centralised, such as being enforced in an operating system and/or application.
  • access policies consist of Access Control Lists (ACLs) defining "who" has access to "what”.
  • ACLs Access Control Lists
  • this centralised approach may have significant security and/or privacy risks, for example because of the potential for administrators to abuse such power, the concentration of power as a target for attackers, the possibility of administrators making mistakes etc,
  • decentralised access management may be achieved by realising that agents can protect data (the "what") using encryption and control access through the distribution of keys (the “who”). This is possible because agents may perform encryption and key management client-side without being subservient to any intermediate service.
  • access management may be divided into two parts:
  • a "macro" access requirement being the access to groups of encrypted blobs (boxes) in a remote service. Note that this access control may be governed by repository services.
  • an agent may extend transactions and/or perform other relevant processing in order to provide "macro" related access management. For example, any one or any combination of the following may be performed :
  • SSL access may be automatically given to the owner
  • the owner's agent may advise the repository service and/or remote service to grant the invited user SSL access to the box.
  • the acceptance of the confirmation may be manual and/or be set to a given time.
  • invitations may become a three step process: the invite, the acceptance and the confirmation. This may be used to synchronise many members into a box at once. For example, to invite a set of people to a box, an agent or user may wait for acceptances, then confirm the acceptances at the same time. Since the confirmation may involve advising repository and/or remote services to grant SSL access to the box, this process effectively opens up access to a box at the same time to all invitees.
  • SSL access may be blocked in some or all of the system services and/or remote services.
  • associated home boxes and contact boxes may be deleted. This box deletion may occur via the revocation service and/or associated certificate service instructing the repository service and/or remote service.
  • the box owner's agent may advise the repository service to deny SSL access to the box for the un-invited user.
  • the Registration Authority may check with the repository service that the requestor is a member of the associated box.
  • a change owner transaction may pass additional data, such as box access codes being enforced by a repository service and/or remote service.
  • access to a particular home box and/or particular tagged information may be access controlled.
  • Such access controls may be defined in a policy.
  • Conditions for access may include location, tokens, time of day, time since last access, device, authorisation token etc. For example, access may be restricted according to country. 3,3, 1 1 Recovery Management
  • recovery management may be centralised, such as empowering centralised administrators to override user controls, reset passwords, issue new keys etc. This may have management costs and/or security and privacy risks, as most, if not all, support problems may become the responsibility of the central group with such power.
  • decentralised recovery management may be achieved by realising that agents may take special precautions to facilitate recovery themselves, without necessarily involving any centralised party. For example: making agent protocols omnipotent, adding extra information to transactions to detect inconsistencies, ensuring redundancy of keys via distributing a copy to each authorised user, backing up information for example in their home box, etc.
  • an agent may extend transactions and/or perform other relevant processing in order to provide decentralised recovery management. For example, any one or any combination of the following may be performed:
  • the confirmation message may include a hash of the permit or key data If the receiver finds that the hash of the confirmed permit does not match the current permit then the transaction may be repeated or aborted.
  • a key transference e.g. a permit
  • Codes may include contact codes, invitation codes, change-owner codes etc If a code is found in a home box, then associated messages may be expected to be found in the contact box for the recipient. If these are not found, then appropriate action may be taken such as to restart or abort the transaction.
  • a user in a parent box may reset their client permit by using the client credentials to read the client permit out of the client's home box or an associated meta-box. This may occur if an agent needed to ensure that they have the latest client permit.
  • the server-side oriented service providers may make privacy a concern. This is because centralised administrators may have the power to access user information and/or a service provider may make use of user data for its own commercial purposes.
  • the service provider, or associated partners may sell, track, archive, backup, aggregate, resell, correlate, target and/or otherwise take advantage of end-user information.
  • service providers may have a "privacy policy", these may be non-binding, voluntary, hard to verify, and/or diluted by service provider Terms of Service which may claim a right to use or access user data for any purpose that the service provider deems necessary to run their service.
  • decentralised privacy management may be achieved by realising that agents, with the use of encryption and protected agent-to-agent transactions, may have considerable scope to ensure that intermediate parties are effectively "blind” to activities occurring between agents.
  • agents may limit information and/or interactions with other agents to further strengthen privacy.
  • an agent may extend transactions and/or perform other relevant processing in order to enhance privacy. For example, any one or any combination of the following may be performed:
  • a target user may decline a contact by simply ignoring it. In this way, the target user may hide from another user their existence in the system.
  • An invitee may decline an invite by simply ignoring it. In this way, an invitee may hide from another user whether or not they are active in the system.
  • Profile information may be voluntarily passed between users. This allows users to have the option of what personal information, if any, should be conveyed to another user e.g. name, phone numbers, location etc.
  • Filenames in the remote service may be obfuscated to avoid leaking information and/or giving any indication about the contents of the encrypted content.
  • Revocation messages may not need to give details of who is being revoked. All that may be required in a revocation message may be the issuer and serial numbers of revoked certificate(s).
  • decentralised provisioning management may be achieved by realising that agents themselves can be an administrator for other agents. This is because agents may manage credentials on behalf of other users and agents may manage boxes on behalf of other users.
  • a managed-user may be able to access a sub-box under a shared box, called a "client" box.
  • Client boxes are especially useful for companies as they may allow staff invited to a parent box to be able to view and/or manage any of the subordinate client boxes.
  • Client boxes may also useful for experienced users as it allows them to quickly setup and/or manage boxes on behalf of other users, Note that any member of a parent box may be able to read and/or write to client boxes but a given client may only be able to read and/or write to their own client box,
  • an agent may implement extended interaction protocols and/or perform other relevant processing in order to provide decentralised administration of managed-users. For example, any one or any combination of the following may be performed:
  • a box owner, or delegated administrator or privileged member may provision a client by generating their credentials and/or creating a client box.
  • Generating credentials may involve generating a key pair(s), obtaining certificate(s) and storing them in a credential-backup box and/or a credential backup service.
  • the box owner may then give the name and passphrase used for credential backup to the client.
  • the Registration Authority may check that the email address conforms to predetermined criteria, such as a sub domain and/or an identifier for the parent box, and/or that the requestor is an owner, or delegated administrator or privileged member, of the parent box.
  • predetermined criteria such as a sub domain and/or an identifier for the parent box, and/or that the requestor is an owner, or delegated administrator or privileged member, of the parent box.
  • CSR Certificate Signing Request
  • Clients may automatically be invited to their client boxes. This may occur by storing the client box permit in the client's home box.
  • Shared client boxes may be managed in a similar way to client boxes.
  • a client may be assigned to a client shared box by copying the client shared box permit into to the client's home box.
  • a shared client box may be restricted to selected clients, for example by using tags or groups or manual assignment.
  • An all-client shared box may automatically assign clients to that ail-client shared box.
  • Members of parent boxes may automatically be invited to client boxes when client boxes are created and/or when a user is invited to a parent box with existing client-boxes associated with it. This is because members may obtain client permits by accessing the client's home box. Similarly, members of parent boxes may also automatically be invited to client shared boxes.
  • SSL credentials used on login such as to a repository service and/or remote service, identifies them and therefore may determine which boxes they may access.
  • a client may use a different interface to access boxes with, such as a private portal. This may avoid clients needing to maintain their own credentials locally; instead they may be retrieved via credential backup on each login.
  • Credentials of client boxes may be distributed to other members of the parent box. This may allow those members to reset a client's passphrase.
  • the box owner or other authorised box member(s) may connect to credential backup using the client's SSL certificate, store the credentials with a new passphrase, and then give the new passphrase to the client.
  • a client may reset their passphrase, similar to any other user, by simply storing their credentials in credential backup. Note that a parent box member may never know this new passphrase as their reset passphrase procedure uses the client's SSL certificate for authentication and not the client's old passphrase. Additionally, the credential backup service may never know the passphrase as the credential backup service may use a derived passphrase.
  • a parent box member may ensure that they have the correct client permit by reading it from the client's home box. Note that to do so, the parent box member may need to connect to the remote service and/or repository service using the SSL certificate of the client.
  • client users may not be invited or un-invited to other boxes, they may not need to have contact boxes. Note that the invite and/or un-invite to shared client boxes may be handled by directly writing to, or removing permits from, their home box.
  • Client permits may be placed in parent boxes or an associated meta-box. This is to cater for the case where a delegated administrator or privileged member doesn't have direct contact with other box users so therefore cannot pass on the credentials to those users.
  • a client-permit-key may be generated and stored in the parent box permit and used to encrypt client permits. This has advantages such as increasing scalability by reducing the number of contact box messages, reducing the risk of race-conditions between different delegated administrators or privileged members, reducing the number of asymmetric-key operations (used in contact box messages), etc.
  • Administrative functions may generally be performed by the box owner. However, it may be useful for a box owner to be able to delegate administrative privileges to other users in their box. Examples of privileges or permissions may include any one or any combination of; • Allowing users to invite other users to the box. Note that this privilege may involve passing certificates of the new user back to the box owner.
  • the enforcement may require co-operation by a system service, such as a repository service and/or remote service.
  • a box owner may send a message to the system service indicating any changes in authorisation by any of the users in their box.
  • the box owner may supply members with appropriate Attribute Certificates (ACs) for their privileges.
  • ACs Attribute Certificates
  • users wishing to exercise privileges may need to supply the appropriate AC at the time that the privilege or permission is needed .
  • Attribute Certificates may be used for privileges or permissions.
  • a repository service may verify an SSL certificate for a session on connection, and ensure that an appropriate AC is provided for each privilege required on that session.
  • the ACs may be provided at connect time and/or provided at the time of a request.
  • Privileges may be granted via a member, for example by the owner, generating an appropriate AC signed by their registrar credential (private key).
  • the AC may be short lived which may avoid the need for revocation support.
  • An AC may be tied to a transaction, for example via a hash.
  • a standard X.509 AC format may be used , for example, by making use of the "Holder" field.
  • the user may issue an AC to a recipient, for example via their contact box.
  • the AC may cover any permission, such as, to invite a user to a box, allow creation of clients, read a file, write a file, delete a file, rename a file etc.
  • the AC may be single use, such as to download a file only once.
  • the repository may enforce privileges by only allowing operations granted by an appropriate AC.
  • ACs may be issued by an agent or external attribute certificate server (e.g. Certificate Services 392) or a third party PKI. Attribute certificates may be revoked, for example, using an OCSP service. Note that such a revocation service may be a convenience and differs from a regular CA in that attribute certificates may be signed by user credentials such as their registrar private key, not a CA key, so the central location is just to provide somewhere where revocation messages may be stored. A reason for making use of a revocation service may be so that an attribute certificate could be disabled for example, when a user is un-invited from and/or leaves a box. In addition, or as an alternative, ACs may have short life, for example weeks or days or hours or any other time period.
  • central servers e.g. Remote Services 370 and/or Repository Services 391
  • central servers may not need to maintain an authorisation list.
  • the server may base its access decision based on a cryptographic authorisation such as an AC, rather than checking that the requesting user is allowed to perform an operation based on a server authorisation list.
  • a box owner may generate an AC signed using their registrar private key and may reference the SSL certificate of the target user.
  • the AC may be sent to the target user via their contact box.
  • the target user wants to create a client, it would send the AC to the server.
  • the server may perform a number of checks, For example, any one or any combination of the following may be checked:
  • the AC is valid e.g. not expired or not revoked
  • the AC references the target user, for example, the SSL certificate of the target user.
  • Box ownership may be handled by simply associating a box with a particular registrar certificate.
  • privileges may be recognised only if an AC is signed by the owner's registrar credentials (private key).
  • Revocation may be handled by using a standard form e.g. V2Form, and include the X.500 issuer name and/or serial number which may allow the use of OCSP to confirm the AC issuer is valid and/or the AC itself is valid.
  • V2Form a standard form e.g. V2Form
  • ACs may be used to handle most, if not all, system management permissions, e.g . read/write/delete permission(s), delegation of ' invite(s), box membership, etc. This means that central servers may not need to maintain a permissions database or any state information about users of a box as the rights of an SSL session may be governed by reference to the ACs provided on that session.
  • a combination of attribute certificates (ACs) and SSL, or equivalent, certificates may be used to facilitate anonymity.
  • ACs attribute certificates
  • SSL Secure Sockets Layer
  • certificates may be used to facilitate anonymity.
  • a user's security domain may be further protected as, not only may it be difficult, if not impossible, for intermediate parties to read a user's data, but it may become difficult, if not impossible, for intermediate parties to tell who a user is collaborating with.
  • the box creation step may associate an owner's registrar certificate with a box.
  • intermediate services e.g. repository services and/or remote services, may only accept requests from sessions that have an appropriate AC, signed by the owner's registrar credential, which references the SSL certificate of the current session.
  • an owner may issue multiple ACs to authorise one or more SSL certificates for use by a member.
  • a member may provide one or more SSL certificates, such as from a temporary certificate server (e.g. one of Certificate Services 392) which the owner could endorse using an AC.
  • a temporary certificate server e.g. one of Certificate Services 392
  • Such an SSL certificate could then be used to connect to the intermediate services, thereby disguising who is the real user, especially if the label in the SSL certificate was untraceable, such as a random number or random string, This randomness may facilitate anonymity as the intermediate infrastructure may only see random, but authorised, SSL sessions performing actions.
  • ownership may not necessarily be associated with a single user.
  • the concept of an "owner" is someone who can un-invite any other user but can't be uninvited themselves.
  • a change owner process uses an agent protocol, for example between a box owner and a box member (as described above).
  • repository services may re-assign a box to a new owner. This re-assignment may check that the new owner has contact with each box member.
  • a box-to-box copy may be used which may involve encrypted content being copied to a new box along with a re-encrypted content key from the box owner.
  • a trust layer (e.g. Trust Layer 460) may be for end users to establish bilateral relationships with other users and/or for agents to exchange certificates. Exchanging certificates may be important for securing the control layer (e.g. Control Layer 440).
  • trust management may primarily be performed and controlled client- side, such as by an agent (e.g. Agent 340). In this way, the trust management (also called relationship management or identity management) may be considered decentralised. Further, agents may treat their own certificates as private certificates and only distribute them as required to trusted contacts. The exchange of certificates may be encrypted to protect from man-in-the-middle attacks and/or to help maintain privacy of the certificates.
  • trust management may be obtained via different means, such as leveraging existing corporate, PKI and/or WoT systems.
  • first user e.g. Userl 301 , Userl 441
  • second user e.g. User2 302, User2 451
  • the two users may each have their own credentials.
  • the first user may have credentials comprising private keys (e.g. Private Keys 482) and associated personal certificates (e.g. Personal Certificates 483) which may be stored in a keystore (e.g. Keystore 481 ).
  • the second user may have credentials comprising private keys (e.g. Private Keys 492) and associated personal certificates (e.g. Personal Certificates 493) which may be stored in a second keystore (e g. Keystore 491 ).
  • the process of establishing a trusted relationship may involve the verification of identity of people and/or the authenticity of end systems. This process may also be known as a make contact process, a relationship establishment process, an introduction process, a vetting process, a proof-of-identity process etc.
  • a vetting process e.g. Vetting 303
  • the process of establishing a relationship may be one-way or both-ways or multi-way in the case of many users. It may involve the first user verifying the identity of the second user and/or the second user verifying the identity of the first user.
  • the verification process may involve the first user giving a contact code (e.g. Contact Code 461 ) to the second user (e.g. Contact Code 471 ).
  • the contact code may be generated by the first user's agent and/or chosen by the first user.
  • the contact code may be thought of as a bootstrap key because it enables the encryption and decryption of the initial contact message.
  • the contact code may be conveyed using out-of-bands means.
  • the out-of- bands means may help establish proof-of-identity, verification, validation or other assurances that the parties are who they say they are.
  • the out-of-band means may use any method, for example in person, over the telephone, via SMS, via email, via file transfer, via instant messaging, using physical means such as in person, etc.
  • the process of vetting may involve a first application establishing the authenticity of a second application and vice versa. This may be done manually be machine administrators, such as with a contact code and/or an automated means such as using configuration or other predetermined criteria.
  • the process of establishing a bilateral relationship may involve the exchange of certificates.
  • the purpose of exchanging certificates may be to provide a cryptographically strong control layer (e.g. Control Layer 440) also called a control path, plane, channel or tunnel with other users or applications.
  • a cryptographically strong control layer e.g. Control Layer 440
  • Control Layer 440 also called a control path, plane, channel or tunnel with other users or applications.
  • Such an exchange may include more than one personal certificate (e.g. Personal Certificates 483) by the first user requesting the relationship and/or a second user accepting the relationship request (e.g. Personal Certificates 493).
  • a personal certificate e.g. Personal Certificates 483
  • an encryption certificate, a content signing certificate, and/or a system signing certificate e.g. registrar certificate
  • the registrar certificate may be used to check the signing of control messages, certificate requests, renewal of certificates, a revocation message etc.
  • the exchange of certificates may make use of contact boxes or equivalent such as message boxes or control boxes.
  • a contact box between the first user and the second user may be created (e.g. Contact Box 408).
  • a contact box between the second user and the first user may be created (e.g. Contact Box 410).
  • the agent associated with each user may utilise repository services (e.g. Repository Services 391 ) and/or remote services (e.g. Message Boxes 383).
  • the exchange of certificates may be obtained via other means, such as email, instant messaging, a "cloud” messaging service, a “cloud” queuing service, a USB device, a direct connection or any other physical or electronic transport means.
  • the first user may create a make contact task (MCT) (e.g. Make Contact Task 407).
  • MCT may be signed (e.g. Sign 464) for example using the first user's registrar private key (one of Private Keys 483).
  • the MCT may be encrypted (e.g. Encrypt 463) using a contact code (e.g. Contact Code 461 ) as the encryption key.
  • the contact code may be any code, password, passphrase, number, known certificate or any other type of key.
  • the encryption may involve a wrapping key.
  • the MCT may be conveyed to the second user, for example via a contact box (e.g. Contact Box 408) or other means such as email.
  • a contact box may be created, for example using a repository service (e.g. Repository Services 391 ) and/or remote services (e.g. Remote Services 370) Note, at this point, the second user may not yet have credentials.
  • the second user may receive a notification (e.g. from Repository Services 391 ) inviting them to register in order to gain credentials (e.g. Private Keys 492 and Personal Certificates 493).
  • the second user may obtain their personal credentials via other means e.g. leveraging an already existing credential infrastructure.
  • the second user may retrieve the MCT (e.g. Make Contact Task 407) from their contact box (e.g. Contact Box 408) and decrypt it (e.g. Decrypt 473) using a contact code (e.g . Contact Code 471 ) provided by the first user.
  • the decryption may involve a wrapping key.
  • the decryption may make use of one or more personal certificates (e.g. Personal Certificates 483) from the first user.
  • the second user may add the first user's certificates to their list of known contacts (e.g. Contact Certificates 472).
  • the second user may check (e.g . Check 474) the signature of the MCT, for example using the registrar certificate of the first user.
  • the second user may also check for revocation of the first user, for example using a revocation service (e.g. part of Certificate Services 392).
  • the second user may also store the first user's certificate(s) in their home box (e.g. Home Box 412), preferably encrypted (e.g. Encrypt 494) with their encryption certificate (e.g. part of their Personal Certificates 493).
  • the second user may accept the make contact request by returning an accept contact task (ACT) (e.g. Accept Contact Task 409) which may contain one or more personal certificates (e.g. Personal Certificates 493) of the second user.
  • the second user may sign (e.g. Sign 476) the ACT, for example using their registrar private key (e.g. one of Private Keys 492).
  • the second user may encrypt (e.g. Encrypt 475) the ACT using a certificate such as an encryption certificate provided by the first user (e.g. part of Contact Certificates 472).
  • the encryption may involve a wrapping key.
  • the ACT may be transferred back the first user via message box (e.g. Contact Box 410) which may be part of a remote service other messaging means e.g. email.
  • a contact box may be created, for example using a repository service (e.g. Repository Services 391 ) and/or remote services (e.g. Remote Services 370).
  • the first user may retrieve the ACT and decrypt it (e.g. Decrypt 465) using a private key (e.g. one of Private Keys 482) such as the private key associated with their encryption certificate.
  • the decryption may involve a wrapping key.
  • the first user may retrieve one or many personal certificates (e.g. Personal Certificates 493) from the second user.
  • the first user may add these certificates to their list of known contacts (e.g. Contact Certificates 462).
  • the first user may also store the certificate(s) in their home box (e.g. Home Box 41 1 ), preferably encrypted (e.g. Encrypt 484), such as using their encryption certificate (e.g. part of their Personal Certificates 483) and/or via a home-box key.
  • the first user may check (e.g. Check 466) the digital signature using a signing certificate of the second user associated (e.g, part of Contacts 462).
  • the first user may also check for revocation of the second user, for example using a revocation service (e.g. part of Certificate Services 392).
  • the first user may send an acknowledgement to the second user via their outgoing contact box (e.g. Contact Box 408) and/or delete the MCT from their outgoing contact box.
  • the acknowledgement may be signed and/or encrypted.
  • the second user may receive the acknowledgment and/or is notified about the removal of the MCT from the contact box as a signal of confirmation and delete the ACT from their outgoing contact box (e.g. Contact Box 410). If the second user receives an acknowledgement task, the second user may decrypt it and check its signature in a similar way to the methods described above.
  • a MCT may be declined with a specific message.
  • a MCT may have a limited lifespan and may be deleted after it has timed out. This may be useful for privacy reasons as a target user may wish to ignore a MCT without betraying the fact that they exist and/or are actually in the system.
  • the make contact process/protocol may be extended to carrying control messages.
  • a MCT may include one or more invitations to a box. This may allow a new user to be invited to a box as soon as they have registered, they can gain access to the box without the need for the owner to be available to issue the invite after registration (as previously described).
  • the make contact process may be communicated using external means, such as email, instant messaging, message queues, physical means or any other suitable transport mechanism.
  • message boxes e.g. Contact Box 408, Contact Box 410
  • a remote service e.g. Remote Services 370
  • the message boxes may be used as contact boxes (e.g. Contact Box 408).
  • Credentials Layer 480 may be for users and/or applications and/or agents to obtain and manage credentials, preferably certificate based credentials. Credentials may be required for different purposes, for example, signing, encryption, certificate management and/or communications. Communications certificates e.g. Secure Socket Layer (SSL) certificates may be required to access facility services (e.g. Facility Services 390) and/or remote services (e.g. Remote Services 370).
  • facility services e.g. Facility Services 390
  • remote services e.g. Remote Services 370
  • credential management may primarily be performed and controlled client-side, such as by an agent (e.g. Agent 340).
  • Agent may interact with other system services (e.g. Facility Services 390) and/or remote services (e.g. Remote Services 370).
  • credentials may be obtained via different means, such as integration with corporate identity systems, PKIs or any other identity management system, preferably that manages certificate based credentials.
  • the credentials of users may be strong credentials, such as certificate based credentials, and/or may be stored securely in a keystore (e.g. Agent Data 331 ).
  • Credentials may include keys and/or certificates for different purposes, for example signing, encryption, communications, email and/or certificate management. The combination of a private key and certificate may be considered a credential. If such personal certificates are not generally published then they may be considered as private certificates.
  • Credentials may be obtained via a registration process or enrolment process and may make use of system services (e.g. Facility Services 390). Alternatively, credentials may be obtained by leveraging or importing them from a third party system(s).
  • system services e.g. Facility Services 390.
  • credentials may be obtained by leveraging or importing them from a third party system(s).
  • Credentials may be obtained via certificate services (e.g. Certificate Services 392) which may comprise a Certification Authority (CA) and/or a Registration Authority (RA). Credentials may also be obtained via external means, such as being issued on a smart card. Users (e.g. Userl 301 and User2 302), may obtain credentials from different CAs. Note that it is not necessary for certificate credentials of different users to be related, compatible or in the same format. Thus, certificate credentials may be mixed and/or be in different forms and/or signed by different authorities and/or self-signed. Preferably, certificates are in X.509 format.
  • Credentials may include private keys (e.g. Private Keys 482) and/or personal certificates (e.g. Personal Certificates 483).
  • Each user e.g. Userl 301
  • agent e.g. Agent 340
  • a key pair may be a private key and the other may be a public key.
  • Each private key may be stored in the keystore.
  • a public key may be self-signed, signed by other trusted parties or sent to a Certification Authority (CA) for signing.
  • CA Certification Authority
  • the sending of a public key to a CA may be via a Certificate Signing Request (CSR) and the returning of a signed certificate may be in a Certificate Signing Response (CSRR).
  • CSR Certificate Signing Request
  • CSRR Certificate Signing Response
  • the CA may perform minimal name check or proof of identity, for example, a verification of the email address to be used in the issued certificate, to validate that the name is somehow related to the person or application requesting the certificate.
  • a CA or RA may require other information such as evidence of identity, a unique label such as an email address, and/or cryptographic information such as a random number, timestamp etc.
  • Initial name verification may involve the CA or RA giving the user an authorisation code.
  • a system signing certificate may be known as a registrar certificate. This may be the first certificate requested from the CA and it may be verified by an authorisation code. For example the authorisation code may be used to sign a CSR for a registrar certificate. Once the registrar certificate is obtained, then subsequent CSRs may be signed with the associated registrar private key. For example, a user may generate multiple key pairs in order to gain different certificates, and therefore credentials, e.g. to obtain signing, communications, encryption and/or email certificates.
  • Registrar credentials may have many other uses, For example: to sign Attribute Certificates (ACs) and/or for signing control messages sent between agents (e.g. in Control Layer 440) etc.
  • ACs Attribute Certificates
  • Control Layer 440 Control Layer 440
  • credentials may be stored securely in a keystore (e.g. Agent Data 331 ).
  • an agent e.g. Agent 340
  • may create a state or home box e.g. Home Box 41 1 for Userl 441
  • a repository service e.g. Repository Services 391
  • a remote service e.g. Agent Boxes 382.
  • a CA may be involved in other procedures to do with the lifecycle of certificates such as re-issuance, renewal etc. Note, however, that the agent may take responsibility for the lifecycle management of certificates, with the CA mainly forming the role of assistance, for example, certificate signing.
  • the CA may, under pre-determined conditions, accept a CSR signed by the expired registrar private key in order to obtain a new registrar certificate and subsequently other certificates. The agent may then need to distribute renewed certificates to existing contacts.
  • a credential backup service may be part of a facility service (e.g. Backup Services 393). Such a service may allow agents or users (e.g. Userl 301) or applications to retrieve credentials, for example, in the case they are lost or the user is using a different end system.
  • agents or users e.g. Userl 301
  • applications e.g. Userl 301
  • retrieve credentials for example, in the case they are lost or the user is using a different end system.
  • a credential backup service may require authenticated access such as a passphrase or client-side SSL authentication. If certificate-based credentials are required, the user may need to obtain a temporary SSL certificate, for example from a temporary access service provided by certificate services (e.g. Certificate Services 392).
  • certificate services e.g. Certificate Services 392.
  • an agent may authenticate to the credential backup service and provide data to the credential backup service.
  • Backed up data may be the raw credentials, encrypted credentials, a keystore, an encrypted keystore or any other derivation of credentials.
  • a protected keystore may be encrypted using password based encryption (PBE) using a derived password of the encrypted keystore passphrase.
  • PBE password based encryption
  • an agent may need to re- backup the keystore if the passphrase to the keystore is ever changed.
  • the agent may authenticate to the credential backup service. If the credentials or keystore are encrypted, the agent may decrypt them and/or store them locally.
  • a credential backup service may work in combination with other system services.
  • a credential backup service may return other information for an agent to gain access to system services, such as returning in a response any one or any combination of key(s), link(s), form(s), portal(s), portal link(s), web service(s), access detail(s), credential(s), temporary credential(s), token(s), etc.
  • Certificate revocation may be used to ensure validity of credentials.
  • Many prior art systems may not provide for revocation, or may only provide revocation in a cumbersome way, for example WoT systems.
  • Providing revocation, particularly timely revocation, is considered essential to handle the case that credentials are lost or compromised.
  • Certificate revocation may be invoked by end users or applications, such as via a revocation-custodial box.
  • the ability for end-users to get trusted custodians to invoke revocation may be far preferable to prior art systems that rely on central administrators who may be susceptible to social engineering attacks and other risks such as abuse of authority.
  • a certificate revocation service may be provided by one of the system services (e.g. Certificate Services 392). Such a service may act as a third party to allow a user or other service to determine if credentials have been revoked.
  • the interface to the certificate revocation service may be via an Online Certificate Status Protocol (OCSP).
  • Agents e.g. Agent 340
  • other system services e.g. Facility Services 390
  • remote services e.g. Remote Services 370
  • OCSP service such as on start-up, on authentication, at pre-defined intervals, whenever new data is accessed, whenever signatures are checked etc.
  • a user e.g. Userl 301
  • the trigger may be direct, for example by a certificate service notifying other system service and/or agents.
  • the trigger may be indirect, in that other systems and/or agents discover the revocation, for example via OCSP.
  • SSL access may be blocked in some or all of the facility services and/or remote services. In advanced embodiments, any existing SSL sessions of a revoked user may be terminated.
  • associated agent boxes and/or home boxes e.g. Agent Boxes 382
  • message boxes and/or contact boxes e.g. Message Boxes 383
  • associated item(s) in credential backup may be deleted, for example, on instruction from the revocation service and/or associated certificate service.
  • authorisation to associated boxes may be removed, for example owned boxes, invited boxes, client boxes, meta boxes etc.
  • agents When agents discover or are notified that a user has been revoked, those agents may rotate keys for any shared boxes they own and/or have been authorised as delegated administrators or privileged members . Rotated keys may include box keys and/or community keys. If ACs have been issued to the revoked user, then the agent may advise a revocation service to revoke those ACs. Agents may also delete messages sent to that user, for example unacknowledged messages in their outbound contact box for the revoked user.
  • An encrypted emergency passphrase may be used to handle the possibility of a user (e.g. Userl 301 ) forgetting their passphrase which is protecting their keystore (e.g. n Agent Store 330).
  • a user e.g. Userl 301
  • agent e.g. Agent 340
  • PRC Passphrase Recovery Code
  • EPB Encrypted Passphrase Blob
  • the EPB may be stored locally alongside the keystore and/or with other agent data (e.g. Agent Store 330) and or in any manner accessible by the agent or end user.
  • agent data e.g. Agent Store 330
  • the EPB may be portable, e.g. on a USB device.
  • An agent may disable keystore recovery management if an EPB can't be created, such as if the storage area containing the keystore is read-only, or the agent was enabled via remote credentials such as from credential backup.
  • the PRC may be given directly to a second user (e.g. User2 302) and/or stored in a passphrase-recovery-box (e.g. Agent Boxes 382) and/or stored in a passphrase assistance service (e.g. Backup Services 393).
  • a passphrase-recovery-box e.g. Agent Boxes 382
  • a passphrase assistance service e.g. Backup Services 393
  • the advantage of a passphrase-recovery-box is that it allows the owner to invite and un-invite trusted users to that box as required.
  • the advantage of a credential assistance service is that the PRC may be automatically sent to the user, such as via one or more emails and/or SMS, for example via a "Forgot Passphrase" function associated with the agent.
  • Users given access to a PRC may be considered trusted or custodians of the PRC. For example, a custodial user might be a reseller, or another member of staff in an office.
  • a user e.g. Userl 301
  • they may use a passphrase assistance service and/or contact one of the custodial users that they have given access to their PRC.
  • the custodial user may provide the PRC back to the forgetting user. This may be done over the phone, via a message or any other means.
  • the PRC may be cryptographically strong and single use and so therefore may be safe to send over untrusted communication channels, e.g. email(s) and/or SMS.
  • the forgetting user via their agent (e.g. Agent 340) then may use the PRC to decrypt the EPB to obtain the passphrase to unlock their keystore.
  • the agent after successfully opening the keystore via the PRC , may require the forgetting user to choose a new passphrase. In this case, a new PRC and EPB may be generated. If a passphrase-recovery-box is being used, then the PRC may be stored in that box. If the credential backup has been performed , then the credentials may need to be backed up again using the new passphrase. If the PRC is being entrusted to other parties, such as a passphrase assistance service and/or trusted user and/or trusted organisation, then the new PRC needs to be provided to those parties.
  • EPB and PRC may be considered relatively safe. Abuse of the EPB may require physical access to the user's end system. Also, the PRC, being cryptographical!y strong and single use, may not leak information, unlike prior art password "hints" which may be considered to have very weak security.
  • An advantage of storing the PRC in a box is that an owner may control which users to trust and can change that choice, unlike in prior art systems which may require exclusive trust of the provider.
  • An advantage of using a passphrase assistance service is that it may be automated to send the PRC over one or more emails and/or SMS and/or other means. This approach may be considered relatively resistant to any attack on the PRC . For example, if any attacker obtains the PRC e.g. by intercepting email(s), by hacking a server etc. , they may not be able to do anything with it without physical access to the user's computer containing the EPB. Further protection may be used via a separate channel, for example sending the PRC via SMS or sending an encrypted PRC via email with the unlocking code sent by SMS. This recovery process may be unlike prior art whereby password reset links are relatively susceptible to attacks because there is no client-side protection.
  • a revocation message may be used to handle the possibility of a user's credentials being no longer safe. For example, because they lost their computer (e.g. End System 305), or they suspect their computer has been compromised (e.g. malware), or they suspect that their keystore passphrase is no longer secret or they have forgotten their passphrase and did not use a PRC.
  • RM revocation message
  • a user may generate a RM and sign it using their registrar credential (private key) and/or make use of a revocation passphrase (e.g. as defined in RFC 4310).
  • the RM may be given directly to a second user (e.g. User2 302) and/or stored in a box, such as a revocation-custodial box (e.g. one of Agent Boxes 382) which allows the owner to invite and un-invite trusted users to that box as required.
  • Users given access to a RM may be considered trusted or custodians of the RM.
  • a custodial user might be a reseller, or another member if staff in an office.
  • the user may contact one of the custodial users that they have given access to their RM.
  • the custodial user may then send the RM to a revocation service (e.g. part of Certificate Services 392).
  • a significant advantage of storing the RM in a box which they control access to is that a user can choose who to trust and can change that choice, unlike in prior art systems which may need to trust the service provider exclusively.
  • a user may have multiple devices, for example a desktop computer and one or more mobile devices.
  • the desktop computer may be the primary credential holder, for example the user's registrar certificate
  • a mobile device has its own embedded credentials, for example SSL certificates, or equivalent then these may be used to connect to the system, for example remote services and/or repository services.
  • the system may need to recognise the trust anchor (TA) of the mobile device. The user may then issue the device an AC authorising the use of the device's SSL certificate.
  • TA trust anchor
  • a mobile device may generate or request SSL certificates, for example from a temporary certificate service (e.g. part of Certificate Services 392) and pass the credentials to the mobile device. If the user generates SSL certificates, then the certificate path may be sufficient for the system to accept the SSL certificate. If a certificate server is used, then the user may issue the device an AC for the supplied SSL credentials.
  • SSL certificates for example from a temporary certificate service (e.g. part of Certificate Services 392)
  • the mobile device may advise an OCSP server to revoke the SSL certificate and/or ACs. If embedded SSL credentials are used then an external OCSP server may be notified. Note that the OCSP server may accept the revocation request because it was signed by the same registrar credential that issued the SSL certificate and/or the AC .
  • SSL certificates may not necessarily be tied to a user, they may be tied to the device.
  • Embodiments of the present invention may have many advantages and benefits. This may result from a number of realisations and/or insights by the inventors which may be different from prior art.
  • Applications include Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (laaS).
  • Derivatives include derived passwords and/or password based encryption (PBE) techniques. This approach may be considered insufficient if strong security and/or privacy is required.
  • P2P - Peer-to-Peer approaches tend to be application specific (e.g. instant messaging) and/or require real-time connections. This approach relies on the resources of end systems and is therefore unable to leverage "cloud” benefits such as availability, vast storage, low cost etc,
  • WoT - Web of Trust systems tend to use decentralisation to avoid authority and/or intermediate parties. However, this may result in very poor handling of revocation, certificate update etc.
  • Attempts to make WoT work in the wider internet have generally had difficulty with scale and complexity.
  • PKI - Public Key Infrastructures tend to work well in closed communities, but have problems scaling because of authoritarian, inflexible and/or centralised nature of most implementations. In general, PKI's have not been successful in the wider internet because of difficulties to do with complexity, manual processes, jurisdiction and cost.
  • Embodiments of the present invention stem from the realisation that client-side techniques, in combination with ideas from the above approaches, may result in benefits, such as strong security, privacy, trust, control etc. with, relatively few of the limitations of prior art approaches. In particular, protecting data at the source with encryption based on strong cryptographic keys and mutual/compartmentalised trust between users.
  • Client-side encryption may have benefits compared to server-side approaches. Encryption may encase, armour, lock-down the end-user data at the source making it relatively immune to problems with server security intermediate between source and destination, for example being stored, cached, transferred, routed etc. Essentia) to utilising client-side encryption is to solve the (universal) problem of key management. Note that server-side encryption has little additional security benefit as server-side keys have mostly the same risks as server-side infrastructure. Key management may have complexity, cost and challenges including key generation, storage, duplication, distribution, access, protection, rollover, rotation, recovery, removal, revocation etc. If public/private key cryptography is used to help distribute keys, then there may be additional problems of managing certificates, governance, issuance, proof-of-identity, renewal etc.
  • Client-side capabilities to ensure end-to-end interactions, mostly independent of intermediate infrastructure.
  • Cloud storage to leverage availability, low cost, scalability and other benefits.
  • P2P management - by using relatively autonomous and co-operating agents to enable decentralised management.
  • Data-centric security may make data essentially "host-proof”, “location-proof” and “third-party-proof”.
  • Strong control - as keys may be generated and/or managed and/or distributed by the owner of the data.
  • This may facilitate pseudonymity as users may just need to be known to each other via a (bilaterally recognised) label (such as an email address for convenience).
  • a label such as an email address for convenience.
  • This approach may be quite different from PKIs and WoTs which may go to great lengths to prove that an identity (label) has meaning.
  • this approach may allow intermediate servers and/or providers to be relatively "blind" to who is collaborating and what is being exchanged.
  • Authentication may be user-to-user verified (not user-to-system verified). Each end user only has to convince themselves, for example via the contact and/or vetting process, that the other party is providing certificates that represent them (and not because a third party said so).
  • Authorisation may be user-to-user (not user to system or central policy driven).
  • Sharing may be based on a decision by the owner about "fit-for-purpose". For example, the owner may make a decision about whether a given label, such as an email address, (personally verified) should be allowed to access information (by virtue of distributing them a key) at this point in time (a trusted contact, not revoked).
  • a given label such as an email address, (personally verified) should be allowed to access information (by virtue of distributing them a key) at this point in time (a trusted contact, not revoked).
  • An aspect of embodiments of the present invention stems from the realisation that many security, privacy, trust, control and integrity problems in systems may be better managed using a layered approach.
  • the Sharing Layer may handle "content” keys.
  • individual resources or content may be encrypted with their own key (e.g. Wrap 425).
  • the purpose is to protect the security and privacy of the content from any intermediate party.
  • the Control Layer may handle "shared" keys. In this layer sets of resources or content may be accessed with a shared key (e.g. Permit 442, Community Key 445). The purpose is to protect and compartmentalise content being shared by a set of users.
  • a shared key e.g. Permit 442, Community Key 445. The purpose is to protect and compartmentalise content being shared by a set of users.
  • the Trust Layer may handle "public” keys. In this layer the distribution of certificates is managed. The purpose is to protect the control layer (or channel or tunnel) being used between two or more collaborating users. Note that "public" keys may be stored in a "private" certificate.
  • the Credentials Layer may handle "private" keys.
  • credentials may be obtained by each user.
  • each public/private key pair is generated client-side, such as via an agent, and that the private credentials are protected by the user, such as using a keystore (e.g. Keystore 481 ).
  • keystore e.g. Keystore 481
  • the purpose of this layer is manage strong credentials and this enable the full benefits of asymmetric cryptography to be used e.g. digital signatures, encryption, authenticity, revocation, key management etc.
  • agents may be responsible for the full lifecycle management of keys including their generation and distribution. For example, when box keys are rolled over on un-invite, or certificates are rolled over when near expiry etc.
  • the Sharing Layer may define a user's "community".
  • a user may have a very explicit trusted community which may be exactly equal to the set of contacts that the user has chosen to make contact with Note that this community may be completely user defined and not, as is the case in prior art, defined, influenced, adjusted or otherwise interfered with by any third party, especially organisations.
  • the Control Layer may define each "workgroup" that a user belongs to.
  • a user may collaborate with a very explicit set of people.
  • each workgroup may be very exactly defined , e.g. by the members of a box, and not, as is the case in prior art, defined, influenced, adjusted or otherwise interfered with by any third party, especially administrators.
  • the Trust Layer may define each "relationship" that a user has. Such relationships may be bi-lateral and/or via mutual consent, preferably involving out- of-band means of verification and/or proof-of-identity. Note that relationships may be precisely determined by the user, and not, as is the case in prior art, be defined, influenced, adjusted or otherwise interfered with by any third party, especially trusted third parties.
  • the Credentials Layer may define a "personal" footprint of a user. This may allow a user to project themselves as they see fit, for example, whether real names or pseudonyms are used, how much personal data is distributed, what type of persona to portray, etc. Note that a user's personal profile may be completely voluntary, and not, as is the case in prior art, determined , measured, implied, embellished or otherwise publicised or influenced by any third party.
  • a communications layer may be added which enables communications such as voice, video, chat, telephone, VOIP, messaging etc.
  • User Re-establishment may be the process by which a user, who has lost their credentials, re-establishes themselves back into the system. Note that, in embodiments of the present invention, if a user is revoked then their access may be removed in many ways, for example:
  • SSL access may be revoked from all facility services (e.g. Facility Services 390) and/or remote services (e.g. Remote Services 370).
  • facility services e.g. Facility Services 390
  • remote services e.g. Remote Services 370
  • Owned system boxes e.g. contact boxes, home boxes, passphrase-recovery boxes, credential backup boxes etc.
  • Authorisation to associated boxes may be removed in repository services and/or remote services, for example owned boxes, invited boxes, client boxes, meta boxes etc.
  • re-establishing a user after the loss of credentials may be more successfully achieved by realising that there may be different types of reinstatement and/or that reinstatement may require a multi-part approach, as follows:
  • revocation is via a trusted contact who has released a Revocation Message to the revocation service (e .g. part of Certificate Services 392).
  • the re- registration may follow the same checks by the certificate services as was performed originally during the initial registration process. After re-registering and obtaining a new set of credentials, the user may need to create a new home box. Note that this may be important because an attacker who manages to impersonate another user e.g. by somehow getting them revoked and somehow re-registering as them, say, using a compromised email account, may only gain SSL access to facility services, but at this point, may not have any other keys or capabilities necessary to communicate with other users or access any encrypted messages, meta-data nor content.
  • the re-registering user may need to re-establish trust relationships with other users. This may follow the bilateral vetting and exchange of certificates (as described above). Note that an attacker who manages to impersonate another user may only be able to access a victim's data after convincing some or all of the victim's contacts of their authenticity, which may be difficult, if not impossible, as it involves out-of-band, usually personal, vetting or verification.
  • the re-registering user may need to be re-invited to each of the boxes they previously had access to. This further makes the task of an attacker difficult, because now the attacker needs to convince each data owner to invite them back into a box. Or, in the case of owned boxes, an attacker must be able to convince a member of the box to invite them back as an owner. Even if an attacker manages to impersonate someone and colludes with another party, each workspace is strictly compartmentalised and so the attacker and colluder may only result in the attacker gaining access to boxes the colluder owns or is a part of, which may be no worse than the colluder simply providing information to the attacker in the first place.
  • the re-registering user may need to use the latest box keys in order to . access the content of a box. If keys were rotated or rolled-over, especially if content keys were re-encrypted using the new box keys, then this may close another path of an attacker e.g. a user which previously was trusted, but who went rogue and kept previous box keys, those previous keys may have become useless. 4.2.4 Access Layering
  • the Sharing Layer may be considered as a "matrix" or "N:M” layer, In this layer, any number of users may store shared data in a box (e.g. Shared Box 402), and any number of users may retrieve data. The result is a matrix of possible interactions. Storing of shared data may be through repository services, via repository assistance, such as via an authentication token to remote services, or directly to the remote seivice by the agent.
  • the Control Layer may be considered a "broadcast” or "1 :M” layer.
  • an authoritative person usually the data owner and/or box owner, may transfer data via a box to other users.
  • a common box may be used (e.g. Shadow Box 404).
  • multiple messages, each encrypted with a different key may be sent via message boxes (e.g. Contact Box 408) .
  • Storing of broadcast data may be separate from the storing of shared data, for example, broadcast data may be stored in a repository service (e.g. Repository Services 391 ) whilst shared data is stored in remote services (e.g. Remote Services 370).
  • the Trust Layer may be considered as a cryptographically secure channel or "tunnel" or "1 : 1 " layer. In this layer, interactions may be solely between two parties.
  • a tunnel may be uni-directional such as with contact boxes.
  • the mechanism may be an external messaging means (e.g. email, instant messaging etc.) and/or an internal messaging means (e.g. a messaging service part of Repository Services 391 ) or via storage means (e.g. Remote Services 370).
  • the Credentials Layer may be considered a "personal" or "1 :0" layer. Information in this layer may be for the exclusive use of a user and/or their agent. Storage may be local (e.g. Agent Store 330), which may, for security reasons, be portable such as on a USB drive. Storage may be remote (e.g. Home Box 41 1 ) which may be stored using a backup service (e.g . one of Backup Services 393) and/or via remote services (e.g. Remote Services 370).
  • a backup service e.g . one of Backup Services 393
  • remote services e.g. Remote Services 370
  • client-side encryption may protect data from non-authorised parties including any intermediate provider of storage or collaboration services. This may be different from prior art which may depend on a whole range of server-side security measures such as network controls, system controls, administrator controls, operational controls etc Essentially, client-side encryption may provide "data-centric” security and privacy rather than prior art that may rely on controls that are “infrastructure-centric”. This may also be known as “self-protecting” or “self-defending” data.
  • Certificate-based credentials and/or public-key cryptography may be used in order to protect user-to-user interactions via intermediate transport or storage means.
  • PKC public-key cryptography
  • the use of PKC allows for the use of end-to-end encryption for confidentiality, digital signatures for integrity and authenticity and/or the ability to use keys for sharing without requiring the sharing of passwords.
  • end-to-end encryption keeps data safe whilst it is stored and/or travelling between intermediate systems, Thus, even if there are security problems with intermediate systems, the most an attacker may be able to obtain is encrypted data.
  • additional server security may also contribute to overall security by limiting server access e.g. access to authorised cipher text, access to particular permits and/or home boxes, access to system services, ensuring mandatory escrow etc. Such an approach may introduce additional barriers to an attacker.
  • Client-side security may also be enhanced through the user of multiple keys and/or partial keys. In this case, the user may need to obtain multiple keys or multiple parts of keys in order to decrypt data.
  • Privacy of data may be enforced through end-to-end. This means that only end-systems with appropriate keys may be able to decrypt any end-user or application information. Intermediate storage or other "cloud” based ' service may only ever handle encrypted information. This "mandatory” enforcement may be considered different from prior art which may, at best, offer “voluntary” promises to honor their security and/or privacy policies. Mandatory enforcement using encryption may make content safe from server-side breaches or provider leakage including mishaps, internal abuse, external infiltration or service provider exploitation.
  • Privacy of identity may be enforced through the secret exchange of certificates. Secrecy may be ensured by encrypting certificates and avoiding any central source of certificates, such as a server, database, repository, website or directory. As such, personal certificates may be considered as private certificates and may be only distributed to trusted contacts.
  • This decentralised management may be important to allow each user or application to hide their existence from everyone except those who they explicitly choose to trust.
  • This "private" approach to certificates may be very different from prior art, which tends to make certificates “public” especially in (logically) centralised directories.
  • the encryption used when exchanging certificates may also serve to prove that the person sending the encrypted certificate is in possession of the matching private key.
  • Privacy of interactions may be enforced by generic encrypted blobs and generic boxes. This may make any data, whether user, agent or system information, relatively in indistinguishable from each other as well as make any relationships between boxes or users relatively difficult to deduce.
  • Privacy may be further enhance by using encrypted filenames.
  • Users via their agents, may completely control invitation, authorisation, and other management features on the client-side.
  • Management is peer-oriented and may be secured using end-to-end encryption, thereby not needing to rely on the honesty of any intermediate administrators.
  • embodiments of the present invention may form a peer-based overlay so that management is decentralised and client-side encryption used to protect both system data and user data. This means that server-side operators may be relatively "blind" to what is being transferred or shared between users and that intermediate administrators may be relatively powerless to interfere with policies and other management co-ordination between end-system agents.
  • decentralised management may use end-to-end encryption to protect management data using substantially the same mechanisms normally used to protect end-user data.
  • the techniques used for the end-to-end sharing of user data may be applied for the end-to-end transfer of management messages and/or security information such as keys, certificates and/or capabilities.
  • Partitioning may be enforced as keys may be unique, thereby able to completely and independently define groups of data being shared. This may be also known as compartmentalisation. It means that any break in the system may only affect the particular partition or data items encrypted with those keys. Further, this partitioning may allow compartmentalisation of data in many dimensions, for example different groups of users, different classification levels of data items e.g. sensitive, secret etc, different temporal controls such as making data available for a pre-determined time after which keys are rotated or rolled-over etc.
  • Rights may be enforced client-side by leaving information encrypted on the end-system. This may be known as “on-disk” encryption or “at-rest” encryption. Applications may then decrypt information "on-the-fly” as required. For example, using a special viewer or using a Virtual File System (e.g. VFS 313) may decrypt information in memory as required. This may enable policy based rights, for example, restricting and/or controlling copying, saving, printing, copy to clipboard, access times etc.
  • VFS 313 Virtual File System
  • Remote services e.g. Remote Services 370
  • facility services e.g. Facility Services 391
  • certificate-based credentials may be used for strong authentication. This strong authentication may be stronger than using simple authentication as is the case in most prior art, such as using name and password.
  • Strong authentication may use mutual authentication such as SSL or TLS (sometimes called client-authenticated SSL or two-way SSL). This may be stronger than "simple" SSL, which is normally used just for link encryption, as it additionally provides certificate-based client authentication.
  • the advantages of strong authentication may be many. For example, barriers to attackers may require strong credentials before even obtaining a connection, passphi ases are not transmitted "over the wire", intermediate passwords are not used or known by intermediate systems etc.
  • a further aspect of embodiments of the present invention stem from the realisation that a non-real-time peer-based system can be achieved using end-to-end encryption and intermediate storage.
  • a key which encrypts a set of content in effect is its own universe and completely independent, isolated, insulated and/or compartmentalised from any other key and that key's associated encrypted content.
  • control may be enabled via direct connections to end-systems. Whilst this achieves control independent from interference by any third parties, it relies on the availability and resources of end-systems, which may be inappropriate for general desktop systems, mobile devices or systems behind company firewalls.
  • control may be exercised by end systems, with overriding control nearly always with centralised administrators of the service provider.
  • control is typically implemented using access control rules, for example using Access Control Lists (ACLs), enforced by computer systems such as operating systems and/or applications.
  • ACLs Access Control Lists
  • the system(s) uses the access control rules to decide whether access requests from (authenticated) users should be approved (granted) or disapproved (rejected).
  • Access to user data may be enforced via an agent controlling the distribution of appropriate keys and need not, as is the case with prior art, be reliant on the enforcement of sharing controls by intermediate parties e.g. the providers of storage and/or collaboration services. This may mean that server-side operators are relatively powerless to access information themselves or change access rules to data as they may have no means to obtain or control the distribution of keys, [0480] This approach may be known as "capability-based" controls as the possession of an appropriate key is all that is required to have the capability to access encrypted information. In contrast, prior systems may require careful definition and control of ACLs, also known as security policies, and strong enforcement by associated operating systems and/or applications.
  • ACLs also known as security policies, and strong enforcement by associated operating systems and/or applications.
  • Access to system data may be enforced via an agent controlling the distribution of administration keys and need not, as is the case in prior art, be reliant on centralised administrators.
  • such administrators may be a problem as they may have elevated privileges necessary to operate systems, particularly server-side systems, and therefore the capacity to abuse those privileges.
  • Authorization may equally apply to machines and/or programs as it does to people, using the same technique of distributing keys to authorised entities.
  • the access management may be more powerful because the keys may convey the rights to invoke services, participate in distributed processing or otherwise be involved in multiparty and/or multi-location and/or multi-disciplined processing.
  • keys may be used to mediate access to a service bus, peripherals, partner systems or any other federated system.
  • remote services e.g. Remote Services 370
  • facility services e.g. Facility Services 391
  • ACs attribute certificates
  • ACs may allow the box owner to effectively sign off on privileges being exercised by delegated administrators or privileged members, for example "invite user” or "create client”.
  • a further aspect of embodiments of the present invention stem from the realisation that end-users may have the absolute choice as to who they trust and for what, rather than, as is the case in prior art, needing to mostly trust nearly every aspect of a service provided by a Trusted Third Party (TTP).
  • TTP Trusted Third Party
  • Trust may be very tightly controlled. This is because trust is established via the mutual exchange of certificates between consenting users on an "as needed” basis. Trust may be easily terminated, simply by discarding the other party's certificate.
  • trust may be relatively encompassing as the exchange of certificates may be relatively independent of technology. This is because exchanged certificates need not necessarily be related, associated or compatible. This means that embodiments of the present invention may work with multiple PKI's and or WoT systems simultaneously without the need for CA cross certification, border CAs or trust translation mechanisms by third parties.
  • TTPs Trusted Third Parties
  • PKIs Public Key Infrastructures
  • WoT Web of Trust
  • a "protocol" may be used to establish bilateral trusted relationships which may include the encrypted exchange of certificates. This may make use of an out-of-band verification between a first user and a second user. This verification process may enable a vetting process for example to establish proof of identity. It may also facilitate a communication protocol between the first and the second user with the use of a contact code. The code may be used as part of an introduction message or introduction request to encrypt part of the communications and may make use of an underlying remote service. An introduction acceptance may use the certificate of the first user to encrypt the response by the second user.
  • a benefit of the approach may be to allow the certificate exchange to be relatively automated, without the need to rely and/or trust a third party.
  • An introduction process may result in a highly secure and private "tunnel" between users, for example, to share information, to exchange system information and/or to control interactions between applications.
  • the bilateral exchange may use encrypted certificates to ensure the privacy of trusted relationships during their establishment and/or the restricting of certificate distribution to exactly those who a given user chooses to explicitly trust.
  • a further complication with WoT systems is that if a user is revoked then this may affect and/or collapse trust calculations for all users for which the revoking user had counter signed.
  • the trust layer e.g. Trust Layer 460
  • Credential Layer 480 may be relatively independent from the credential layer (e.g. Credential Layer 480).
  • the establishment of trust may be performed via the make contact process and may not involve a TTP nor be dependent on TTP(s) to verify the public key/certificate.
  • the separation of credentials from trust may assist anonymity and/or privacy, unlike prior art systems which may set rules relating to activities and relationships allowed by users.
  • a box owner may issue one or more attribute certificates (ACs), including to himself, which may endorse the use of an SSL, or equivalent, certificate.
  • ACs attribute certificates
  • the SSL certificate is temporary and/or random, then this may be used to hide from intermediate parties who is performing what activity in any given box. All that intermediate parties may determine, for example using traffic analysis, is that a set of labels, for example random numbers, are uploading and downloading files. Because all information is end-to-end encrypted, intermediate parties may not be able to determine which files are user content and which files are system messages, for example, granting of privileges etc.
  • activity may be further obfuscated if a user makes use of multiple SSL certificates. In this case, a given user may have many authorised SSL certificates and can use any combination to disperse their activity.
  • trust domains may be relatively explicit and/or precisely controlled and/or defined. This may be considered to be different from prior art where trust domains may be implicit and/or pre-defined and/or out of the control of end users because prior art relies on trusted third parties.
  • a trust domain may be the scope of the CA and may be as broad as the total community of issued certificates of that PKI, thereby encompassing users for which a given user may have no direct relationship with.
  • the trust boundary may be fuzzy, as trust levels may be ambiguous and/or manual for each endorser (e.g. complete trust, marginal trust, no trust) and trust calculations may rely on chains of trust involving users with which a given user may have no direct relationship.
  • trust domains may be explicit, being equal to the set of people who a user has successfully made contact with or in the context of a box. This is because trust is established via bilateral relationships such as using the make contact (or introduction) process and is not necessarily reliant on any third party. These bilateral relationships may have the effect that an end user can setup their own "trust domain" with the boundary being exactly defined by those that they have exchanged certificates with. This trust boundary is effectively chosen and/or defined and/or controlled by the end user and need not be defined, extended and/or limited by one or more third parties.
  • the trust layer may be used to establish relationships through a direct contact or introduction process and may involve the exchange of certificates. These certificates need not necessarily be related, compatible, associated or in a predefined format or part of a single system. In embodiments of the present invention certificates and/or signed public keys from any one or any combination of different and/or disparate systems may be used.
  • the underlying trust model of any given system is a foundation for the security of that system.
  • the trust model tends to be controlled by TTPs.
  • the trust model may be decentralised and may be controlled by the end-user and/or application. A number of examples follow.
  • Users may control who they trust by following through on the make contact process. Note that a first user need not be highly concerned about the details in a certificate offered by a second user. This is because the certificates mainly serve the purpose of securing an identifiable channel between two users. Thus a user may only need to be confident that the other party has a corresponding private key which they keep private. In prior art systems, users may have no choice but to accept the rules of trust imposed on them by a provider.
  • Users may control who is a custodian to help them recover their passphrase.
  • users may have no choice but to rely on the provider for recovering or resetting passwords.
  • Users may control who is a custodian with the capability to revoke them in the event that credentials are lost or become compromised. In prior art systems, users may have no choice but to rely on the provider to correctly revoke them when required and not be susceptible into being tricked by an attacker into revoking them, for example, via a social engineering attack.
  • Users may control who to share information with by creating a box and inviting other users to that box. If some information needs to be shared with a different set or subset of users, than the data owner may create another box and invite the different set of users. Thus user trust is in context to the information being shared. Highly sensitive information may involve only inviting highly trusted users.
  • Organisations may control the accessibility of decryption keys by requiring key escrow by their staff and/or customers.
  • the encryption facility is strongly managed by the organisation and independent from any intermediate services.
  • Organisations may require this capability to insure themselves against staff losses or to safeguard contents of boxes being stored on behalf of customers, for example, a bank providing a virtual vault facility.
  • Governments may control the ability to access citizen's encrypted data by mandating key escrow.
  • a government may obtain access to a citizen's home box, preferably using a trust anchor recognised by the remote service and/or repository service, and then be able to decrypt keys and permits in a citizen's home box using the citizen's escrowed encryption key.
  • users subject to mandatory escrow may be completely compartmentalised away from other users. This is because all other boxes are insulated from imposing governments as these other boxes have nothing to do with escrowed keys
  • management and/or operations may be decentralised. Though central services may be required, the centralised role may be essentially limited to providing a record of where to look for data, signing certificates and providing a place to check if credentials have been revoked. Most other concerns of access management, control, and organisation may be distributed across relatively independent agents.
  • embodiments of the present invention may be decentralised by having solutions to a number of problems which prior art may claim to be a driver for a centralised approach. For example:
  • Decentralised Authorisation Management may define their own policies and control these policies through client-side management of keys and/or attribute certificates.
  • Decentralised Content Management - as agents may store meta-data associated with content in order to support features such as searching, versioning, concurrent editing, workflow, icons, file attributes etc.
  • Decentralised Certificate Management may distribute certificates as required and may manage the life cycle of certificates and/or signed public keys. Some assistance from a certificate signing service may be used.
  • Decentralised Credential Management may obtain and/or manage their own credentials not necessarily from a single authority.
  • box owners can manage credentials of client boxes or sub-boxes.
  • Decentralised Entitlements Management as the box owner is effectively signing off each change in access privileges though the invite/un-invite process and/or the issuance of attribute certificates.
  • Decentralised Identity Management as agents may perform their own vetting and authorisation as well as control relationships, groups and trust domains.
  • Decentralised Key Management may manage and distribute keys as required without assistance or interference from third parties.
  • Decentralised Provisioning Management - as agents may generate credentials and pass these to other agents, for example client boxes or devices.
  • Decentralised Privacy Management - as agents may collaborate with other parties without intermediate servers having any access to content, and/or use other privacy preserving mechanisms, such as innocuous email addresses, temporary SSL certificates and/or attribute certificates, to hide interactions and/or associations with other parties.
  • Decentralised Privilege Management may grant, on a peer basis, permissions for actions within a box, especially with the use of attribute certificates.
  • Decentralised Recovery Management as agents, after being revoked, may separately regain credentials, trust and/or capabilities
  • Decentralised Rights Management - as agents may make use of at-rest encryption and/or secure applications such as viewers or players to control what an end-user can or can't do with content.
  • Decentralised Role Management - as agents may control sets of privileges otherwise known as roles.
  • Decentralised Security Management as enforcement is data-centric rather than infrastructure centric and management is via autonomous, peer-oriented agents.
  • Decentralised Storage Management as anyone or any combination of storage services may be used and these storage services may be relatively simple.
  • Decentralised Trust Management as agents may perform their own vetting and group management and need not be reliant on any one or any combination of third parties for verification of trust.
  • "managed-users” may be provisioned and/or administered by agents (as previously described).
  • a box owner, or other member of the parent box which the box owner has given privileges to may manage the life-cycle of credentials of clients and/or their access to sub-boxes. Credentials may be created, reset and/or updated on behalf of clients and those credentials distributed to them, for example via credential backup (e.g. Backup Services 393).
  • Client boxes, including shared client boxes, may be created and access to them provided via the distribution of keys to those clients home box, for example by distributing client credentials to other users in the parent box.
  • An advantage of agents being able to provision managed-users is considered to simplify the use of the system by users who do not want or need to maintain their own credentials. For example: • Managed-users may simply interact with the system using a name and passphrase, relatively unaware that they are using strong credentials being maintained in credential backup.
  • Managed-users may be able to access the system using a private portal (further described below) which allows a website to provide a highly secure and private facility to clients without needing to open up their internal infrastructure to those clients.
  • a private portal further described below
  • Parent box owners, or other members of the parent box if given permission to do so, may reset a managed-user's passphrase. This may be a highly common activity as it is well known in the industry that a majority of support problems relate to forgotten passwords.
  • Users may themselves take precautions to safeguard their own credentials. Examples may include: using strong passphrases for keystores, protecting access to end systems or devices containing keystores, duplicating keystores and storing them elsewhere, using a PRC, using a credential backup service (e.g. part of Backup Services 393), using multiple accounts, making use of external authentication systems which host the credentials etc.
  • a credential backup service e.g. part of Backup Services 393
  • an agent may automatically and/or periodically prompt an end ' user to perform such safeguards, such as if the agent detects that the safeguards aren't in place or do not match a policy on safeguards. Examples may include:
  • remote credentials such as from a credential backup service
  • the remote credentials may be retrieved and remain in memory for the duration of a single session.
  • remote credentials may be preferable and/or necessary because the end-system is not able to store credentials locally and/or the end-system is less secure than the credential backup service.
  • Particular examples include:
  • a centralised authentication system such as a Virtual Private Network (VPN).
  • the credentials may be delivered using an authentication extension protocol such as Protected Access Credentials (PAC).
  • PAC Protected Access Credentials
  • Embodiments of the present invention may enable self-management. That is, management may be performed by agents without necessarily involving central administrators. Importantly, this self-management may be authoritative in that central administrators may have no means to influence, adjust, override or otherwise interfere with the way agents may manage aspects of embodiments of the present invention.
  • Examples of self-management may include:
  • Self-management may occur in combination with repository services. For example, box creation, box deletion, box ownership transfer, registration etc. Note that clean-up tasks may be driven by an agent and/or repository services. For example, if a box is deleted, the box and its content may be marked for deletion and then after a given time, the agent and/or repository services may delete and/or archive the deleted content
  • an aspect of provisioning is de-provisioning.
  • de- provisioning may be problematic, for example, having manual processes to ensure that when an employee's role changes that all appropriate permissions are removed or if an employee leaves, removing all appropriate permissions.
  • removing privileges may be performed by rotating or rolling-over keys and/or severing access may be performed via revocation. Advantages of the latter approach may be relatively complete and/or timely removal of privileges as well as this deprovisioning may be performed without requiring the assistance or instigation by central administrators.
  • agents may essentially be self- managing.
  • the amount of administration required by centralised services such as remote services and/or repository services, may be relatively small.
  • embodiments of the present invention may be pared down to a point where the only manual administration required may be to revoke users, and even this may be managed if individual users provide their own custodian or trusted users to manage their revocation.
  • a decentralised approach may remove many complexities. For example, prior art may require significant effort with membership management, including enrolment, privileges, group management etc, In particular, group management may be a relatively complex issue, e.g. because of the need to manage dynamic and/or conflicting requirements of groups which may be unpredictable, transient, complex, overlapping, disjoint, dormant, out-dated etc. In a decentralised approach end-users determine their own group scope, and/or may dynamically build groups in context of the sharing required at the time it is required via the distribution of keys.
  • Agents may be mobile and/or need credential portability.
  • their credentials and/or keystore and/or agent data may need to be portable and/or be backed-up remotely.
  • Portable credentials may mean storing such data on a portable memory device, USB drive or any other suitable storage device.
  • An agent e.g. Agent 340
  • Agent data may be stored locally (e.g. Agent Store 330) or remotely in an agent data box or "home" box (e.g. one of Agent Boxes 382) or via a hibernate service.
  • the agent may interact with a resource service (e.g. Repository Services 391 ) and/or a remote service (e.g. Remote Services 370) or hibernate service which is typically done at registration time.
  • Remotely storing agent data may have many advantages. For example:
  • Embodiments of the present invention may be highly scalable. This may be because most processing , computations, management etc is performed by the end- systems making the overall system highly distributed. Adding more end-systems is not necessarily dependent on the processing or administrative scaling of central servers . This may be unlike prior art in which central servers and/or central administration may become a bottleneck.
  • Processing requirements may be minimal for remote services as most processing is performed client-side e.g. cryptographic functions, compression, etc.
  • t Trust requirements may be minimal as the main function of remote services may be to store and return data correctly. Note that agents may be able to detect corrupted and/or compromised data via the use of digital signatures.
  • remote services may only store encrypted data making it valueless in the case of any security breach such as hacker attacks or malicious or accidental disclosure.
  • remote services may limit access to just the set of encrypted blobs that a user requires, for example, the set of encrypted content associated with each box that the user has access to,
  • Service requirements may be minimal as higher level services may be provided by a repository service e.g. notifications, billing etc.
  • Symmetric keys may be used wherever possible, including wrapping keys, so as to limit public key operations which may be relatively computationally expensive.
  • Embodiments of the present invention may have flexibility. This may result from the layered and/or modular approach to security, privacy, trust, control etc. A number of examples follow.
  • Different and/or multiple identity systems may be leveraged and/or incorporated.
  • the interface to corporate identity systems the leveraging of PKIs or WoTs etc. This flexibility may be because the use of credentials, particularly certificate-based credentials, may be relatively independent from other aspects of embodiments of the present invention.
  • Different and/or multiple cryptographic modules may be used. For example, use of a Hardware Security Module (HSM), use of a government certified cryptographic providers etc.
  • HSM Hardware Security Module
  • Encryptid content keys may be stored with content or separate from it; encrypted meta-data may be stored in the same shared box or in a separate (meta-data) box; community keys may directly encrypt content keys or may encrypt workspace keys which in turn are used to encrypt content keys etc.
  • a layered, iterative and/or decentralised approach may be taken to enhance safety and/or security.
  • Safety may be enhanced as each participant in a box has copies of keys to that box.
  • Security may be enhanced by separating the recovery of passphrase, the recovery of credentials, the recovery of certificates and the recovery of each set of box keys. Note that regaining credentials is not sufficient to regain previous access: in addition, it further requires obtaining copies of certificates and/or regaining access to each box. Regaining box keys is then dependent on re-establishing trust with the owner of the box, or a member in the case of a box-owner trying to regain their box.
  • recovery may be performed client-side using a relatively broad range of recovery options. This decentralised approach may give many advantages and benefits. Some examples are given below.
  • An aspect of embodiments of the present invention may be that if credentials are lost, they may be suitably re-instated (as previously described) in a way that allows the system to continue to function just as it had prior to revocation.
  • the reinstatement of credentials may use a process which may be relatively robust, which may not be subject to attacks such as social engineering, as may be the case in prior art (as previously described).
  • a PRC may be used to unlock a EPB in order to open the keystore.
  • the PRC may be provided externally by a passphrase-recovery-box, a trusted third party, a passphrase assistance service etc, whilst the EPB is stored locally on the end-user's machine along with the keystore and or in any manner accessible by the agent or user.
  • the recovery process may be extended to three-factor, for example by sending an encrypted PRC via one or more emails with the unlocking code sent via SMS or another email.
  • credentials may be revoked preferably via a custodian of a revocation message (RM).
  • RM revocation message
  • a user may need to re-register, then that user may need to follow procedures as if they only just joined the system. For example: re-eslablishing a home box, reestablishing trust relationships, re-establishing access to boxes etc.
  • a benefit of this approach is that it may avoid credentials being critical to system operation. For example, in embodiments of the present invention, encrypted data that is shared may be recovered from other parties.
  • an end system loses credentials, the credentials may be re-instated and access to previous information may be re-gained via the contact and invitation process, without involving central administrators. If a box owner loses credentials, then they may be re-instated by one or more of the people who the owner trusted with the data in the first place. [0550] If a user with end-system at-rest encryption loses credentials, then after re- invitation back to a box, the user may be able to recover the local encryption keys, such as from a shared box or home box, without involving central administrators.
  • a user may recover keys for any shared box, by simply getting re-invited back to that box by another box member. The user may be given back keys to that box during this process. Note that this process is the same for a box owner, in which case any of the members may invite the owner back and pass them back keys to that box.
  • the components might be any one or any combination of:
  • box-B Another box that the user owns and has members e.g. "box-B"
  • a special encrypted file containing the key to box-A stored in box-A e.g. "B(A)" may be the box-A key encrypted with the box-B key • A policy that allows access to box-A if the re-instated owner is invited back to one or more boxes
  • a re-instated owner may be part of the following process:
  • a user from box-B re-invites the owner back to box-B. This may provide the owner with the box-B key and/or trigger the policy to allow access to personal boxes
  • the special file may be encrypted with a user-chosen passphrase.
  • the special file may be in two or more parts with each part been encrypted using different box keys from different boxes. For example, if the special file was encrypted in two parts , then this may cryptographically enforce the need to get re- invited to the appropriate two boxes before being able to recover personal box keys.
  • the special file may be stored in a "personal-box-recovery" box, in which case, one of the owner's custodians would need to invite them back to the box in order to recover their personal box keys.
  • encrypted data may also be recovered via a key escrow service.
  • a government may mandate that keys are escrowed, a large corporation may mandate the escrowing of employee keys or an institution like a bank may use a key escrow as a safety measure to insure against customers losing their keys to a bank provided electronic vault.
  • key escrow would only involve the escrowing of encryption private keys.
  • the escrowing of signing private keys is considered not necessary and a security risk as any breach in security may result in obtaining signing keys which may subsequently allow impersonation of the real user.
  • escrowed keys are stored in systems with strong security, monitoring and auditing. Such systems should be independent and preferably logically, physically and administratively separate from remote services and/or repository services.
  • escrowed keys are stored encrypted by a computationally difficult means of obtaining them. This may make it difficult to steal a large number of keys, as decrypting a large number of escrow keys may require relatively large amounts of computing power.
  • access to an escrow server would involve legal and/or procedural constraints, such as needing a court order or signed military order, requiring multiple signatories and/or approvals etc.
  • access by officials to repository services should use temporary SSL keys using a separate trust anchor. This may,be so that the repository services can recognise an official accessing the system in order to obtain box keys from a user's home box. In this way, the repository can enforce strong authentication and restrictions such as read-only access, send notifications etc.
  • key escrow should only be used in extreme cases, such as for national security, criminal investigation or disaster recovery.
  • Embodiments of the present invention may be implemented in a relatively diverse range of application scenarios in order to provide enhanced security, privacy, control, trust and other end-to-end capabilities.
  • an agent may be used to facilitate peer-based management, data-centric security/privacy, strong cryptography, trusted communities, secure sharing, private collaboration, distributed processing etc.
  • data-centric encryption may provide self-enforcing, end-to-end, persistent security and privacy which may be in contrast to the server centric approach of prior art which may be hard to enforce, transient and/or point-to-point.
  • An advantage of embodiments of the present invention may be that agents may automatically distribute, update and/or remove certificates in end-system certificate stores in order enable certificate-based applications.
  • agents may be used to address the issuance, distribution and disabling problem that has traditionally been difficult in prior art: •
  • the certificate "issuance” problem may be addressed via the bilateral Make Contact process, not necessarily involving a third party.
  • This process may also be used for "machine-to-machine” trust, such as when multiple computing devices need to co-operate securely and/or privately.
  • the certificate "distribution" problem may be addressed via a "push" mechanism, again not necessarily involving a third party. At the agent level, this may involve distributing certificates to other agents, for example, during the Make Contact process and/or the Certificate Update process.
  • an agent When an agent receives certificates (e.g. Contact Certificates 462) , it may update local knowledge (e.g. Home Box 41 1 ) and/or update a local certificate store (e.g. Certificate Store 314) for use by the local operating system and/or local applications.
  • the certificate "disabling" problem may be addressed via messages sent to agents to remove certificates from certificate stores, for example if they are revoked, expire, become obsolete etc.
  • the management of a local certificate store may be in accordance to a predetermined policy For example, agents may initiate management actions based on user instigation, time of day, link stability, idle time, frequency, periods, time of day, on demand, certificate type, certificate expiry, revocation event etc.
  • the management of a local certificate store may be useful to a significant number of applications which may assume certificates in place in order to have their own control channels protected by asymmetric cryptography.
  • This local certificate management may include updating certificates when they need renewing, removing certificates when they expire and/or revoked, further distributing certificates to multiple device etc.
  • Email especially the most common form using Simple Mail Transfer Protocol (SMTP) may have poor security and privacy.
  • SMTP Simple Mail Transfer Protocol
  • the format is basically text and so may be viewable by any intermediate party.
  • Secure email may generally fall into two categories - a hosted solution which necessarily involves a trusted third party, or an end-to-end solution which may involve asymmetric cryptography.
  • the international standard for end-to-end email encryption is Secure/Multipurpose Internet Mail Extensions (S/MIME) which is built into most modern email software,
  • S/MIME lets users encrypt outgoing messages and attachments so that only intended recipients who have a certificate, can read them.
  • S/MIME allows users to digitally sign a message, which provides the recipients with a way to verify the identity of the sender and/or prove that the message hasn't been tampered with.
  • S/MIME In order for users to use end-to-end encryption, it is usually necessary to have certificates in place and/or for the users to manage these certificates.
  • S/MIME usually requires a PKI to be in place.
  • self-signed certificates such as Pretty Good Privacy (PGP)
  • PGP Pretty Good Privacy
  • users may have to manually manage the obtaining and maintenance of certificates on their end-system.
  • a further problem in prior-art may be the quality of certificates being used, as a user may not understand the appropriateness of certificates they receive.
  • Overall setting up end-to-end encrypted email may be a manual, arduous, complex, technical and/or relatively difficult process that requires end-users to have expert knowledge and thus is often cited as a major reason why S/MIME has not had widespread adoption .
  • the management of certificates may be managed by agents interfacing with local email applications and/or operating system functions. This may require agents interfacing to certificate databases which may be kept by the operating system and/or email specific software.
  • an agent in conjunction with a web browser plug-in may provide S/MIME capabilities. Making encrypted email available as a Web browser extension may make end-to-end authenticated and encrypted e-mail accessible to a much wider set of people.
  • S/MIME standards-based protocols
  • government-endorsed cryptography may help meet stringent regulatory requirements, such as eHealth laws, data privacy laws, payment card industry requirements etc,
  • CAs certification authorities
  • client-side cryptography may allow email integration into existing smartcards, USB tokens, and other cryptographic devices.
  • XMPP Extensible Messaging and Presence Protocol
  • IM instant messaging
  • multi-party chat forums
  • voice and video calls collaboration
  • lightweight middleware content syndication
  • gaming monitoring
  • geolocation geolocation
  • remote control systems generalized routing of XML data
  • an agent may manage XMPP certificates.
  • the interface between an XMPP client and an agent may include registering and obtaining certificates, exchanging XMPP certificates with other clients/applications, rolling over certificates, revoking a certificate etc.
  • An advantage of embodiments of the present invention is the ability to centrally store histories of those communications in a highly secure and private way.
  • P2P peer-to-peer
  • IM instant messaging
  • chat chat
  • forums voice calls
  • video calls etc
  • end systems to maintain logs and/or histories, which may have limited storage space and/or not suitable for long term reliable storage. This may be especially important for voice and/or video, which may generate significant amounts of data.
  • VFS these histories may be kept encrypted on the end-systems.
  • agents may keep synchronised an operating system certificate store and/or one or more application certificate stores. This may be achieved by an agent interfacing to an associated application programming interface (API) in order to manage certificates e.g. add, modify, delete, update etc.
  • API application programming interface
  • end-system applications may use a "client certificate" for strong security and/or privacy and/or integrity.
  • DMS Document management applications or document management systems
  • Examples include document signing, document encryption and document approval workflow.
  • a motivation for using these capabilities may be because end-users may want to treat the DMS as only semi-trusted, for example for the DMS to manage the overall storage and management of documents but the end-user can maintain privacy via encryption and ensure integrity using digital signatures.
  • a local certificate store for client-side certificates may be used by a document management system.
  • Agents may be used to manage the distribution and maintenance of certificates to the end-points of members with access to the document management system.
  • Agents may also be used facilitate members outside the document management system as members may send documents to non-members that also make use of an agent. This allows embodiments of the present invention to be used as a "gateway" between internal systems and external people.
  • Conveying a legally binding digital signature on a document may involve a paper version of the document being physically signed by one or more parties either in person and/or remotely and then scanned, printed or faxed and/or sent via courier to one or more other parties.
  • Such a signing process for documents may be costly and/or time consuming.
  • a user's credentials and digital signatures may be used as a basis for legal signatures.
  • documents may by digitally signed and this may be used by the end user and/or other system, e.g. a document management system, for the purpose of a legal digital signature.
  • Digital signatures may be made visible to the user, for example with a signing indicator and/or a way to view the certificate used to verify the signature.
  • Documents may then be involved in a workflow which may involve further signatures between and/or with further parties. In this latter case, signatures may envelope each other to form a chain of custody and/or evidence.
  • Key management may involve the generation, exchange, storage, use, and replacement of cryptographic keys.
  • it is often regarded as the most difficult aspect of cryptosystems because of the manual processes that must be implemented around the lifecycle and/or management of keys.
  • agents may effectively become an authority for keys and thereby allow the decentralisation of key management to those who are responsible for the data, such as box owners or delegated administrators or privileged members within boxes.
  • Encryption may be used for protecting data. Generally, encryption may fall into three categories relating to who controls the keys:
  • Communications encryption where transient or session keys are used to encrypt a network link e.g. SSL, TLS.
  • Host encryption where an operating system or other application ensures that stored information is protected e.g. disk encryptors, volume encryptors, hardware security modules (HSMs) etc.
  • storage keys are maintained by an operating system or device level hardware and/or software.
  • encryption is persistent, such as storage or data encryption, especially in corporate environments, there may be a large number of data objects and/or groups of data objects that need different encryption keys.
  • Each encryption key and/or group of encryption keys may need to be managed throughout its lifecycle e.g. how they are generated, stored, rolled over, assigned, etc. This may result in an expensive and complex key management problem.
  • Key-servers become an authoritative server for managing keys.
  • Key-servers typically maintain a database of secret keys and/or master keys and/or algorithmically derive keys.
  • key-servers may have significant problems, for example:
  • each box or data owner may effectively be a key authority and/or publisher. Since agents may communicate in a virtual peer-to-peer like way, keys may be distributed by box owners without the need for centralised key-servers and/or administrators. This may have the significant advantage of being able to support distributed applications across arbitrary sets of people and/or organisations without the need for trusted third parties.
  • Embodiments of the present invention may avoid the need for TTPs and/or centralised mechanisms for distributing keys. Instead, a user, via their agent, may effectively manage the secure distribution and authorisation of keys. Keys may be stored in a home box and/or a meta-box and/or a shared-box controlled by the owner. Keys may be distributed via messages such as using a contact box and/or posted to a meta-box and/or a shared-box for download by authorised parties.
  • keys are protected using the same mechanisms as protecting user data - via possession of keys for access and encryption for enforcement.
  • content keys may be protected by workspace keys
  • workspace or box keys may be protected by community keys
  • community keys may be protected by certificates etc.
  • a significant driver for enterprise encryption may be to protect confidential information, especially for competitive business reasons and/or compliance reasons.
  • Organisations, particularly large ones may have many and diverse projects that require the encryption of related content according to internal security and/or privacy policies.
  • key management tasks may be addressable with existing staff.
  • key management becomes increasingly complex as the size of projects grow, as the number of projects goes, as the amount of staff changes in projects occur, as the richness of access levels increases etc. This results in increasing administrative burden, especially as projects go live and the responsibility may be passed to "operations".
  • Prior art solutions often attempt to implement processes, such as entitlements or role management, to try to keep track of who needs access to what and why which may involve arduous sign-off procedures to try to ensure accuracy and relevance of people's access rights.
  • data owners may retain responsibility for their data and the people that have access to it. This may avoid the need to pass administrative responsibility, such as to an IT department, who may not understand or be able to manage ongoing and/or changing requirements related to who needs access to what information and why.
  • ensuring data owners retain responsibility for their data may help accountability and auditing and may reduce or eliminate the need for explicit entitlements or role management and/or sign-off procedures. This is because membership to a box may be tracked and therefore may be self-auditing.
  • Business databases especially those storing financial information, may require field level encryption to avoid accidental, malicious or unauthorised access to sensitive data. For example, credit card holder information is vulnerable at each point in a financial processing stream . Though encryption may protect such information, the key management associated may be difficult and/or complex.
  • applications may be authorised to access database fields through the distribution of keys.
  • Groups of applications may be managed by membership and groups of related data may be managed by boxes.
  • the box owner may authorise or de-authorise applications as required through the invite/un- invite process.
  • applications may interface with an agent to handle the keys and/or encryption/decryption of data. Owners of the process may manage boxes.
  • Database fields may be designed to contain a printable form of encrypted data supplemented by meta-data if required e.g. checksums, identifiers etc.
  • both users and applications may be members of boxes.
  • the users are typically one or more that own the process.
  • the applications particularly on different machines and/or environments, may perform the processing, especially distributed processing.
  • Preferably multiple people are members of any given box to simplify recovery and/or administration.
  • a sweeping trend in business may be the move away from internal data centres to virtual data centres and/or the use of cloud services such as laaS, PaaS and SaaS.
  • cloud services such as laaS, PaaS and SaaS.
  • clouds may not have a physical "location" security may be unpredictable and/or compliance with data residency regulations may become difficult.
  • data outside the enterprise may be protected by encryption.
  • Each data owner can create virtual storage, for example in a public or private cloud, but control keys such that the information is protected from the cloud storage provider.
  • applications may interface with an agent using an API that may be similar to the underlying cloud storage service.
  • the API provided by embodiments of the present invention may also supplement third party storage APIs.
  • Some repository services and/or storage services may be kept on premise.
  • user boxes e.g. User Boxes 381
  • agent boxes e.g. Agent Boxes 382
  • message boxes e.g. Message Boxes 383
  • the on-premise protection may add an extra layer of protection by making it relatively impossible to obtain event the encrypted information.
  • embodiments of the present invention may facilitate private, self- managing, cross-organizal, distributed applications. For example, in any one or any combination of the following areas:
  • Message Queues may be implemented in corporate or private cloud environments protected by encrypted transactions. This protects individual data elements, rather than relying on the message queue to secure the transport.
  • Service Buses may make use of encryption, especially by organisations that do not want passwords and account information to be passed over the bus where subscriber applications may be listening in. Similarly, applications that involve credit card information may need to use encryption across an Enterprise Service Bus (ESB) in order to comply with regulations or mandates, such as Payment Card Industry (PCI) requirements.
  • EBS Enterprise Service Bus
  • PCI Payment Card Industry
  • Inter-organizations may make use of private cryptographic tunnels, for example for signalling, key management, configuration, software distribution, asset management etc.
  • Secure transaction management may use keys and encryption for machine authorisation such as for workload automation and/or other distributed processing systems. This is because such distributed systems require .trust between the machines performing the work.
  • Embodiments of the present invention may be integrated in to a broad range of information sharing applications that may require high levels of security, privacy, control etc.
  • Such applications include secure file sharing, social networking, private messaging, private forums, content publishing, VoIP, virtual worlds, telephony, video conferencing, virtual worlds and any other collaboration application. Further examples are outlined in this section.
  • Agents may be embedded into a private portal.
  • a private portal is typically a web page hosted on one-site but contains a view of another system, for example, makes it appear that an area of a page is running on or from a given website.
  • the main advantage of a private portal may be that it may be very quick to setup, such as to add the capability to a web page using an "iframe", and may give significant security and privacy of user data without the necessity to have the website enforce such security and privacy.
  • it may provide a facility to a website, for example a personalised and private area for clients and a business to exchange files, without needing to open up internal computing resources of the business to the internet.
  • a private portal may not need to be attached to a website. Instead a link may be used to invoke the portal in a blank web page. Such a link may safely be sent in an email, because it only identifies the portal, not the data in the portal.
  • a private portal may make use of managed-user credentials. This may be beneficial so that an end-user may get the appearance of just using a name and passphrase to log into a private portal, when in reality, the name and passphrase may have been used to provision a user in a credential backup service.
  • a user inputting the correct name and passphrase may result in the download of credentials to the portal agent and the user gets "logged in" to receive access to shared files, for example in a sub-box or client box,
  • a private portal may make use of an agent capable of performing independent processing in a web browser, for example an applet or other plugin.
  • the portal may be embedded into a webpage within a website using a Hypertext Transfer Markup Language (HTML) iframe.
  • HTML Hypertext Transfer Markup Language
  • the portal agent e.g. the applet in the iframe, may make use of mutual SSL to access storage and/or facility services which may be independent of the website hosting the web page.
  • Options to the portal may be encoded into a parameter in the Uniform Resource Locator (URL), for example to hide modes of the private portal such as read-only, disable passphrase change, display of logos etc.
  • URL Uniform Resource Locator
  • a private portal may have many advantages. For example:
  • the portal may give highly secure and private access to clients without the cost of requiring the website hosting to deliver that high level of security and privacy or opening access to a company's internal servers.
  • the business website may not support SSL, but SSL may be run between the agent and the remote and/or facility services.
  • the portal may reinforce the business brand.
  • a professional company such as one that provides legal, financial, engineering, or any other type of advice, may use the portal to demonstrate to their customers how seriously they are about keeping confidential or other sensitive information secure and private.
  • the portal may allow clients to use a secure collaboration service without first registering and/or being aware that they are using strong credentials. By treating portal users as managed-users, a portal user may simply login using a provided name and passphrase. • A URL for the portal may be safely given out, e.g. via email, without giving away any information about what is being communicated. This may be quite different from prior art which may allow for the publication of URL's of content, which may be a security problem as the "secret" URL to a file can easily become known and may be a privacy problem because it gives away that content exists.
  • a private portal may be attached to a single parent box, allowing login by any client in a sub-box. Additionally, a private portal may be linked to more than one parent box, thus allowing login by any client in any of the sub-boxes of the linked parent boxes.
  • Secure file sharing may cover a class of applications for storing and exchanging files or other content, especially files which may be sensitive, private and/or confidential.
  • Examples users include accountants that need to share financial information with clients, lawyers that need to share drafts of legal documents, directors of companies that need to share board papers, agencies that need to share graphic designs, consultancies that need to share engineering plans, mediators that need to share dispute resolution documents, consultants giving advice to clients, entrepreneurs sharing information with investors, company executives and/or employees who need to share highly confidential and/or proprietary information with other company personnel or external consultants and/or board members, deal rooms, virtual data rooms etc.
  • Secure file sharing may be implemented using an agent application.
  • an agent application may allow an owner to setup private workspaces and to selectively invite/un-invite people to shared boxes or workspaces as required. Members may be able to upload/download files as appropriate for the permissions given to them.
  • the owner may delegate administrative rights or privileges, such as to invite other members and/or add sub-boxes and/or other access control permissions on files/folders such as delete, modify, read etc.
  • the application may also provide notifications about activity and/or audit reports about that activity.
  • Publication of content may involve large files such as multi-media files.
  • the content may be locked and access to it is via issuance and distribution of a key which allows unlocking of the content.
  • Publication of content may involve physical distribution, such as via compact disc (CD) or digital video disk (DVD).
  • CD compact disc
  • DVD digital video disk
  • the content may be protected by encryption and only accessible using a key provided by the content provider. This approach may be valuable when it is too expensive to deliver the content electronically, but still can deliver the keys electronically.
  • Publication of content may involve electronic distribution, for example, enabling copies of large files in multiple geographic locations.
  • a repository service may facilitate this replication and advise agents as to where the nearest copy is located. Note that this replication may be independent from the enablement of viewing the content through the use of keys.
  • Publication of content may involve interfacing with third party document management systems where selected information needs to be provided to authorised people.
  • Publication of content of content may be synchronised by delaying the release of keys.
  • content may be distributed, and later, an owner may distribute keys to a set of users who share the content at the same time. This may be for applications that need to synchronise the release of material at the same time, for example exams, tenders, entertainment, products, services etc.
  • Publication of content may make use of a private portal, as described above, so that information may be made available to external people, not necessarily requiring local credentials.
  • Publication of content may make use of repository services to enforce policy(s) or other controls.
  • a library or other information service may enable users to buy a certain number of documents and then download them as required.
  • the repository service may restrict any given user's download to a set number and/or set value and/or restrict certain documents to be only downloaded once. When such limits and/or conditions are reached , the repository service may make further files inaccessible.
  • An audit may be used to reconcile usage with user's account and/or privileges and/or allocations.

Landscapes

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

Abstract

La présente invention concerne le domaine de la sécurité des données électroniques et/ou des communications. Dans un aspect, l'invention concerne la sécurité des données et/ou la confidentialité des données dans un environnement réseau réparti et/ou décentralisé. Dans un autre aspect, l'invention concerne un procédé consistant à permettre une collaboration privée et/ou un partage d'information entre des utilisateurs, des agents et/ou des applications. Un ou plusieurs modes de réalisation consistent à permettre le partage d'une ou de plusieurs clés et/ou d'un ou de plusieurs contenus entre un premier utilisateur et/ou un agent et un second utilisateur et/ou un agent. En outre, un ou plusieurs modes de réalisation de l'invention s'appliquent au partage de données chiffrées par l'intermédiaire de services de partage d'informations. L'invention concerne également plusieurs modes de réalisation.
PCT/AU2013/000145 2012-02-20 2013-02-19 Système et procédé de cryptographie WO2013123548A2 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP13752183.7A EP2817917B1 (fr) 2012-02-20 2013-02-19 Système et procédé de cryptographie
US13/969,071 US8842841B2 (en) 2012-02-20 2013-08-16 Cryptographic method and system
US14/455,300 US20140351586A1 (en) 2012-02-20 2014-08-08 Cryptographic method and system
IL234215A IL234215B (en) 2012-02-20 2014-08-20 Cryptographic method and system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AU2012900626A AU2012900626A0 (en) 2012-02-20 Cryptographic Method and System
AU2012900626 2012-02-20

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/969,071 Continuation US8842841B2 (en) 2012-02-20 2013-08-16 Cryptographic method and system

Publications (2)

Publication Number Publication Date
WO2013123548A2 true WO2013123548A2 (fr) 2013-08-29
WO2013123548A3 WO2013123548A3 (fr) 2014-12-31

Family

ID=49006320

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2013/000145 WO2013123548A2 (fr) 2012-02-20 2013-02-19 Système et procédé de cryptographie

Country Status (5)

Country Link
US (2) US8842841B2 (fr)
EP (1) EP2817917B1 (fr)
AU (1) AU2013200916B2 (fr)
IL (1) IL234215B (fr)
WO (1) WO2013123548A2 (fr)

Cited By (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015084305A1 (fr) * 2013-12-02 2015-06-11 Intel Corporation Procédés, systèmes et appareil de protection de contenu basés sur des personas
WO2015142715A1 (fr) * 2014-03-18 2015-09-24 Intuit Inc. Procédé et système pour fournir des biens virtuels à capacité d'accès sécurisé
US9152806B2 (en) 2013-12-06 2015-10-06 Sony Corporation Computer ecosystem providing privacy and tracking in sharing user-generated content by encrypting the UGC at the imaging source
WO2015153333A3 (fr) * 2014-04-02 2015-12-30 Severin William B Trains de vagues de signal
US9298927B2 (en) 2014-02-27 2016-03-29 Intuit Inc. Method and system for providing an efficient vulnerability management and verification service
US20160134751A1 (en) * 2014-11-10 2016-05-12 Alibaba Group Holding Limited Method and apparatus for establishing communication between mobile terminals, incoming communication control and outgoing communication control and system by use thereof
US9390288B2 (en) 2013-11-01 2016-07-12 Intuit Inc. Method and system for validating a virtual asset
US9418236B2 (en) 2013-11-13 2016-08-16 Intuit Inc. Method and system for dynamically and automatically managing resource access permissions
US9516044B2 (en) 2014-07-31 2016-12-06 Intuit Inc. Method and system for correlating self-reporting virtual asset data with external events to generate an external event identification database
US9742794B2 (en) 2014-05-27 2017-08-22 Intuit Inc. Method and apparatus for automating threat model generation and pattern identification
US9866534B2 (en) 2013-12-06 2018-01-09 Sony Corporation Computer ecosystem providing privacy and tracking in sharing user-generated content
US9923909B2 (en) 2014-02-03 2018-03-20 Intuit Inc. System and method for providing a self-monitoring, self-reporting, and self-repairing virtual asset configured for extrusion and intrusion detection and threat scoring in a cloud computing environment
US10102082B2 (en) 2014-07-31 2018-10-16 Intuit Inc. Method and system for providing automated self-healing virtual assets
US10121007B2 (en) 2014-02-21 2018-11-06 Intuit Inc. Method and system for providing a robust and efficient virtual asset vulnerability management and verification service
US10757133B2 (en) 2014-02-21 2020-08-25 Intuit Inc. Method and system for creating and deploying virtual assets
TWI734426B (zh) * 2019-03-27 2021-07-21 開曼群島商創新先進技術有限公司 使用可信執行環境檢索區塊鏈網路的公開資料
US11082240B2 (en) 2019-03-27 2021-08-03 Advanced New Technologies Co., Ltd. Retrieving public data for blockchain networks using highly available trusted execution environments
US11095629B2 (en) 2019-03-29 2021-08-17 Advanced New Technologies Co., Ltd. Retrieving access data for blockchain networks using highly available trusted execution environments
US20210344508A1 (en) * 2018-09-06 2021-11-04 Securosys SA Hardware Security Module that Enforces Signature Requirements
US11294700B2 (en) 2014-04-18 2022-04-05 Intuit Inc. Method and system for enabling self-monitoring virtual assets to correlate external events with characteristic patterns associated with the virtual assets
US20220188719A1 (en) * 2020-12-16 2022-06-16 Commvault Systems, Inc. Systems and methods for generating a user file activity audit report
US20220237595A1 (en) * 2019-06-24 2022-07-28 Blockstar Developments Limited Cryptocurrency key management
DE112018004390B4 (de) 2017-10-19 2022-12-08 International Business Machines Corporation Sichere zugriffsverwaltung für werkzeuge innerhalb einer sicheren umgebung

Families Citing this family (254)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9067150B2 (en) * 2008-01-19 2015-06-30 Lamplight Games System and method for providing interactive content for multiple networked users in a shared venue using short messaging service communication
EP2386977A1 (fr) * 2010-05-11 2011-11-16 Gemalto SA Système permettant l'affichage d'un fichier informatique privé sur un écran d'un terminal de télécommunications et procédé correspondant
EP2625820B1 (fr) * 2010-10-08 2021-06-02 Brian Lee Moffat Système de partage de données privées
US9824198B2 (en) * 2011-07-14 2017-11-21 Docusign, Inc. System and method for identity and reputation score based on transaction history
US9948988B2 (en) * 2011-10-04 2018-04-17 Ricoh Company, Ltd. Meeting system that interconnects group and personal devices across a network
US10142122B1 (en) 2012-04-11 2018-11-27 Google Llc User interfaces, systems and methods for configuring smart devices for interoperability with a smart hub device
US10397013B1 (en) 2012-04-11 2019-08-27 Google Llc User interfaces, systems and methods for configuring smart devices for interoperability with a smart hub device
US10075334B1 (en) 2012-04-11 2018-09-11 Google Llc Systems and methods for commissioning a smart hub device
US9198204B2 (en) 2012-04-11 2015-11-24 Google Inc. Apparatus and method for seamless commissioning of wireless devices
US8625805B1 (en) 2012-07-16 2014-01-07 Wickr Inc. Digital security bubble
US9449178B2 (en) * 2012-07-24 2016-09-20 ID Insight System, method and computer product for fast and secure data searching
US9756022B2 (en) 2014-08-29 2017-09-05 Box, Inc. Enhanced remote key management for an enterprise in a cloud-based environment
CN104737494B (zh) * 2012-10-17 2018-01-09 诺基亚技术有限公司 用于以分布式方式基于信任评估来提供安全通信的方法和装置
EP2784717A1 (fr) 2012-10-17 2014-10-01 Box, Inc. Gestion de clé à distance dans un environnement sur Cloud
US9654579B2 (en) 2012-12-21 2017-05-16 Akamai Technologies, Inc. Scalable content delivery network request handling mechanism
US9667747B2 (en) 2012-12-21 2017-05-30 Akamai Technologies, Inc. Scalable content delivery network request handling mechanism with support for dynamically-obtained content policies
US8966260B1 (en) * 2013-01-30 2015-02-24 Palo Alto Networks, Inc. Credentials management in large scale virtual private network deployment
US10164962B2 (en) * 2013-03-15 2018-12-25 Blackhawk Network, Inc. Using client certificates to communicate trusted information
US9887983B2 (en) 2013-10-29 2018-02-06 Nok Nok Labs, Inc. Apparatus and method for implementing composite authenticators
US10706132B2 (en) 2013-03-22 2020-07-07 Nok Nok Labs, Inc. System and method for adaptive user authentication
US10270748B2 (en) 2013-03-22 2019-04-23 Nok Nok Labs, Inc. Advanced authentication techniques and applications
CN104937571A (zh) * 2013-03-27 2015-09-23 日立麦克赛尔株式会社 终端装置、程序、数据收发系统和数据收发方法
US9246892B2 (en) 2013-04-03 2016-01-26 Salesforce.Com, Inc. System, method and computer program product for managing access to systems, products, and data based on information associated with a physical location of a user
US9922580B2 (en) 2013-04-30 2018-03-20 Google Llc Apparatus and method for the virtual demonstration of a smart phone controlled smart home using a website
US9961077B2 (en) 2013-05-30 2018-05-01 Nok Nok Labs, Inc. System and method for biometric authentication with device attestation
US9830089B1 (en) 2013-06-25 2017-11-28 Wickr Inc. Digital data sanitization
US10567349B2 (en) 2013-06-25 2020-02-18 Wickr Inc. Secure time-to-live
US9866591B1 (en) 2013-06-25 2018-01-09 Wickr Inc. Enterprise messaging platform
US10129260B1 (en) 2013-06-25 2018-11-13 Wickr Inc. Mutual privacy management
CN105493524A (zh) 2013-07-25 2016-04-13 康维达无线有限责任公司 端到端m2m服务层会话
JP6230322B2 (ja) * 2013-08-01 2017-11-15 株式会社東芝 通信装置、鍵共有方法、プログラムおよび通信システム
US9521126B2 (en) * 2013-08-21 2016-12-13 Intel Corporation Processing data privately in the cloud
US9106642B1 (en) 2013-09-11 2015-08-11 Amazon Technologies, Inc. Synchronizing authentication sessions between applications
US9112854B1 (en) * 2013-09-11 2015-08-18 Amazon Technologies, Inc. Secure communication between applications on untrusted platforms
US9648125B2 (en) * 2013-10-04 2017-05-09 Akamai Technologies, Inc. Systems and methods for caching content with notification-based invalidation
US9641640B2 (en) * 2013-10-04 2017-05-02 Akamai Technologies, Inc. Systems and methods for controlling cacheability and privacy of objects
US9813515B2 (en) * 2013-10-04 2017-11-07 Akamai Technologies, Inc. Systems and methods for caching content with notification-based invalidation with extension to clients
US10623400B2 (en) * 2013-10-14 2020-04-14 Greg Hauw Method and device for credential and data protection
JP6226689B2 (ja) * 2013-10-16 2017-11-08 キヤノン株式会社 情報処理システム、情報処理方法、及びプログラム
US9185136B2 (en) * 2013-11-28 2015-11-10 Cyber-Ark Software Ltd. Correlation based security risk identification
US10088818B1 (en) 2013-12-23 2018-10-02 Google Llc Systems and methods for programming and controlling devices with sensor data and learning
US9698976B1 (en) 2014-02-24 2017-07-04 Wickr Inc. Key management and dynamic perfect forward secrecy
US9467441B2 (en) * 2014-02-25 2016-10-11 Dell Products, L.P. Secure service delegator
US8943140B1 (en) * 2014-03-26 2015-01-27 Ankit Dilip Kothari Assign photographers on an event invite and automate requesting, uploading, and sharing of photos and videos for an event
US9413533B1 (en) 2014-05-02 2016-08-09 Nok Nok Labs, Inc. System and method for authorizing a new authenticator
US9654469B1 (en) 2014-05-02 2017-05-16 Nok Nok Labs, Inc. Web-based user authentication techniques and applications
US9577999B1 (en) 2014-05-02 2017-02-21 Nok Nok Labs, Inc. Enhanced security for registration of authentication devices
US10257017B2 (en) * 2014-06-03 2019-04-09 JumpCloud, Inc. Autonomous server agents
US9430405B2 (en) 2014-06-18 2016-08-30 Fastly, Inc. Encrypted purging of data from content node storage
US9609032B2 (en) * 2014-06-26 2017-03-28 Microsoft Technology Licensing, Llc Joint ownership of protected information
US9584530B1 (en) 2014-06-27 2017-02-28 Wickr Inc. In-band identity verification and man-in-the-middle defense
US9082018B1 (en) * 2014-09-30 2015-07-14 Google Inc. Method and system for retroactively changing a display characteristic of event indicators on an event timeline
US9672377B2 (en) * 2014-07-11 2017-06-06 mindHIVE Inc. System and methods for secure collaborative communication
US10148630B2 (en) 2014-07-31 2018-12-04 Nok Nok Labs, Inc. System and method for implementing a hosted authentication service
US9749131B2 (en) 2014-07-31 2017-08-29 Nok Nok Labs, Inc. System and method for implementing a one-time-password using asymmetric cryptography
US9875347B2 (en) 2014-07-31 2018-01-23 Nok Nok Labs, Inc. System and method for performing authentication using data analytics
US9455979B2 (en) 2014-07-31 2016-09-27 Nok Nok Labs, Inc. System and method for establishing trust using secure transmission protocols
US9071618B1 (en) 2014-08-04 2015-06-30 Bank Of America Corporation Providing multiple access levels to a single user account using different login credentials
US9912644B2 (en) * 2014-08-05 2018-03-06 Fireeye, Inc. System and method to communicate sensitive information via one or more untrusted intermediate nodes with resilience to disconnected network topology
SE539192C2 (en) * 2014-08-08 2017-05-09 Identitrade Ab Method and a system for authenticating a user
EP2985945A1 (fr) * 2014-08-15 2016-02-17 CompuGroup Medical AG Méthode pour la sécurité de l' échange des courriers électroniques
CN104182698B (zh) * 2014-08-18 2018-01-16 联想(北京)有限公司 一种数据清除方法及电子设备
JP2016048413A (ja) * 2014-08-27 2016-04-07 株式会社東芝 システム、仮想デスクトップ環境選択方法および情報処理装置
US9397832B2 (en) * 2014-08-27 2016-07-19 International Business Machines Corporation Shared data encryption and confidentiality
US10574442B2 (en) 2014-08-29 2020-02-25 Box, Inc. Enhanced remote key management for an enterprise in a cloud-based environment
TW201610699A (zh) * 2014-09-05 2016-03-16 緯創資通股份有限公司 應用程式分享方法以及使用該方法的裝置
WO2016037048A1 (fr) * 2014-09-05 2016-03-10 Sequitur Labs, Inc. Exécution et messagerie d'un code sécurisé géré par des règles pour des dispositifs informatiques, et sécurité d'un dispositif informatique
US9710672B2 (en) * 2014-09-08 2017-07-18 Uri Jacob Braun System for and method of controllably disclosing sensitive data
US9736154B2 (en) 2014-09-16 2017-08-15 Nok Nok Labs, Inc. System and method for integrating an authentication service within a network architecture
US10114939B1 (en) * 2014-09-22 2018-10-30 Symantec Corporation Systems and methods for secure communications between devices
US9552485B1 (en) * 2014-10-21 2017-01-24 Amazon Technologies, Inc. Cryptographic material renewal
US10367646B1 (en) 2014-10-21 2019-07-30 Amazon Technologies, Inc. Cryptographic material distribution and management
US10275604B2 (en) 2014-10-31 2019-04-30 Hewlett Packard Enterprise Development Lp Security record transfer in a computing system
US10503909B2 (en) 2014-10-31 2019-12-10 Hewlett Packard Enterprise Development Lp System and method for vulnerability remediation verification
EP3206341B1 (fr) * 2014-11-04 2021-03-17 Huawei Technologies Co., Ltd. Procédé, appareil et dispositif pour afficher un message
EP3018876B1 (fr) * 2014-11-05 2020-01-01 Vodafone IP Licensing limited Surveillance de signalisation de trafic
US10601604B2 (en) 2014-11-12 2020-03-24 Google Llc Data processing systems and methods for smart hub devices
EP3032453B1 (fr) 2014-12-08 2019-11-13 eperi GmbH Stockage de données dans un ordinateur serveur avec une infrastructure de cryptage/décryptage déployable
US9654288B1 (en) 2014-12-11 2017-05-16 Wickr Inc. Securing group communications
US10277565B2 (en) 2014-12-31 2019-04-30 Hewlett Packard Enterprise Development Lp Enterprise service bus logging
US10110575B2 (en) * 2015-01-29 2018-10-23 Docusign, Inc. Systems and methods for secure data exchange
US10341103B2 (en) 2015-01-29 2019-07-02 Entit Software Llc Data analytics on encrypted data elements
US9754120B2 (en) * 2015-02-13 2017-09-05 Konica Minolta Laboratory U.S.A., Inc. Document redaction with data retention
US10218700B2 (en) * 2015-02-23 2019-02-26 Ca, Inc. Authorizations for computing devices to access a protected resource
US9674162B1 (en) 2015-03-13 2017-06-06 Amazon Technologies, Inc. Updating encrypted cryptographic key pair
US9893885B1 (en) 2015-03-13 2018-02-13 Amazon Technologies, Inc. Updating cryptographic key pair
US10505905B2 (en) * 2015-03-24 2019-12-10 Global Data Sentinel, Inc. Transport envelope
US9602288B1 (en) * 2015-03-27 2017-03-21 Amazon Technologies, Inc. Enhanced data security through uniqueness checking
US10003467B1 (en) 2015-03-30 2018-06-19 Amazon Technologies, Inc. Controlling digital certificate use
US9479340B1 (en) 2015-03-30 2016-10-25 Amazon Technologies, Inc. Controlling use of encryption keys
WO2019070419A1 (fr) * 2017-09-20 2019-04-11 James Fournier Système de commande d'utilisation de données internet
US10631793B1 (en) * 2015-04-14 2020-04-28 Eric Levell Luster Impact indicator
US10516527B1 (en) * 2015-04-17 2019-12-24 EMC IP Holding Company LLC Split-key based cryptography system for data protection and synchronization across multiple computing devices
US9729390B2 (en) 2015-04-22 2017-08-08 LARC Networks, Inc. Dead drop network architecture
US9703973B2 (en) * 2015-04-28 2017-07-11 International Business Machines Corporation Customer load of field programmable gate arrays
US20160335447A1 (en) * 2015-05-15 2016-11-17 Alcatel-Lucent Usa, Inc. Secure enterprise cdn framework
US9639705B1 (en) * 2015-06-17 2017-05-02 Amazon Technologies, Inc. Encryption management for data storage
US9699197B2 (en) 2015-07-17 2017-07-04 LARC Networks, Inc. Double write data exchange in a dead drop network architecture
US20170046531A1 (en) * 2015-08-14 2017-02-16 Strong Bear Llc Data encryption method and system for use with cloud storage
CN106529322A (zh) * 2015-09-14 2017-03-22 飞思卡尔半导体公司 自动的存储安全
US10003466B1 (en) * 2015-09-15 2018-06-19 Amazon Technologies, Inc. Network traffic with credential signatures
US10027640B2 (en) * 2015-09-22 2018-07-17 Qualcomm Incorporated Secure data re-encryption
US10437977B2 (en) * 2015-10-13 2019-10-08 Etas Embedded Systems Canada Inc. System and method for digital key sharing for access control
US9735961B2 (en) * 2015-11-16 2017-08-15 Verizon Patent And Licensing Inc. Managing key rotations with multiple key managers
US10382538B1 (en) * 2015-11-16 2019-08-13 Kairos App, L.L.C. System and method for creating a dynamic social network
ITUB20155986A1 (it) * 2015-11-27 2017-05-27 Savo Mario Sistema di sicurezza informatica per la distribuzione, la condivisione e l?immagazzinamento di dati crittografati tramite la comunicazione riservata delle relative chiavi di decriptazione
US10037436B2 (en) * 2015-12-11 2018-07-31 Visa International Service Association Device using secure storage and retrieval of data
US9584493B1 (en) 2015-12-18 2017-02-28 Wickr Inc. Decentralized authoritative messaging
US10225084B1 (en) * 2015-12-29 2019-03-05 EMC IP Holding Company LLC Method, apparatus and computer program product for securely sharing a content item
US10778435B1 (en) * 2015-12-30 2020-09-15 Jpmorgan Chase Bank, N.A. Systems and methods for enhanced mobile device authentication
US10291607B1 (en) 2016-02-02 2019-05-14 Wickr Inc. Providing real-time events to applications
US10791097B2 (en) * 2016-04-14 2020-09-29 Sophos Limited Portable encryption format
AU2016392715B2 (en) * 2016-02-12 2020-07-23 Sophos Limited Encryption techniques
US9984248B2 (en) * 2016-02-12 2018-05-29 Sophos Limited Behavioral-based control of access to encrypted content by a process
US10263966B2 (en) * 2016-04-14 2019-04-16 Sophos Limited Perimeter enforcement of encryption rules
US10650154B2 (en) 2016-02-12 2020-05-12 Sophos Limited Process-level control of encrypted content
US10681078B2 (en) * 2016-06-10 2020-06-09 Sophos Limited Key throttling to mitigate unauthorized file access
US10628597B2 (en) * 2016-04-14 2020-04-21 Sophos Limited Just-in-time encryption
US10686827B2 (en) * 2016-04-14 2020-06-16 Sophos Limited Intermediate encryption for exposed content
DE102016205203A1 (de) * 2016-03-30 2017-10-05 Siemens Aktiengesellschaft Datenstruktur zur Verwendung als Positivliste in einem Gerät, Verfahren zur Aktualisierung einer Positivliste und Gerät
US9596079B1 (en) 2016-04-14 2017-03-14 Wickr Inc. Secure telecommunications
US9602477B1 (en) 2016-04-14 2017-03-21 Wickr Inc. Secure file transfer
US10228924B2 (en) 2016-04-19 2019-03-12 International Business Machines Corporation Application deployment and monitoring in a cloud environment to satisfy integrity and geo-fencing constraints
US10574440B2 (en) * 2016-05-06 2020-02-25 ZeroDB, Inc. High-performance access management and data protection for distributed messaging applications
US10509459B2 (en) 2016-05-19 2019-12-17 Scenera, Inc. Scene-based sensor networks
US10291604B2 (en) 2016-06-03 2019-05-14 Docusign, Inc. Universal access to document transaction platform
US10237306B1 (en) * 2016-06-30 2019-03-19 EMC IP Holding Company LLC Communicating service encryption key to interceptor for monitoring encrypted communications
GB2551983B (en) 2016-06-30 2020-03-04 Sophos Ltd Perimeter encryption
US10110383B1 (en) * 2016-06-30 2018-10-23 EMC IP Holding Company LLC Managing embedded and remote encryption keys on data storage systems
US10826875B1 (en) * 2016-07-22 2020-11-03 Servicenow, Inc. System and method for securely communicating requests
ES2725048T1 (es) * 2016-07-29 2019-09-19 Permanent Privacy Ltd Aplicaciones asociadas a una encriptación segura
US10637853B2 (en) 2016-08-05 2020-04-28 Nok Nok Labs, Inc. Authentication techniques including speech and/or lip movement analysis
US10769635B2 (en) 2016-08-05 2020-09-08 Nok Nok Labs, Inc. Authentication techniques including speech and/or lip movement analysis
MY197983A (en) 2016-08-10 2023-07-25 Nextlabs Inc Sharing encrypted documents within and outside an organization
US10356087B1 (en) * 2016-08-26 2019-07-16 Intelligent Waves Llc System, method and computer program product for credential provisioning in a mobile device platform
US10177908B2 (en) * 2016-08-30 2019-01-08 Workday, Inc. Secure storage decryption system
US10693843B2 (en) * 2016-09-02 2020-06-23 Scenera, Inc. Security for scene-based sensor networks
US10305906B1 (en) * 2016-09-13 2019-05-28 Amazon Technologies, Inc. Access heartbeat for a hardware security module
US10528432B2 (en) * 2016-09-28 2020-01-07 Sap Se Off-site backup network disk
US10356067B2 (en) * 2016-11-02 2019-07-16 Robert Bosch Gmbh Device and method for providing user-configured trust domains
US20180137291A1 (en) * 2016-11-14 2018-05-17 Linkedin Corporation Securing files at rest in remote storage systems
US10250440B2 (en) 2016-11-29 2019-04-02 International Business Machines Corporation Managing a generation and delivery of digital identity documents
US11165565B2 (en) * 2016-12-09 2021-11-02 Microsoft Technology Licensing, Llc Secure distribution private keys for use by untrusted code
US10091195B2 (en) 2016-12-31 2018-10-02 Nok Nok Labs, Inc. System and method for bootstrapping a user binding
US10237070B2 (en) 2016-12-31 2019-03-19 Nok Nok Labs, Inc. System and method for sharing keys across authenticators
US10171487B2 (en) * 2017-02-15 2019-01-01 International Business Machines Corporation Generating a virtual database to test data security of a real database
US20180239506A1 (en) * 2017-02-20 2018-08-23 Michael Edmond ARZOUMANIAN Activation system for controlling interactive devices
US10594481B2 (en) 2017-02-21 2020-03-17 International Business Machines Corporation Replicated encrypted data management
WO2018156885A1 (fr) * 2017-02-24 2018-08-30 Adt Us Holdings, Inc. Réinitialisation automatique de mot de passe à l'aide d'un système de sécurité
US10467292B2 (en) * 2017-02-28 2019-11-05 Salesforce.Com, Inc. Suggesting query items based on database fields
JP6900727B2 (ja) * 2017-03-28 2021-07-07 横河電機株式会社 エンジニアリング支援システム、エンジニアリング支援方法、クライアント装置、及びクライアントプログラム
US10469254B2 (en) 2017-03-29 2019-11-05 Intuit Inc. Method and system for hierarchical cryptographic key management
US10796015B2 (en) * 2017-03-29 2020-10-06 Mybitchbook, Inc. Method and system for anonymous user data storage and controlled data access
US10990707B1 (en) * 2017-03-30 2021-04-27 Comodo Security Solutions, Inc. Device for safe data signing
US11538031B2 (en) 2017-03-31 2022-12-27 Vijay Madisetti Method and system for identity and access management for blockchain interoperability
US10248808B2 (en) * 2017-04-11 2019-04-02 International Business Machines Corporation File sharing and policy control based on file link mechanism
US10812475B2 (en) * 2017-04-18 2020-10-20 Servicenow, Inc. Authenticating access to an instance
US10686765B2 (en) * 2017-04-19 2020-06-16 International Business Machines Corporation Data access levels
US10122699B1 (en) * 2017-05-31 2018-11-06 InfoSci, LLC Systems and methods for ephemeral shared data set management and communication protection
US11463439B2 (en) * 2017-04-21 2022-10-04 Qwerx Inc. Systems and methods for device authentication and protection of communication on a system on chip
US10645078B2 (en) 2017-05-01 2020-05-05 Microsoft Technology Licensing, Llc Smart card thumb print authentication
US11182349B2 (en) * 2017-06-04 2021-11-23 Apple Inc. Synchronizing content
US11528129B2 (en) 2017-06-04 2022-12-13 Apple Inc. Synchronizing content
US20180367308A1 (en) * 2017-06-16 2018-12-20 LARC Networks, Inc. User authentication in a dead drop network domain
US10491576B1 (en) * 2017-06-16 2019-11-26 Intuit Inc. System and method for security breach response using hierarchical cryptographic key management
US10263775B2 (en) 2017-06-23 2019-04-16 Microsoft Technology Licensing, Llc Policy-based key recovery
US11829583B2 (en) * 2017-07-07 2023-11-28 Open Text Sa Ulc Systems and methods for content sharing through external systems
US10999318B2 (en) * 2017-07-07 2021-05-04 Uniken Inc. Algorithmic packet-based defense against distributed denial of service
US11082412B2 (en) 2017-07-12 2021-08-03 Wickr Inc. Sending secure communications using a local ephemeral key pool
US11316666B2 (en) * 2017-07-12 2022-04-26 Amazon Technologies, Inc. Generating ephemeral key pools for sending and receiving secure communications
US10715504B2 (en) * 2017-07-12 2020-07-14 Wickr Inc. Provisioning ephemeral key pools for sending and receiving secure communications
US11146406B2 (en) 2017-07-26 2021-10-12 Hewlett-Packard Development Company, L.P. Managing entitlement
US10841079B1 (en) * 2017-07-26 2020-11-17 EMC IP Holding Company LLC Data registration-aware storage systems
US10432613B2 (en) * 2017-08-23 2019-10-01 Dell Products L. P. HTTPS enabled client tool
US10193690B1 (en) * 2017-09-29 2019-01-29 U.S. Bancorp, National Association Systems and methods to secure data using computer system attributes
US11868995B2 (en) 2017-11-27 2024-01-09 Nok Nok Labs, Inc. Extending a secure key storage for transaction confirmation and cryptocurrency
US10904230B2 (en) * 2017-11-29 2021-01-26 Vmware, Inc. Distributed encryption
US10887322B2 (en) * 2017-12-04 2021-01-05 Microsoft Technology Licensing, Llc Preserving integrity of multi-authored message content
US11831409B2 (en) 2018-01-12 2023-11-28 Nok Nok Labs, Inc. System and method for binding verifiable claims
US10068099B1 (en) * 2018-01-19 2018-09-04 Griffin Group Global, LLC System and method for providing a data structure having different-scheme-derived portions
US10078759B1 (en) * 2018-01-19 2018-09-18 Griffin Group Global, LLC System and method for data sharing via a data structure having different-scheme-derived portions
CN108345801B (zh) * 2018-02-09 2021-09-28 南京邮电大学 一种面向密文数据库的中间件动态用户认证方法及系统
GB2574182A (en) * 2018-03-26 2019-12-04 Ssh Communications Security Oyj Authentication in a computer network system
US11023601B2 (en) * 2018-04-20 2021-06-01 Rohde & Schwarz Gmbh & Co. Kg System and method for secure data handling
EP3557469B1 (fr) * 2018-04-20 2022-06-22 Rohde & Schwarz GmbH & Co. KG Système, procédé et programme informatique pour un échange de données sécurisé
US11362824B2 (en) * 2018-05-25 2022-06-14 Intertrust Technologies Corporation Content management systems and methods using proxy reencryption
US11115224B1 (en) * 2018-06-05 2021-09-07 Amazon Technologies, Inc. Access control system
US10885226B1 (en) * 2018-06-06 2021-01-05 NortonLifeLock, Inc. Systems and methods for enforcing secure shared access on computing devices by content state pinning
US11303632B1 (en) * 2018-06-08 2022-04-12 Wells Fargo Bank, N.A. Two-way authentication system and method
CN112491972A (zh) * 2018-06-11 2021-03-12 华为技术有限公司 资源获取、分发、下载方法、装置、设备及存储介质
US11025425B2 (en) 2018-06-25 2021-06-01 Elasticsearch B.V. User security token invalidation
US11223626B2 (en) 2018-06-28 2022-01-11 Elasticsearch B.V. Service-to-service role mapping systems and methods
JP2021530071A (ja) 2018-06-29 2021-11-04 クラウデンティティー インコーポレーテッド データストリームアイデンティティ
US11196554B2 (en) * 2018-07-27 2021-12-07 Elasticsearch B.V. Default password removal
US11611541B2 (en) * 2018-08-07 2023-03-21 Citrix Systems, Inc. Secure method to replicate on-premise secrets in a cloud environment
US10708247B2 (en) 2018-09-27 2020-07-07 Intel Corporation Technologies for providing secure utilization of tenant keys
US11184162B1 (en) * 2018-09-28 2021-11-23 NortonLifeLock Inc. Privacy preserving secure task automation
US11133933B1 (en) * 2018-11-23 2021-09-28 Amazon Technologies, Inc. Rapid secure authentication and communications through multitenant components in provider networks
US11023598B2 (en) 2018-12-06 2021-06-01 Elasticsearch B.V. Document-level attribute-based access control
US11133932B2 (en) * 2018-12-20 2021-09-28 Sony Interactive Entertainment LLC Secure data channel in a networked gaming system
US10848974B2 (en) 2018-12-28 2020-11-24 Intel Corporation Multi-domain trust establishment in edge cloud architectures
US11102002B2 (en) * 2018-12-28 2021-08-24 Dell Products, L.P. Trust domain isolation management in secured execution environments
CN109886548B (zh) * 2019-01-18 2024-05-07 平安科技（深圳）有限公司 派单方法、系统、装置及存储介质
US11165568B2 (en) 2019-01-28 2021-11-02 Knectiq Inc. System and method for secure electronic data transfer
US12041039B2 (en) 2019-02-28 2024-07-16 Nok Nok Labs, Inc. System and method for endorsing a new authenticator
CN113508379B (zh) * 2019-03-04 2024-02-20 日立数据管理有限公司 用于分布式系统中的多向信任形成的系统、方法和介质
US11418497B2 (en) * 2019-03-21 2022-08-16 Microsoft Technology Licensing, Llc Synchronization in a file storage system using authentication-state-based permissions
US11449620B2 (en) 2019-03-27 2022-09-20 Zettaset, Inc. Transparent high-performance data-at-rest encryption for platform-as-a-service (PaaS) environments
US11792024B2 (en) 2019-03-29 2023-10-17 Nok Nok Labs, Inc. System and method for efficient challenge-response authentication
CN109996228B (zh) * 2019-03-29 2021-04-13 联想(北京)有限公司 一种信息处理方法及电子设备
US11552781B2 (en) 2019-04-05 2023-01-10 Honeywell International Inc. Using error detection bits for cryptographic integrity and authentication
US11423181B2 (en) * 2019-05-09 2022-08-23 Scott R. Copeland Distributed and autonomous data security agent
US11411746B2 (en) * 2019-05-24 2022-08-09 Centrality Investments Limited Systems, methods, and storage media for permissioned delegation in a computing environment
US11461451B2 (en) 2019-06-25 2022-10-04 Vmware, Inc. Document signing system for mobile devices
US11275858B2 (en) * 2019-06-25 2022-03-15 Vmware, Inc. Document signing system for mobile devices
US11570155B2 (en) * 2019-07-25 2023-01-31 Everything Blockchain Technology Corp. Enhanced secure encryption and decryption system
CN112398800A (zh) * 2019-08-19 2021-02-23 华为技术有限公司 一种数据处理方法及装置
US20210092127A1 (en) * 2019-09-19 2021-03-25 Microsoft Technology Licensing, Llc Writing role-backed access control to chain
EP4035333A4 (fr) 2019-09-24 2022-11-16 Magic Labs, Inc. Outil non gardien pour construire des applications informatiques décentralisées
US11362843B1 (en) * 2019-11-19 2022-06-14 Amazon Technologies, Inc. Certificate rotation on host
US11843706B1 (en) 2019-11-19 2023-12-12 Amazon Technologies, Inc. Gradual certificate rotation
CN111090887A (zh) * 2019-12-30 2020-05-01 论客科技（广州）有限公司 一种基于即时聊天工具的对话内容销毁方法及装置
US11159316B2 (en) * 2020-01-15 2021-10-26 Vmware, Inc. Self-service device encryption key access
US11722477B2 (en) * 2020-01-21 2023-08-08 Forcepoint Llc Automated renewal of certificates across a distributed computing security system
US11741192B2 (en) * 2020-01-29 2023-08-29 International Business Machines Corporation Increasing trust formation and reduce oversight costs for autonomous agents
US11290253B2 (en) * 2020-02-14 2022-03-29 Gideon Samid Document management cryptography
US11444781B2 (en) * 2020-02-20 2022-09-13 Lenovo (Singapore) Pte. Ltd. Distributed trust authentication
US20210288947A1 (en) * 2020-03-13 2021-09-16 Disney Enterprises, Inc. Secure content access across user accounts
US11876797B2 (en) 2020-03-30 2024-01-16 Everything Blockchain Technology Corp. Multi-factor geofencing system for secure encryption and decryption system
US11552802B2 (en) * 2020-04-15 2023-01-10 Salesforce, Inc. Stateless mutual authentication between services
US20220327247A1 (en) * 2020-05-16 2022-10-13 Scott R. Copeland DISTRIBUTED and AUTONOMOUS DATA SECURITY AGENT
CN116018779A (zh) 2020-06-29 2023-04-25 伊鲁米纳公司 面向软件即服务租户的基于策略的基因组数据共享
CN115868144A (zh) * 2020-06-29 2023-03-28 伊鲁米纳公司 经由安全发现框架的临时云提供商凭据
US11477183B1 (en) 2020-06-29 2022-10-18 Amazon Technologies, Inc. Application-based management of security credential revocations
US11334661B1 (en) * 2020-06-29 2022-05-17 Amazon Technologies, Inc. Security credential revocations in a cloud provider network
US10897351B1 (en) * 2020-07-02 2021-01-19 Slack Technologies, Inc. Encryption key management for an automated workflow
CN111865970B (zh) * 2020-07-17 2022-09-16 北京百度网讯科技有限公司 用于实现接口幂等性的方法和装置
US20220103379A1 (en) * 2020-09-28 2022-03-31 Red Hat, Inc. Secured software workload provisioning to a trusted execution environment
US11601418B2 (en) 2020-10-14 2023-03-07 Bank Of America Corporation System for increasing authentication complexity for access to online systems
JP7470879B2 (ja) 2020-12-28 2024-04-18 キーファクター， インコーポレイテッド 遠隔証明機関管理
CN114765546B (zh) * 2020-12-30 2023-07-18 海能达通信股份有限公司 端到端硬加密方法、系统、加密设备、密钥管理服务器
US11349924B1 (en) * 2021-04-07 2022-05-31 Dell Products L.P. Mechanism for peer-to-peer communication between storage management systems
US11856090B2 (en) 2021-06-24 2023-12-26 International Business Machines Corporation Data protection optimization
US11916966B2 (en) 2021-07-02 2024-02-27 Adaptiv Networks Inc. Access policy management
US11811917B2 (en) * 2021-07-06 2023-11-07 EMC IP Holding Company LLC System and method for secure authentication of backup clients using short-term tokens
CN113744056A (zh) * 2021-09-07 2021-12-03 辽宁振兴银行股份有限公司 一种联机交易幂等的方法及装置
US12041164B2 (en) * 2021-09-10 2024-07-16 International Business Machines Corporation Encryption key hybrid deployment management
US12126613B2 (en) 2021-09-17 2024-10-22 Nok Nok Labs, Inc. System and method for pre-registration of FIDO authenticators
US20230216662A1 (en) * 2021-12-30 2023-07-06 Arris Enterprises Llc Optimized key management for data signing systems
US11411964B1 (en) * 2022-04-19 2022-08-09 Traceless.Io Security systems and methods for identity verification and secure data transfer
US11997073B2 (en) * 2022-04-25 2024-05-28 Dell Products L.P. Secure certificate storage when a connectivity management system client is running on an operating system
US20240250812A1 (en) * 2023-01-19 2024-07-25 Cisco Technology, Inc. Client-Based Enforcement for Mid-Session Reauthentication
WO2024173886A1 (fr) 2023-02-17 2024-08-22 Magic Labs, Inc. Outil sans garde pour le chiffrement et le déchiffrement de données avec stockage et récupération de données décentralisés
CN118660289B (zh) * 2024-08-19 2024-11-01 烟台大学 一种多任务场景下基于隐私保护的工人选择方法及系统

Family Cites Families (69)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5774552A (en) * 1995-12-13 1998-06-30 Ncr Corporation Method and apparatus for retrieving X.509 certificates from an X.500 directory
US6226618B1 (en) * 1998-08-13 2001-05-01 International Business Machines Corporation Electronic content delivery system
US6959288B1 (en) * 1998-08-13 2005-10-25 International Business Machines Corporation Digital content preparation system
US7181629B1 (en) * 1999-08-27 2007-02-20 Fujitsu Limited Data distribution system as well as data supply device terminal device and recording device for the same
WO2001080565A2 (fr) * 2000-04-17 2001-10-25 Cachestream Corporation Channel dancer
US6950933B1 (en) * 2000-05-19 2005-09-27 Networks Associates Technology, Inc. Method and system for management and notification of electronic certificate changes
US20020007350A1 (en) * 2000-07-11 2002-01-17 Brian Yen System and method for on-demand data distribution in a P2P system
JP4503794B2 (ja) * 2000-07-19 2010-07-14 株式会社日立製作所 コンテンツ提供方法及び装置
JP2002141895A (ja) * 2000-11-01 2002-05-17 Sony Corp コンテンツ配信システムおよびコンテンツ配信方法
JP2002140630A (ja) * 2000-11-01 2002-05-17 Sony Corp チケットに基づくコンテンツ料金精算システムおよびチケットに基づくコンテンツ料金精算方法
US20020107806A1 (en) * 2001-02-02 2002-08-08 Akio Higashi Content usage management system and content usage management method
JP2002229861A (ja) * 2001-02-07 2002-08-16 Hitachi Ltd 著作権保護機能つき記録装置
WO2003014899A1 (fr) * 2001-08-06 2003-02-20 Certco, Inc. Systeme et procede de climat de confiance pour environnements informatiques
US7171554B2 (en) * 2001-08-13 2007-01-30 Hewlett-Packard Company Method, computer program product and system for providing a switch user functionality in an information technological network
WO2003058485A1 (fr) * 2002-01-12 2003-07-17 Coretrust, Inc. Procede et systeme pour la protection des informations d'un contenu numerique
US7395436B1 (en) * 2002-01-31 2008-07-01 Kerry Nemovicher Methods, software programs, and systems for electronic information security
JP3971941B2 (ja) * 2002-03-05 2007-09-05 三洋電機株式会社 データ記憶装置
JP2003271457A (ja) * 2002-03-14 2003-09-26 Sanyo Electric Co Ltd データ記憶装置
JP3862074B2 (ja) * 2002-06-20 2006-12-27 ソニー株式会社 データ通信システム、情報処理装置および方法、並びにプログラム
US7386878B2 (en) * 2002-08-14 2008-06-10 Microsoft Corporation Authenticating peer-to-peer connections
DE10239062A1 (de) * 2002-08-26 2004-04-01 Siemens Ag Verfahren zum Übertragen von verschlüsselten Nutzdatenobjekten
TW200409518A (en) * 2002-08-28 2004-06-01 Matsushita Electric Ind Co Ltd Content-duplication management system, apparatus and method, playback apparatus and method, and computer program
US7558955B2 (en) * 2002-11-20 2009-07-07 Aol Llc, A Delaware Limited Liability Company Method and apparatus for secure instant messaging utilizing server-supervised publication
US7436965B2 (en) * 2003-02-19 2008-10-14 Microsoft Corporation Optical out-of-band key distribution
US7320076B2 (en) 2003-03-05 2008-01-15 Sun Microsystems, Inc. Method and apparatus for a transaction-based secure storage file system
JP2004272669A (ja) * 2003-03-10 2004-09-30 Hitachi Ltd グリッドコンピューティングにおける課金管理方法及び課金管理装置
KR101001048B1 (ko) 2003-04-25 2010-12-14 애플 인크. 보안 네트워크를 통한 콘텐츠의 분배 방법 및 그 시스템
KR100965437B1 (ko) 2003-06-05 2010-06-24 인터트러스트 테크놀로지즈 코포레이션 Ｐ2ｐ 서비스 편성을 위한 상호운용 시스템 및 방법
JP4493653B2 (ja) * 2003-06-24 2010-06-30 インターナショナル・ビジネス・マシーンズ・コーポレーション 分散型アプリケーション環境においてサーバを認証するための方法およびシステム
US7792300B1 (en) 2003-09-30 2010-09-07 Oracle America, Inc. Method and apparatus for re-encrypting data in a transaction-based secure storage system
JP4603256B2 (ja) * 2003-12-01 2010-12-22 日本電気株式会社 ユーザ認証システム
US7636441B2 (en) * 2004-01-12 2009-12-22 Intel Corporation Method for secure key exchange
CN1934582A (zh) * 2004-03-22 2007-03-21 松下电器产业株式会社 内容使用系统、信息终端及结算系统
WO2006033154A1 (fr) * 2004-09-24 2006-03-30 Fujitsu Limited Programme de distribution de contenu
WO2006038622A1 (fr) * 2004-10-06 2006-04-13 Nec Corporation Système de distribution de contenu
JP2006285607A (ja) * 2005-03-31 2006-10-19 Sony Corp コンテンツ情報提供システム，コンテンツ情報提供サーバ，コンテンツ再生装置，コンテンツ情報提供方法，コンテンツ再生方法，およびコンピュータプログラム
US7590939B2 (en) * 2005-06-24 2009-09-15 Microsoft Corporation Storage and utilization of slide presentation slides
US20070011301A1 (en) * 2005-07-11 2007-01-11 Ong Pin P Provisioning relay and re-direction server for service implementation on generic customer premises equipment
US20070043667A1 (en) * 2005-09-08 2007-02-22 Bahman Qawami Method for secure storage and delivery of media content
FR2895611B1 (fr) * 2005-12-23 2008-02-22 Thales Sa Architecture et procede pour controler le transfert d'informations entre utilisateurs
JP5034498B2 (ja) * 2006-02-20 2012-09-26 株式会社日立製作所 ディジタルコンテンツの暗号化，復号方法，及び，ディジタルコンテンツを利用した業務フローシステム
US20070265966A1 (en) * 2006-05-15 2007-11-15 The Directv Group, Inc. Content delivery systems and methods to operate the same
US7613770B2 (en) * 2006-06-30 2009-11-03 Microsoft Corporation On-demand file transfers for mass P2P file sharing
US8015409B2 (en) * 2006-09-29 2011-09-06 Rockwell Automation Technologies, Inc. Authentication for licensing in an embedded system
US20080092239A1 (en) * 2006-10-11 2008-04-17 David H. Sitrick Method and system for secure distribution of selected content to be protected
US8719954B2 (en) * 2006-10-11 2014-05-06 Bassilic Technologies Llc Method and system for secure distribution of selected content to be protected on an appliance-specific basis with definable permitted associated usage rights for the selected content
WO2008114162A1 (fr) * 2007-03-16 2008-09-25 Koninklijke Philips Electronics N.V. Procédés et appareil pour la distribution d'un contenu numérique
US20080235746A1 (en) * 2007-03-20 2008-09-25 Michael James Peters Methods and apparatus for content delivery and replacement in a network
JP5233175B2 (ja) * 2007-06-08 2013-07-10 ソニー株式会社 コンテンツ配信システム、配信サーバ、端末及びコンテンツ配信方法
JP2009005202A (ja) * 2007-06-25 2009-01-08 Ripplex Inc 情報交換装置
KR101447194B1 (ko) * 2007-08-06 2014-10-15 삼성전자주식회사 Ｄｒｍ 에이전트의 공유장치 및 방법
JP5458888B2 (ja) * 2007-09-25 2014-04-02 日本電気株式会社 証明書生成配布システム、証明書生成配布方法およびプログラム
US8544066B2 (en) * 2007-12-27 2013-09-24 Nec Corporation Access right management system, access right management method, and access right management program
WO2009086669A1 (fr) * 2007-12-29 2009-07-16 Thomson Licensing Système et procédé de transmission de données
JP4730626B2 (ja) * 2008-06-13 2011-07-20 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、およびプログラム
KR20100061585A (ko) * 2008-10-09 2010-06-08 삼성전자주식회사 Ｆｏｒｗａｒｄ Ｌｏｃｋ이 설정된 ＤＲＭ 콘텐츠의 처리 방법, 장치 및 시스템
US8510810B2 (en) * 2008-12-23 2013-08-13 Bladelogic, Inc. Secure credential store
WO2010134996A2 (fr) * 2009-05-20 2010-11-25 Intertrust Technologies Corporation Systèmes et procédés de partage de contenu
US9900150B2 (en) * 2009-10-30 2018-02-20 International Business Machines Corporation Dispersed storage camera device and method of operation
US9225525B2 (en) * 2010-02-26 2015-12-29 Red Hat, Inc. Identity management certificate operations
US8898457B2 (en) * 2010-02-26 2014-11-25 Red Hat, Inc. Automatically generating a certificate operation request
US20130061035A1 (en) 2010-03-09 2013-03-07 Lock Box Pty Ltd Method and system for sharing encrypted content
US8751799B2 (en) * 2010-05-20 2014-06-10 Absio Corporation Method and apparatus for providing content
US8483394B2 (en) * 2010-06-15 2013-07-09 Los Alamos National Security, Llc Secure multi-party communication with quantum key distribution managed by trusted authority
EP2625820B1 (fr) * 2010-10-08 2021-06-02 Brian Lee Moffat Système de partage de données privées
US10963584B2 (en) * 2011-06-08 2021-03-30 Workshare Ltd. Method and system for collaborative editing of a remotely stored document
US8732462B2 (en) * 2011-07-07 2014-05-20 Ziptr, Inc. Methods and apparatus for secure data sharing
US20160112413A1 (en) * 2011-10-11 2016-04-21 Tianjin Surdoc Corp. Method for controlling security of cloud storage
US9449183B2 (en) * 2012-01-28 2016-09-20 Jianqing Wu Secure file drawer and safe

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of EP2817917A4 *

Cited By (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9390288B2 (en) 2013-11-01 2016-07-12 Intuit Inc. Method and system for validating a virtual asset
US9418236B2 (en) 2013-11-13 2016-08-16 Intuit Inc. Method and system for dynamically and automatically managing resource access permissions
WO2015084305A1 (fr) * 2013-12-02 2015-06-11 Intel Corporation Procédés, systèmes et appareil de protection de contenu basés sur des personas
US9152806B2 (en) 2013-12-06 2015-10-06 Sony Corporation Computer ecosystem providing privacy and tracking in sharing user-generated content by encrypting the UGC at the imaging source
US9866534B2 (en) 2013-12-06 2018-01-09 Sony Corporation Computer ecosystem providing privacy and tracking in sharing user-generated content
US10360062B2 (en) 2014-02-03 2019-07-23 Intuit Inc. System and method for providing a self-monitoring, self-reporting, and self-repairing virtual asset configured for extrusion and intrusion detection and threat scoring in a cloud computing environment
US9923909B2 (en) 2014-02-03 2018-03-20 Intuit Inc. System and method for providing a self-monitoring, self-reporting, and self-repairing virtual asset configured for extrusion and intrusion detection and threat scoring in a cloud computing environment
US10757133B2 (en) 2014-02-21 2020-08-25 Intuit Inc. Method and system for creating and deploying virtual assets
US10121007B2 (en) 2014-02-21 2018-11-06 Intuit Inc. Method and system for providing a robust and efficient virtual asset vulnerability management and verification service
US9888025B2 (en) 2014-02-27 2018-02-06 Intuit Inc. Method and system for providing an efficient asset management and verification service
US9298927B2 (en) 2014-02-27 2016-03-29 Intuit Inc. Method and system for providing an efficient vulnerability management and verification service
WO2015142715A1 (fr) * 2014-03-18 2015-09-24 Intuit Inc. Procédé et système pour fournir des biens virtuels à capacité d'accès sécurisé
US20160344725A1 (en) * 2014-04-02 2016-11-24 William B. SEVERIN Signal haystacks
WO2015153333A3 (fr) * 2014-04-02 2015-12-30 Severin William B Trains de vagues de signal
US10055247B2 (en) 2014-04-18 2018-08-21 Intuit Inc. Method and system for enabling self-monitoring virtual assets to correlate external events with characteristic patterns associated with the virtual assets
US11294700B2 (en) 2014-04-18 2022-04-05 Intuit Inc. Method and system for enabling self-monitoring virtual assets to correlate external events with characteristic patterns associated with the virtual assets
US9742794B2 (en) 2014-05-27 2017-08-22 Intuit Inc. Method and apparatus for automating threat model generation and pattern identification
US10102082B2 (en) 2014-07-31 2018-10-16 Intuit Inc. Method and system for providing automated self-healing virtual assets
US9516044B2 (en) 2014-07-31 2016-12-06 Intuit Inc. Method and system for correlating self-reporting virtual asset data with external events to generate an external event identification database
US10237706B2 (en) * 2014-11-10 2019-03-19 Alibaba Group Holding Limited Method and apparatus for establishing communication between mobile terminals, incoming communication control and outgoing communication control and system by use thereof
US20160134751A1 (en) * 2014-11-10 2016-05-12 Alibaba Group Holding Limited Method and apparatus for establishing communication between mobile terminals, incoming communication control and outgoing communication control and system by use thereof
US11799861B2 (en) 2017-10-19 2023-10-24 International Business Machines Corporation Secure access management for tools within a secure environment
DE112018004390B4 (de) 2017-10-19 2022-12-08 International Business Machines Corporation Sichere zugriffsverwaltung für werkzeuge innerhalb einer sicheren umgebung
US20210344508A1 (en) * 2018-09-06 2021-11-04 Securosys SA Hardware Security Module that Enforces Signature Requirements
US11088850B2 (en) 2019-03-27 2021-08-10 Advanced New Technologies Co., Ltd. Retrieving public data for blockchain networks using highly available trusted execution environments
US11082240B2 (en) 2019-03-27 2021-08-03 Advanced New Technologies Co., Ltd. Retrieving public data for blockchain networks using highly available trusted execution environments
US11323271B2 (en) 2019-03-27 2022-05-03 Advanced New Technologies Co., Ltd. Retrieving public data for blockchain networks using highly available trusted execution environments
US11449641B2 (en) 2019-03-27 2022-09-20 Advanced New Technologies Co., Ltd. Integrity of communications between blockchain networks and external data sources
US11080430B2 (en) 2019-03-27 2021-08-03 Advanced New Technologies Co., Ltd. Integrity of communications between blockchain networks and external data sources
TWI734426B (zh) * 2019-03-27 2021-07-21 開曼群島商創新先進技術有限公司 使用可信執行環境檢索區塊鏈網路的公開資料
US11095629B2 (en) 2019-03-29 2021-08-17 Advanced New Technologies Co., Ltd. Retrieving access data for blockchain networks using highly available trusted execution environments
US11405372B2 (en) 2019-03-29 2022-08-02 Advanced New Technologies Co., Ltd. Retrieving access data for blockchain networks using highly available trusted execution environments
US20220237595A1 (en) * 2019-06-24 2022-07-28 Blockstar Developments Limited Cryptocurrency key management
US20220188719A1 (en) * 2020-12-16 2022-06-16 Commvault Systems, Inc. Systems and methods for generating a user file activity audit report

Also Published As

Publication number Publication date
US20140351586A1 (en) 2014-11-27
AU2013200916A1 (en) 2013-09-05
AU2013200916B2 (en) 2014-09-11
US20140164776A1 (en) 2014-06-12
WO2013123548A3 (fr) 2014-12-31
EP2817917A2 (fr) 2014-12-31
EP2817917B1 (fr) 2018-04-11
EP2817917A4 (fr) 2016-02-17
US8842841B2 (en) 2014-09-23
IL234215B (en) 2018-01-31

Similar Documents

Publication Publication Date Title
US8842841B2 (en) Cryptographic method and system
US10432394B2 (en) Method and system for sharing encrypted content
EP2396922B1 (fr) Cadre de services et informatique en nuage sécurisé
EP2396921B1 (fr) Cadre de services et informatique en nuage sécurisé
US8707035B2 (en) High privacy of file synchronization with sharing functionality
US9129130B2 (en) Systems and methods for data verification and replay prevention
US9088538B2 (en) Secure network storage
US9160535B2 (en) Truly anonymous cloud key broker
JP2012530391A (ja) 信頼されるコンピューティングサービスおよびデーターサービスのための安全なプライベートバックアップストレージおよび処理
AU2014274590B2 (en) Cryptographic Method and System
CN104348870A (zh) 基于可信时间戳的云存储系统的数据管理方法和系统
US10187360B2 (en) Method, system, server, client, and application for sharing digital content between communication devices within an internet network
Dahshan Data security in cloud storage services
Sánchez‐Artigas et al. StackSync: Attribute‐based data sharing in file synchronization services
Zeidler et al. Towards a framework for privacy-preserving data sharing in portable clouds
Sayler Custos: A flexibly secure key-value storage platform
Gittins et al. Input to the Commission on Enhancing National Cybersecurity
Gawande et al. A Survey of Various Security Management Models for Cloud Computing Storage Systems

Legal Events

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

Ref document number: 13752183

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 234215

Country of ref document: IL

WWE Wipo information: entry into national phase

Ref document number: 2013752183

Country of ref document: EP