WO2015074745A1 - Verfahren, vorrichtungen und system zur online-datensicherung - Google Patents

Verfahren, vorrichtungen und system zur online-datensicherung Download PDF

Info

Publication number
WO2015074745A1
WO2015074745A1 PCT/EP2014/003035 EP2014003035W WO2015074745A1 WO 2015074745 A1 WO2015074745 A1 WO 2015074745A1 EP 2014003035 W EP2014003035 W EP 2014003035W WO 2015074745 A1 WO2015074745 A1 WO 2015074745A1
Authority
WO
WIPO (PCT)
Prior art keywords
document
key
security
terminal
ksec
Prior art date
Application number
PCT/EP2014/003035
Other languages
English (en)
French (fr)
Inventor
Volker Stöhr
Jens Hohmann
Josef Bauer
Frank-Michael Kamm
Original Assignee
Giesecke & Devrient Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke & Devrient Gmbh filed Critical Giesecke & Devrient Gmbh
Publication of WO2015074745A1 publication Critical patent/WO2015074745A1/de

Links

Classifications

    • 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/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/106—Enforcing content protection by specific content processing
    • G06F21/1062—Editing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/045—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply hybrid encryption, i.e. combination of symmetric and asymmetric encryption

Definitions

  • the invention relates to methods, devices and a system for online data backup over a communication network.
  • the invention relates to methods, devices and an on-line data backup system over the Internet.
  • Cloud storage service its data with a personal key, then he can not share this data with other users, which excludes this procedure for corporate purposes. This also applies to zero-knowledge protocols, where a key is derived from a user password. Distributing such a user password to a larger group of users would create significant security risks.
  • the data stored in a cloud storage service is encrypted with a common key, ie a key that is known to several users, then it is not possible for certain users to grant or deny access to certain data flexibly.
  • the data is encrypted with several personal keys and then stored in a cloud storage service, then it is possible to give certain users flexible access to certain data. If, however, subsequently individual users are granted or revoked access, this requires a change in the data in the cloud storage service. In particular, if certain users are to be safely deprived of access, a secure deletion of data stored in the cloud storage service (including all copies) is necessary, which can hardly be realized in practice.
  • the keys are with the users.
  • backup copies of these keys must be created, which in turn constitutes a security risk.
  • Cloud storage services that provide data encryption by themselves typically have the problem that the cloud storage service also has access to the appropriate keys and thus the encrypted data.
  • the object of the present invention is to provide improved methods and devices as well as an improved system for online data backup via a communication network with which the disadvantages described above are eliminated.
  • the present invention is intended to enable conventional partially “insecure" cloud storage services for online backup by fully controlling the encryption of data by the user in conjunction with a trusted entity. Summary of the invention
  • a basic idea of the invention is to provide a security instance, preferably in the form of a security server, which undertakes the flexible but secure management of access to the data stored in a cloud storage service, preferably in the form of a cloud server.
  • a security instance preferably in the form of a security server
  • This allows according to the invention a clear separation of data and keys. While the cloud storage service sees only the encrypted data (but no keys), the security instance sees only keys (but no data). The merging of data and keys takes place only on the terminal of the user.
  • a method for storing an electronic document present on a terminal on a cloud storage service comprises the following steps: the production of a document key Ksec on the terminal; encrypting the electronic document with the document key Ksec and encrypting the document key Ksec with a public key Kss_pub of a security instance; the transfer of a document container to the
  • Cloud storage service where the document container is the same as the document ment key K c se contains encrypted document and the _pub with the public key Ks S of security documents encrypted instance key Ksec; and saving the document container in the cloud storage service.
  • the method comprises the following further steps: transmitting the encrypted document key K se c to the security instance, wherein the security instance with a private key
  • the security authority generates a signature of the preferably encrypted document key Ksec and optionally stores; and receiving the signature of the preferably encrypted document key Ksec by the terminal, the document container further containing the signature generated with the private key Kss_prv of the security instance.
  • the method further comprises the step of generating a document identifier with which the document generated on the terminal can be uniquely identified.
  • the document identifier comprises a document identification number for uniquely identifying a document and a version number for uniquely identifying a version of a document.
  • the document identifier is generated by the security authority.
  • the method comprises the following further steps: the generation of a hash value of the document identifier by the terminal; encrypting the hash value of the document identifier with the public key Ks S _pub of the security instance by the terminal; the transmission of the encrypted hash value of the document identifier to the cherheitsinstanz; and decrypting the encrypted hash of the document identifier and checking the hash value by the security authority.
  • the terminal preferably checks the signature of the document key Ksec generated by the security instance before the document container is transmitted to the cloud storage service.
  • the step of transmitting the encrypted document key Ksec to the security authority further comprises the step of transmitting a signature of the encrypted document key Ksec generated by the terminal with a private key Kusr_prv of the terminal.
  • the security authority verifies the signature sr_prv generated by the terminal with the private key K U of the document key Ksec before the security authority decrypts the encrypted document key Ksec and with the private key Ks S security instance _prv a signature of the document key Ksec generates and stores.
  • the security instance includes a security server and the cloud storage service includes a cloud server.
  • a method for accessing from a terminal to an electronic document which according to a method according to the first aspect of the invention on a
  • the method comprises the following steps: the transfer of the document container to the terminal, wherein the document container the document encrypted with the document key Ksec and the with the public key Ks S _ P ub contains the security instance encrypted document key Ksec; forwarding the document key Ksec encrypted with the public key Kss_pub of the security instance to the security instance; decrypting by the security instance the document key Ksec encrypted with the public key Kss_ P ub of the security instance; encrypting the document key Ksec with a public key K US r_pub of the terminal; transmitting the Ksec encrypted with the public key Kusr_pub of the terminal document key Ksec to the terminal; decrypting the Ksec encrypted with the public key Kusr_ P ub of the terminal document key Ksec with a private key K US r_prv the terminal; and decrypting the encrypted document contained in the document container with the decrypted document key Ksec.
  • the method comprises the following steps: the generation of a new document key Ksec on the terminal; encrypting the modified electronic document with the new document key Ksec and encrypting the new key Ksec document with a public key Ks S _pub a security authority; transferring a new document container to the cloud storage service, wherein the new document container contains the modified document encrypted with the new document key K sec and the new document key Ksec encrypted with the security key's public key Kss_pub; and saving the new document container in the cloud storage service.
  • a method for changing the access rights to an electronic document stored on a cloud storage service in accordance with a method according to the first aspect of the invention is provided.
  • the method comprises the following steps: defining the access rights to the electronic document in the form of a data structure USRS ac is on the terminal; the transfer of the data structure USRS ac is to the security instance; and changing the access rights to the electronic document stored on the cloud storage service according to the data structure USRSacis on the security instance.
  • a terminal adapted to be used in one of the above methods.
  • a security instance preferably in the form of a security server, which is adapted to be used in one of the above methods.
  • a system is provided with such a terminal, such a security instance, and at least one cloud storage service.
  • a terminal such a security instance
  • at least one cloud storage service may be advantageously implemented within the scope of the further aspects of the invention .
  • the present invention offers the following advantages. Data exists in encrypted form on the cloud server. Multiple users can access the data on the cloud server in plain text, provided that they have the appropriate access rights. Even if they manage to read the data from the cloud server, all other users will not be able to handle this data because they can not decrypt it.
  • the invention can be used in conjunction with conventional
  • the invention makes it possible for a company to also access the data of an employee stored in a cloud storage service after it has left the company.
  • FIG. 1 shows a schematic representation of a system with a computer unit, a mobile terminal, a cloud server for storing data and a security server, which illustrates different aspects of the present invention
  • FIG. 2 is an illustration of a preferred flow according to the invention when storing a newly created document on the cloud server of FIG. 1
  • FIG. 3 is an illustration of a preferred flow in retrieving a document stored on the cloud server of FIG. 1, according to the invention
  • FIG. 4 is an illustration of a preferred flow of the invention in modifying a document stored on the cloud server of FIG. 1, and FIG
  • FIG. 5 is an illustration of a preferred flow of the invention for managing user access rights to a document stored on the cloud server of FIG. 1.
  • Figure 1 shows a schematic representation of the components of a system 10 according to the invention as well as some of the communication links between these components, illustrating different aspects of the present invention.
  • a first terminal in the form of a computer unit 30, preferably a personal computer (PC), a tablet computer, a notebook, a netbook, a smartcard or the like, is configured to communicate via a communication network 40 with a cloud storage service, preferably in the form of a cloud server. 50 to store on this cloud server 50 electronic data (for example, on a database 52 of the cloud server 50) and retrieve from there again.
  • a cloud storage service preferably in the form of a cloud server. 50
  • the communication network 40 is the Internet.
  • the communication network 40 may be an intranet or the like.
  • Such cloud servers 50 can generally be accessed by means of a web browser running on the computer unit 30, such as Internet Explorer, Firefox, Google Chrome , Safari or the like, or a corresponding application with a displayed on a display 32 of the computer unit 30 graphical user interface are accessed.
  • a web browser running on the computer unit 30, such as Internet Explorer, Firefox, Google Chrome , Safari or the like, or a corresponding application with a displayed on a display 32 of the computer unit 30 graphical user interface are accessed.
  • a second terminal in the form of a mobile terminal 12, preferably a smartphone or the like, is also configured to communicate via the
  • Communications network 40 to access the cloud storage service 50.
  • the mobile terminal 12 can also be accessed by means of a running web browser with a displayed on a display 14 of the mobile terminal 12 graphical user interface.
  • an application 22 may be installed on the mobile terminal 12 that is configured to access the cloud storage service 50.
  • both the computer unit 30 and the mobile terminal 12 have a particularly secure area, in particular for the storage and processing of safety-critical data.
  • this secured area is preferably in the form of a Trusted Execution Environments (TEE) known to those skilled in the art with a secure memory area 36, in particular a unique user or terminal identifier USRid and a private key K U sr_ P rv the user of the computer unit 30 is deposited.
  • TEE Trusted Execution Environments
  • this secured area is preferably formed by a security element 20, preferably in the form of a SIM card, an eUICC or the like, with a secure memory area 24 in which, in particular, a unique user or terminal identifier USRid and a private key Kusr_prv of the user of the mobile terminal 12 is deposited.
  • the application 22 may be installed on the security element 20 or on another part of the mobile terminal 12.
  • the system 10 shown in FIG. 1 further includes a security instance 60, preferably in the form of a security server, in communication with the other components of the system 10 via the communication network 40.
  • the security server 60 preferably also has a particularly secure area, in particular for the storage and processing of security-critical data.
  • this secured area is preferably in the form of a hardware security module (HSM) 62 with a secure memory area 64 in which, in particular, a private key Kss_prv of the security server 60 is securely stored.
  • HSM hardware security module
  • the security server 60 is configured to manage information about the users and their terminals, the data stored on the cloud server 50, and the users' access rights to those data. to control these access rights and perform cryptographic operations when accessing that data.
  • the security server 60 is generally provided with significantly higher security requirements and significantly lower storage requirements than the cloud server 50.
  • both the security server 60 and the cloud server 50 should be available, ie online.
  • the safety Security server 60 operated by a trusted entity, such as a Trusted Service Manager (TSM).
  • TSM Trusted Service Manager
  • the data stored on the cloud server 50 can be any type of electronic or digital data, such as a Word or Excel file, a PDF document, a photo, an MP3 file and the like. In the following description, for the sake of simplicity, these data will be referred to as an (electronic) document DOC.
  • a document DOC in the form of a document container DOC CO n on the cloud server 50 can be any type of electronic or digital data, such as a Word or Excel file, a PDF document, a photo, an MP3 file and the like.
  • these data will be referred to as an (electronic) document DOC.
  • Stored cloud server 50 or a database 52 of the cloud server 50 which preferably contains the following elements: DOQd, DOCver, ENC (DOC, Ksec), ENC (Ksec
  • the document DOC is present in this document container DOCcon in encrypted form, due to an encryption with a secret document key K se c, which is newly generated for each new document DOC and each new version of a document DOC, preferably by means of a random number generator.
  • a new document DOC is generated on the computer unit 30, which is to be stored on the cloud server 50.
  • the computer unit 30 asks the security server 60 for a document identifier, which preferably consists of a unique document identification number DOGd and a document version number.
  • a document identifier which preferably consists of a unique document identification number DOGd and a document version number.
  • mer DOC ve r The document version number DOC V er serves to differentiate different versions of the document DOC uniquely identified by the document identification number DOGd.
  • the security server 60 sends the document identifier, ie, the unique document identification number DOGd and the document version number DOCver, to the computer unit 30 in step S22 of Fig. 2.
  • the security server 60 can generate the document identifier in that the document identification number DOGd and the document version number DOCver are concatenated with each other, which is indicated by the symbol "
  • the document identification number DOGd and / or the document version number DOCver could in principle also be created by the computer unit 30, it is advantageous that this task is performed by the security server 60, as this can prevent two terminals on which parallel Documents to be stored on cloud server 50 create the same document identification number.
  • the computer unit 30 generates a secret document key Ks ec , for example by means of a random number generator.
  • the document ment DOC is encrypted with the secret document key K sec , ie ENC (DOC, Ksec), for example by means of the AES encryption algorithm; and to ensure authenticity and integrity, by using a one-way function, preferably in the form of a hash function H, the hash values about the document DOC and the document identifier DOQd
  • ENC (X, K) is used in the present application for the encryption of a data element X with the key K.
  • the encryption algorithms designated by ENC may be symmetrical encryption methods, such as DES, AES or the like, or asymmetric encryption methods, such as RSA or the like.
  • DES symmetrical encryption methods
  • RSA RSA
  • the person skilled in the art can recognize from the context whether a symmetrical and / or an asymmetric encryption method can be used according to the invention.
  • the document container DOCcon also contains a signature of the security server 60, which is formed via the data elements contained in the data container DOCcon.
  • the computer unit 30 signs these data elements with their private key Kusr_prv before these are sent to the security server 60, i. the computer unit 30 generates the following signature:
  • SIG (DOC id II DOCver II ENC (Ksec II H (DOC)
  • the computer unit 30 transmits a unique user or terminal identifier USRid, the document identifier (DOGd
  • USRid the document identifier
  • DOCver the document identifier
  • K sec the signature calculated via these data items.
  • M5 the data element referred to as M5 in Figure 2, ie
  • the security server 60 After the security server 60 obtains the data item M5 from the computer unit 30, the security server 60 preferably performs the following checks in step S24 of FIG. First, the security server 60 checks, based on the user or terminal identifier USRid and the document identifier (DOGd
  • the security server 60 decrypts the document key Ksec and the hash values from the document DOC and the document ID docId II DOC V er. Checking the hash value via the document identifier DOCid II DOCver is important for the security of the system, since otherwise a terminal could gain unauthorized access to a foreign document.
  • the security server 60 stores, for example, in a database, the document ID
  • Kss_prv which has been abbreviated in Figure 2 as SIG (M3, K5).
  • This signature sends the security server 60 back to the computer unit 30, which can verify by verifying this signature by means of the public key Ks S _pub the security server 60 of the correctness of the data elements captured with the signature.
  • the document container DOC COn with this signature, so that the completeness ended at the cloud server 50 to be transmitted document container DOC n CO preferably is in the following form:
  • step S26 of FIG. 2 the cloud server 50 stores the document container DOCcon and confirms this to the computer unit 30 by means of a confirmation message.
  • the document key Ksec generated by the computer unit 30 should, after it has been used to encrypt the document DOC and flowed into the document container DOC CO n, be deleted on the computer unit 30, for example after step S23 of FIG.
  • step S31 of Fig. 3 the computer unit 30 sends the document identifier, i. the document identification number DOQd and the version number DOCver, to the cloud server 50 in order to download the associated document container DOCcon stored thereon and uniquely identified by the document identifier onto the computer unit 30 (see step S32 of FIG. 3).
  • Steps S31 or S32 could still include an optional step of authenticating the computer unit 30 to the cloud server 50, but this is not essential to the security of the system 10.
  • step S33 of Figure 3 checks the computer unit 30 contained in the document container DOCcon signature, which is abbreviated in Figure 3 as SIG (M3, K5). Since this is at the key K5 to the private key K SS _prv of the security server 60, the verification of the signature with the public key Ks S _pub of the security server 60, which is defined in Figure 3 as Kl takes place. By means of this check, the computer unit 30 is convinced of the authenticity and integrity of the data contained in the document container DOCcon with the exception of the still encrypted data. present document DOC. The complete check of the document DOC is preferably made at a later date, as described in detail below.
  • the secret document key Ksec is in encrypted form, and, as already described above in connection with Figure 2, as a result of encryption by the computer unit 30 with the public key Ks S _pub of Security server 60. This has the consequence that only the security server 60 can decrypt the encrypted document key Ksec with his private key Ks S _ P rv again.
  • step S33 of Fig. 3 the computer unit 30 sends a request to the security server 60 containing the data item abbreviated as M7 in Fig. 3, preferably with the following elements: the user or terminal identifier USRid, the document identifier
  • the data element M7 can be transmitted unencrypted from the computer unit 30 to the security server 60 in step S33 of FIG. Because an attacker has no way to get to the secret Kesk key, because he has no access to the private key Kss_prv of the security server 60. According to inventive variants, however, this transmission from the computer unit 30 to the security server 60 can also be encrypted, so that an attacker can not find out which documents a user is accessing.
  • step S34 of Figure 3 are performed by the security server 60 based on the transmitted from the computer unit 30 data element M7 several checks. First, the security server 60 checks using the user or terminal identifier USRid and the document identifier
  • DOCid II DOCver that the security server 60 both the user or his terminal and the document DOC are known, and that this user is entitled to with his terminal, i. the computer unit 30 to access the document DOC.
  • the security server 60 verifies the signature SIG (M3, K5) and thus ensures that the encrypted document key Ksec actually belongs to this document DOC.
  • the security server 60 decrypts the encrypted with the public key of the security server 60 part of the transmitted from the computer unit 30 data element M7, i.
  • SIG (DOC id II DOCver
  • the security server 60 sends the re-encrypted data elements and the signature to the computer unit 30. As well as the transmission of the data from the computer unit 30 to the security server 60 in step S33 of Figure 3, these data may also be transmitted unencrypted without the security of the document DOC to endanger. However, if in step S33 of FIG. 3 a secure channel for the transmission of the data has been formed between the computer unit 30 and the security server 60, this secure channel may also be used for the transmission of the data from the security server 60 to the computer unit 30 in step S34 become.
  • the step of decrypting with the private key Kss_prv of the security server 60 is preferably performed in the hardware security module (HSM) 62 of the security server 60.
  • HSM hardware security module
  • the private key Kss_prv of the security server 60 is thereby protected from potential attacks.
  • the encryption, and in particular the secret documents key Ksec by the security server 60 with the user's public key K U sr_pub in step S34 of Figure 3 preferably immediately following also in the HSM 62 instead without the secret documents key Ksec the secure HSM 62 keys leaves. This increases the security in the event that an attack on the security server 60 is successful because the attacker can not access the secret document key Ksec, which is only briefly unencrypted in the secure HSM 62.
  • step S34 of FIG. 3 the signature is preferably calculated in the HSM 62 in order not to subject the private key Kss_prv of the security server 60 to any attacks, even in this case.
  • step S35 of FIG. 3 the computer unit 30 verifies the signature
  • the computer unit 30 uses its private key K US r_prv to obtain the secret document key Ksec and the hash values encrypted together with it in plain text. Subsequently, the computer unit 30 checks the hash value of the document identifier DOGd
  • the document DOC now in plain text, can now be used in the computer unit 30, for example, edited.
  • the private key Kuss_prv user As well as the private key Kss_prv the security server because the private key Kus r 60 _prv user of essential importance for the security of the document DOC, the private key Kusr_prv user, as has already been mentioned above, preferably in a TEE 34 or a security element 20 of the user's terminal. Optimum safety can be achieved by a combination of TEA and a security element to a terminal P rv user stores when the security element r_ the private key K US and used while the TEE a secure keyboard to enter a PIN code to activate the use of the private Keys Kusr_prv of the user and passes this PIN for verification to the security element.
  • a procedure which is preferred according to the invention in the modification of a document DOC stored on the cloud server 50 is described below.
  • Creating a new document container DOCcon requires a new document identifier.
  • the document identifier is changed by keeping the DOGd and creating a new version number DOCver.
  • the new version number DOCver is created by the security server 60, since it can prevent two terminals operating in parallel on the same document DOC from creating the same version number DOCver for different versions of the same document DOC.
  • step S41 of FIG. 4 the document DOC is processed on the computer unit 30 which the user of the computer unit 30 wishes to save on the cloud server 50.
  • the computer unit 30 transmits, as part of a corresponding request, the document identification number DOQd of the document DOC to the security server 60, which in step S42 first checks whether this document identification number DOQd is known to him, that is, for example, a corresponding entry in his database. lies. If so, the security server 60 creates a new version number DOCver, preferably by incrementing the previous version number, and sends the changed version number DOCver back to the computer unit 30.
  • steps S43 to S46 of FIG. 4 described below are partly identical to the above-described steps S23 to S26 of FIG. 2, so that reference may be made in part to the above description of steps S23 to S26 of FIG.
  • the main difference is that in steps S43 to S46 a newly generated document key Ksec is used and a newly generated document container DOCcon is stored on the cloud server 50, which contains the modified document DOC.
  • the new document container can replace the previously deposited on the cloud server 50 document container or alternatively deposited next to the previous document container on the cloud server 50.
  • the computer unit 30 generates a new secret document key Ksec / with which parts of the new document container DOCcon are generated.
  • the edited document DOC is encrypted with the new secret document key Ksec (ENC (DOC, Ksec)).
  • the hash values are calculated via the modified document DOC and the new document identifier by using a one-way function, preferably a hash function H, and together with the new secret document key Ksec with the public key Kss_pub of the security server 60 is encrypted, ie
  • a signature of the security server 60 is added to the new document container DOCcon as another data element.
  • the computer unit 30 signs these data elements with their private key K US r_prv before these are sent to the security server 60, ie the following signature is generated by the computer unit 30:
  • the computer unit 30 sends its user or terminal identifier
  • M5 USRid II DOGd
  • the security server 60 After the security server 60 obtains the data item M5 from the computer unit 30, the security server 60 preferably performs the following checks in step S44 of FIG. First, the security server 60 checks, based on the user or terminal identifier USRid and the new document identifier (DOGd
  • the security server 60 verifies the signature contained in the data element M5 and thus ensures that the data element M5 actually originates from the computer unit 30.
  • the security server 60 decrypts the new document key Ksec and the hash values via the modified document DOC and the modified document sink DOCid
  • DOCver is advantageous for the security of the system according to preferred embodiments of the invention, since otherwise a terminal could gain unauthorized access to a foreign document. If the checks described above were successful, the security server 60 replaces the previous version number DOCver with the new version number DOCver in its database entry for the document identification number DOCid and uses its private key Kss_prv to create the signature required for the document container:
  • Kss_ p rv which has been abbreviated as SIG (M3, K5) in FIG.
  • This signature sends the security server 60 back to the computer unit 30, which can verify in step S45 of Figure 4 by checking this signature by means of the public key Ks S _pub the security server 60 of the correctness of the data elements captured with the signature.
  • the security server 60 can also store the new version number DOCver together with the previous version number DOCver, so that it is possible for old versions to continue to be accessed.
  • the computer unit 30 combines the signature with the already existing data elements to the new document container DOCcon in step S45 of FIG. 4, so that the complete new document container DOCcon to be transmitted to the cloud server 50 is preferably in the following form :
  • the version number DOCver, the document DOC and the document key K se c and the data elements derived therefrom have changed in the new document container compared to the previous document container described in connection with FIGS. 2 and 3.
  • step S46 of FIG. 4 the cloud server 50 stores the new document container DOCcon and confirms this to the computer unit 30 by means of a confirmation message.
  • the new document container replace the previously stored on the cloud server 50 document container or alternatively deposited next to the previous document container on the cloud server 50 so that both versions of the document can be accessed.
  • the security server 60 implicitly grants the user who creates the document DOC access to his document DOC, for example by sharing these access rights together with the other data of the document DOC are stored in a database of the security server 60, as has been described above in connection with Figure 2.
  • these original access rights also include the right to grant other users or other terminals access to the document DOC, which is stored on the cloud server 50 in the form of a document container DOQon.
  • the user selects on his terminal, such as the computer unit 30, an additional user or an additional terminal, such as the mobile terminal 12, from which he wants to grant access to the document DOC.
  • the terminals and the respective access rights are encoded in a suitable data structure.
  • This data structure identified as USRS acis in Figure 5, may be based on access control lists (ACLs) well known to those skilled in the art.
  • ACLs access control lists
  • the computer unit 30 preferably generates a data element from its own user or terminal identifier USRid, the document identification number DOCid and the data structure USRSacis, as well as a signature via these elements, which is generated with the private key K U sr_prv of the computer unit 30 that under a request for changing the user access rights to the security server 60.
  • step S52 of FIG. 5 the security server 60 checks, based on the user or terminal identifier USRi d and the document identification number DOQd, that the security server 60 knows both the user or his computer unit 30 and the document DOC linked to the document identification number DOCid. and that the user or his computer unit 30 is authorized to manage the access rights to this document DOC.
  • the security server 60 examines the additional user or terminal identifiers USRid contained in the data structure USRS ac is and verifies the signature to ensure that the corresponding request actually comes from the computer unit 30.
  • the security server 60 enters the access rights defined in the data structure USRS ac is in the entry to the document DOC of its database and confirms to the computer unit 30 the successful change of the access rights to the document DOC.
  • the document identification number DOCid is a unique identifier for a document DOC, which may be in different versions. All versions of this document DOC have the same DOCid.
  • the Ver- unions DOCver clearly identifies a specific version of the document DOC.
  • the cloud server 50 considers different versions of a document DOC as belonging together or as independent documents. If the cloud server 50 manages contiguous versions of a document DOC contiguously, then further meaningful functions of the cloud server 50 are possible according to the invention, e.g. querying a list of all present version numbers DOCver for a document identification number DOGd, querying the latest version number for a DOGd and reading the latest version of a document with a particular DOGd.
  • the invention does not impose any conditions on the design of the document identification number DOGd and the version number DOCver.
  • the document identification number DOCid and the version number DOCver may be any (but) unique strings rather than numbers.
  • Possible formats for the document identification number are e.g. Decimal numbers, text, binary numbers, URLs (Universal Resource Locators), UUIDs (Universal Unique Identifiers).
  • the invention does not impose conditions on the length of the document identification number DOGd and the version number DOC ver .
  • a maximum length for the document identification number DOGd and / or the version number DOCver be defined.
  • it may be advantageous, the above in connection with the figures To simplify procedures described 2 to 5 in that instead of the hash value of the Dokumentenident ceremoniessnurnmer DOQd and / or the version number DOC ve r the document identification number DOGd and / or the version number DOCver can be used directly.
  • the document identification numbers DOCid and / or version numbers DOCver can be generated, for example, by the security server 60, as described above, the cloud server 50 and / or the terminal 30. Preferably, consecutive numbers are used, possibly in conjunction with an identification number of the generating point. Alternatively, randomly generated values can be assigned, provided that the value space and the used random number generator can guarantee the uniqueness of the values with a sufficient probability.
  • the version number DOCver is preferably a numeric value starting at 0 and incremented by 1 with each new version.
  • the access rights of the users are preferably stored on the security server 60, for example in the form of the data structure USRS ac is, on respective documents, which in turn are stored in the form of document containers DOC CO n on the cloud server 50.
  • a multiplicity of different rights can be defined on the security server 60. Examples of typical rights include creating a new document DOC, reading, modifying, and deleting a document stored on cloud server 50, as well as managing access rights for other users or devices.
  • the security server 60 preferably stores information about which user (or which terminal) is the creator of a modified document DOC and thus a new version number DOCver.
  • the management of access rights runs independently of the cloud server 50, since these only regulate the interaction between security server 60 and computer unit 30.
  • a separate administration of access rights via which the writing and reading of the document container DOCcon can be controlled by the computer unit 30 can also be implemented on the cloud server 50.
  • a document container DOCcon stored on the cloud server 50 neither direct information (eg in the form of the user or terminal identifier USRid) nor indirect information (eg in the form of a signature created with the private key of the user Kusr_prv) about the author of the document included.
  • information about the author of a document is preferably stored on the security server 60 in connection with the document identification number DOGd and the version number DOCver of a document DOC.
  • the authenticity and integrity of a document container DOC con is preferably protected by a signature created by the security server 60 with its private key Ks S _ P rv.
  • this signature preferably does not extend over all the data contained in the document container DOCcon, but only via the document identifier (DOGd and DOCver) and the encrypted data elements.
  • the document DOC encrypted with the document key K sec does not flow directly into the signature calculation, since it is not part of the request from the computer unit 30 to the security server 60 for filing a new or a modified document DOC on the cloud server 50 is transmitted to the security server 60.
  • the authenticity and integrity of the document DOC is indirectly protected by the signature since, according to the preferred embodiments of the invention described above, the hash value of the document DOC is contained in the data element M1. For this purpose, however, according to preferred embodiments of the invention, it should be ensured that the security server 60 is provided with the correct hash value via the document DOC for generating the signature of the security server 60.
  • the secret document key Ksec is preferably encrypted together with the hash value via the document identifier (DOCid and DOCver) (see, for example, step S23 of FIG. 2 or step S43 of FIG. 4).
  • DOCid and DOCver the document identifier
  • the steps S21 and S22 in FIG. 2 it is not absolutely necessary for the steps S21 and S22 in FIG. 2 to be particularly secured.
  • An attacker could, by means of a large number of requests, generate a multiplicity of document identification numbers DOGd by the security server 60, which are then no longer available to other users, or document identification numbers martialized to form a "man in the middle" attack on other users Send DOGd.
  • this would not result in the attacker gaining unauthorized access to foreign documents.
  • the steps S21 and S22 can be additionally secured, for example by means of an authentication and / or an encryption.
  • the security server 60 in addition to the asymmetric key pair (K ss _ P rv and Ks S _pub) could also have a symmetric key K ss _sec, which is known exclusively to the security server 60.
  • this symmetric key Ks sec At S can be used instead of the public key to encrypt the secret key Ksec documents and the documents in the container DOC CO n hashes contained.
  • the security server 60 further decrypts the message M2 with its private key Ks S _prv.
  • the decrypted data elements of the message M2 are now encrypted with the symmetric key Kss_sec of the security server 60 and the signature is encrypted using the symmetric key Kss_sec of the security server 60. keyed data formed.
  • the 60 encrypted data using the symmetric key Ks S sec At the security server is transmitted together with the signature it to the computer unit 30. Fig. Then, the computer unit 30 completes the document container DOCcon by the data encrypted with the symmetric key Ks S e C of the security server 60.
  • the advantage of this variant is that the decryption of the secret document key Ksec with the symmetric key Kss_sec of the security server 60 is generally faster than the decryption of the secret document key Ksec with the private key Ks S _prv of the security server 60.
  • the security server 60 could be configured to facilitate the aggregation of individual users into user groups. This would be particularly important in the corporate environment.
  • the groups then form departments, projects or working groups. Individual users can belong to several groups. Groups and users can belong to other groups, so departments can be grouped into areas, which in turn can be grouped into even larger units, right through to the entire company.
  • the access rights to a document DOC can then be granted to individual users and to groups.
  • each user is assigned exactly one terminal.
  • the combination of user and terminal is identified via a user or terminal identifier USRid which has a private key K US r_prv.
  • the invention can also be applied to cases where a user uses a plurality of terminals, eg, a PC and a smartphone. But even the case of multiple users per terminal is covered by the invention.
  • either each intended combination of user and terminal can get their own USRid or separate user IDs and terminal IDs are assigned.
  • a user can use different private keys on different terminals.
  • the security server 60 knows the assignment of users and terminals and supports access rights to documents both for certain users in general and for certain users with certain terminals.
  • the security server 60 could grant access rights to users, regardless of the terminal being used.
  • a particularly critical document DOC may only be accessed by a specific terminal, eg a stationary PC within a company, and not by a smartphone that is more easily lost or stolen.
  • the security server 60 can generally block access for a stolen or lost device, while the user continues to use other devices can access the documents.
  • a single identifier could be used. This could be advantageous, for example, if this identifier is assigned by the cloud server 50. In this case, however, it may no longer be possible to recognize from the identifiers which document containers DOC CO n contain different versions of a document DOC. These links could then be mapped by security server 50.
  • the present invention offers the following advantages.
  • Full control of the cryptographic keys is on the user's side, within a user-controlled secure environment.
  • the cloud server does not need any special security measures, so it can be an arbitrary rented server.
  • Existing cloud servers do not need to be specially modified so that known cloud storage services can be used.
  • the security server can subsequently exclude individual devices from access in order to protect the security of the documents in the event of the loss or theft of a device.
  • the security server has access to all documents so that, for example, a company can still access documents from employees who no longer work for the company.
  • a security server can manage document access for any number of cloud servers and any number of users or devices.
  • the security server needs up to that Encrypting and decrypting the secret document key Ks ec and the signing of small data packets compared to the cloud server no large computing power, also only manageable storage space and a relatively low-bandwidth Internet connection.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Es werden ein Verfahren, Vorrichtungen und ein System zur Speicherung eines elektronischen Dokuments, das auf einem Endgerät vorliegt, auf einem Cloudspeicherdienst bereitgestellt. Dabei umfasst das Verfahren die folgenden Schritte: das Erzeugen eines Dokumentenschlüssels Ksec auf dem Endgerät; das Verschlüsseln des elektronischen Dokuments mit dem Dokumenten- Schlüssel Ksec und das Verschlüsseln des Dokumentenschlüssels Ksec mit einem öffentlichen Schlüssel Kss_Pub einer Sicherheitsinstanz; das Übertragen eines Dokumentencontainers an den Cloudspeicherdienst, wobei der Dokumentencontainer das mit dem Dokumentenschlüssel Ksec verschlüsselte Dokument und den mit dem öffentlichen Schlüssel Kss_pub der Sicherheitsinstanz verschlüsselten Dokumentenschlüssel Ksec enthält; und das Abspeichern des Dokumentencontainers im Cloudspeicherdienst.

Description

Verfahren, Vorrichtungen und System zur
Online-Datensicherung
Gebiet der Erfindung
Die Erfindung betrifft Verfahren, Vorrichtungen und ein System zur Online- Datensicherung über ein Kommunikationsnetzwerk. Insbesondere betrifft die Erfindung Verfahren, Vorrichtungen und ein System zur Online- Datensicherung über das Internet.
Hintergrund der Erfindung
Im Internet bzw. World Wide Web gibt es eine Vielzahl von Webdiensten, welche die Online-Datensicherung sowie die Synchronisation von Daten zwischen verschiedenen Computern und Personen ermöglichen. Der Zugriff auf derartige sogenannte Cloudspeicherdienste, wie beispielsweise Dropbox, SkyDrive, Google Drive, erfolgt in der Regel mittels eines Webbrowsers oder einer Applikation auf einem Computer.
Bei herkömmlichen Cloudspeicherdiensten können jedoch verschiedene Sicherheitsprobleme auftreten. Falls die Daten unverschlüsselt gespeichert werden, sind diese für manche Anwendungsfälle gegen ein unbefugtes Auslesen nicht ausreichend geschützt. Verschlüsselt ein Benutzer eines
Cloudspeicherdienstes seine Daten mit einem persönlichen Schlüssel, dann kann er diese Daten nicht mit anderen Benutzern teilen, was dieses Vorgehen für Unternehmenszwecke ausschließt. Dies gilt ebenso für Zero- Knowledge-Protokolle, bei denen aus einem Benutzerpasswort ein Schlüssel abgeleitet wird. Die Verteilung eines solchen Benutzerpassworts an eine größere Gruppe von Benutzern würde zu erheblichen Sicherheitsrisiken führen. Werden die bei einem Cloudspeicherdienst hinterlegten Daten mit einem gemeinsamen Schlüssel verschlüsselt, d.h. mit einem Schlüssel, den mehrere Benutzer kennen, dann ist es nicht möglich, bestimmten Benutzern flexibel den Zugriff auf bestimmte Daten zu gewähren oder zu verwehren. Werden die Daten mit mehreren persönlichen Schlüsseln verschlüsselt und dann bei einem Cloudspeicherdienst abgelegt, dann ist es zwar möglich, bestimmten Benutzern flexibel den Zugriff auf bestimmte Daten zu gewähren. Soll allerdings nachträglich einzelnen Benutzern der Zugriff erteilt oder entzogen werden, so erfordert dies eine Änderung der Daten im Cloudspeicherdienst. Insbesondere wenn bestimmten Benutzern der Zugriff sicher entzogen werden soll, ist dazu ein sicheres Löschen von im Cloudspeicherdienst gespeicherten Daten (incl. aller Kopien) notwendig, was sich in der Praxis kaum realisieren lässt.
Bei den vorstehend genannten Varianten, bei denen die Daten auf einem Server des Cloudspeicherdienstes verschlüsselt gespeichert werden, befinden sich die Schlüssel bei den Benutzern. Damit bei Verlust eines Schlüssels nicht der Zugriff auf die verschlüsselten Daten unmöglich wird, müssen Sicherungskopien dieser Schlüssel angelegt werden, was wiederum ein Sicherheitsrisiko darstellt.
Bei Cloudspeicherdiensten, die von sich aus eine Verschlüsselung der Daten anbieten, besteht in der Regel das Problem, dass auch der Cloudspeicherdienst Zugriff auf die entsprechenden Schlüssel und damit die verschlüsselten Daten hat.
Vor diesem Hintergrund stellt sich der vorliegenden Erfindung die Aufgabe, verbesserte Verfahren und Vorrichtungen sowie ein verbessertes System zur Online-Datensicherung über ein Kommunikationsnetzwerk bereitzustellen, mit denen die vorstehend beschriebenen Nachteile behoben werden. Insbesondere soll es die vorliegende Erfindung ermöglichen, herkömmliche teilweise "unsichere" Cloudspeicherdienste zur Online-Datensicherung sicher nutzen zu können, indem die Kontrolle der Schlüssel zur Verschlüsselung der Daten vollständig durch den Benutzer in Verbindung mit einer vertrauenswürdigen Instanz erfolgt. Zusammenfassung der Erfindung
Die vorstehende Aufgabe wird gemäß der vorliegenden Erfindung durch den jeweiligen Gegenstand der unabhängigen Ansprüche gelöst. Bevorzugte Ausgestaltungen der Erfindung werden in den abhängigen Ansprüchen definiert.
Ein Grundgedanke der Erfindung besteht darin, eine Sicherheitsinstanz, vorzugsweise in Form eines Sicherheitsservers, vorzusehen, welche die flexible, aber sichere Verwaltung des Zugriffs auf die bei einem Cloudspeicherdienst, vorzugsweise in Form eines Cloudservers, gespeicherten Daten übernimmt. Dies erlaubt erfindungsgemäß eine klare Trennung von Daten und Schlüsseln. Während der Cloudspeicherdienst nur die verschlüsselten Daten zu sehen bekommt (aber keine Schlüssel), sieht die Sicherheitsinstanz nur Schlüssel (aber keine Daten). Die Zusammenführung von Daten und Schlüsseln erfolgt erst auf dem Endgerät des Benutzers.
Dementsprechend wird gemäß einem ersten Aspekt der Erfindung ein Verfahren zur Speicherung eines elektronischen Dokuments, das auf einem Endgerät vorliegt, auf einem Cloudspeicherdienst bereitgestellt. Dabei um- fasst das Verfahren die folgenden Schritte: das Erzeugen eines Dokumenten- schlüsseis Ksec auf dem Endgerät; das Verschlüsseln des elektronischen Dokuments mit dem Dokumentenschlüssel Ksec und das Verschlüsseln des Dokumentenschlüssels Ksec mit einem öffentlichen Schlüssel Kss_pub einer Sicherheitsinstanz; das Übertragen eines Dokumentencontainers an den
Cloudspeicherdienst, wobei der Dokumentencontainer das mit dem Doku- mentenschlüssel Ksec verschlüsselte Dokument und den mit dem öffentlichen Schlüssel KsS_pub der Sicherheitsinstanz verschlüsselten Dokumentenschlüssel Ksec enthält; und das Abspeichern des Dokumentencontainers im Cloudspei- cherdienst.
Vorzugsweise umfasst das Verfahren die folgenden weiteren Schritte: das Übertragen des verschlüsselten Dokumentenschlüssels Ksec an die Sicherheitsinstanz, wobei die Sicherheitsinstanz mit einem privaten Schlüssel
Kss_Prv der Sicherheitsinstanz eine Signatur des vorzugsweise verschlüsselten Dokumentenschlüssels Ksec erzeugt und gegebenenfalls speichert; und das Empfangen der Signatur des vorzugsweise verschlüsselten Dokumentenschlüssels Ksec durch das Endgerät, wobei der Dokumentencontainer ferner die mit dem privaten Schlüssel Kss_prv der Sicherheitsinstanz erzeugte Signatur enthält.
Gemäß bevorzugter Ausführungsformen der Erfindung umfasst das Verfahren ferner den Schritt des Erzeugens einer Dokumentenkennung, mit der das auf dem Endgerät erzeugte Dokument eindeutig identifiziert werden kann. Vorzugsweise umfasst die Dokumentenkennung eine Dokumentenidentifi- kationsnummer zur eindeutigen Identifizierung eines Dokuments und eine Versionsnummer zur eindeutigen Identifizierung einer Version eines Dokuments. Vorzugsweise wird die Dokumentenkennung von der Sicherheitsinstanz erzeugt. Vorzugsweise umfasst das Verfahren die folgenden weiteren Schritte: das Erzeugen eines Hashwertes der Dokumentenkennung durch das Endgerät; das Verschlüsseln des Hashwertes der Dokumentenkennung mit dem öffentlichen Schlüssel KsS_pub der Sicherheitsinstanz durch das Endgerät; das Übertragen des verschlüsselten Hashwertes der Dokumentenkennung an die Si- cherheitsinstanz; und das Entschlüsseln des verschlüsselten Hashwertes der Dokumentenkennung und das Prüfen des Hashwertes durch die Sicherheitsinstanz. Vorzugsweise überprüft das Endgerät die von der Sicherheitsinstanz erzeugte Signatur des Dokumentenschlüssels Ksec, bevor der Dokumentencontainer an den Cloudspeicherdienst übertragen wird.
Gemäß bevorzugter Ausführungsformen der Erfindung umf asst der Schritt des Übertragens des verschlüsselten Dokumentenschlüssels Ksec an die Sicherheitsinstanz ferner den Schritt des Übertragens einer Signatur des verschlüsselten Dokumentenschlüssels Ksec, die von dem Endgerät mit einem privaten Schlüssel Kusr_prv des Endgeräts erzeugt wird. Vorzugsweise überprüft die Sicherheitsinstanz die vom Endgerät mit dem privaten Schlüssel KUsr_prv erzeugte Signatur des Dokumentenschlüssels Ksec, bevor die Sicherheitsinstanz den verschlüsselten Dokumentenschlüssel Ksec entschlüsselt und mit dem privaten Schlüssel KsS_prv der Sicherheitsinstanz eine Signatur des Dokumentenschlüssels Ksec erzeugt und speichert. Vorzugsweise umf asst die Sicherheitsinstanz einen Sicherheitsserver und der Cloudspeicherdienst einen Cloudserver.
Gemäß einem weiteren Aspekt der Erfindung wird ein Verfahren zum Zugreifen von einem Endgerät auf ein elektronisches Dokument, das gemäß einem Verfahren gemäß dem ersten Aspekt der Erfindung auf einem
Cloudspeicherdienst gespeichert worden ist, bereitgestellt. Dabei umfasst das Verfahren die folgenden Schritte: das Übertragen des Dokumentencontainers an das Endgerät, wobei der Dokumentencontainer das mit dem Dokumentenschlüssel Ksec verschlüsselte Dokument und den mit dem öffentli- chen Schlüssel KsS_Pub der Sicherheitsinstanz verschlüsselten Dokumentenschlüssel Ksec enthält; das Weiterleiten des mit dem öffentlichen Schlüssel Kss_pub der Sicherheitsinstanz verschlüsselten Dokumentenschlüssels Ksec an die Sicherheitsinstanz; das Entschlüsseln des mit dem öffentlichen Schlüssel Kss_Pub der Sicherheitsinstanz verschlüsselten Dokumentenschlüssels Ksec durch die Sicherheitsinstanz; das Verschlüsseln des Dokumentenschlüssels Ksec mit einem öffentlichen Schlüssel KUSr_pub des Endgeräts; das Übertragen des mit dem öffentlichen Schlüssel Kusr_pub des Endgeräts verschlüsselten Dokumentenschlüssel Ksec an das Endgerät; das Entschlüsseln des mit dem öffentlichen Schlüssel Kusr_Pub des Endgeräts verschlüsselten Dokumentenschlüssels Ksec mit einem privaten Schlüssel KUSr_prv des Endgeräts; und das Entschlüsseln des im Dokumentencontainer enthaltenen verschlüsselten Dokuments mit dem entschlüsselten Dokumentenschlüssel Ksec. Gemäß einem weiteren Aspekt der Erfindung wird ein Verfahren zum Abspeichern eines auf einem Endgerät modifizierten elektronischen Dokuments, das gemäß einem Verfahren gemäß dem ersten Aspekt der Erfindung auf einem Cloudspeicherdienst gespeichert worden ist, bereitgestellt. Dabei umfasst das Verfahren die folgenden Schritte: das Erzeugen eines neuen Do- kumentenschlüssels Ksec auf dem Endgerät; das Verschlüsseln des modifizierten elektronischen Dokuments mit dem neuen Dokumentenschlüssel Ksec und das Verschlüsseln des neuen Dokumentenschlüssels Ksec mit einem öffentlichen Schlüssel KsS_pub einer Sicherheitsinstanz; das Übertragen eines neuen Dokumentencontainers an den Cloudspeicherdienst, wobei der neue Dokumentencontainer das mit dem neuen Dokumentenschlüssel Ksec verschlüsselte modifizierte Dokument und den mit dem öffentlichen Schlüssel Kss_pub der Sicherheitsinstanz verschlüsselten neuen Dokumentenschlüssel Ksec enthält; und das Abspeichern des neuen Dokumentencontainers im Cloudspeicherdienst. Gemäß einem weiteren Aspekt der Erfindung wird ein Verfahren zum Ändern der Zugriffsrechte auf ein elektronisches Dokument, das gemäß einem Verfahren gemäß dem ersten Aspekt der Erfindung auf einem Cloudspeicherdienst gespeichert worden ist, bereitgestellt. Dabei umfasst das Verfah- ren die folgenden Schritte: das Definieren der Zugriffsrechte auf das elektronische Dokument in Form einer Datenstruktur USRSacis auf dem Endgerät; das Übertragen der Datenstruktur USRSacis an die Sicherheitsinstanz; und das Ändern der Zugriffsrechte auf das auf dem Cloudspeicherdienst gespeicherte elektronische Dokument gemäß der Datenstruktur USRSacis auf der Sicherheitsinstanz.
Gemäß einem weiteren Aspekt der Erfindung wird ein Endgerät bereitgestellt, das dazu ausgestaltet ist, im Rahmen eines der vorstehenden Verfahren eingesetzt zu werden.
Gemäß einem weiteren Aspekt der Erfindung wird eine Sicherheitsinstanz, vorzugsweise in Form eines Sicherheitsservers, bereitgestellt, die dazu ausgestaltet ist, im Rahmen eines der vorstehenden Verfahren eingesetzt zu werden.
Gemäß einem weiteren Aspekt der Erfindung wird ein System mit einem solchen Endgerät, einer solchen Sicherheitsinstanz und wenigstens einem Cloudspeicherdienst bereitgestellt. Wie der Fachmann erkennt, lassen sich die vorstehend beschriebenen bevorzugten Ausgestaltungen im Rahmen des ersten Aspekts der Erfindung, d.h. im Rahmen des Verfahrens zur Speicherung eines elektronischen Dokuments, das auf einem Endgerät vorliegt, auf einem Cloudspeicherdienst, im Rahmen der weiteren Aspekte der Erfindung vorteilhaft implementieren. Die vorliegende Erfindung bietet insbesondere die folgenden Vorteile. Daten liegen in verschlüsseltet Form auf dem Cloudserver vor. Es können mehrere Benutzer auf die Daten auf dem Cloudserver im Klartext zugreifen, sofern sie über die entsprechenden Zugriffsrechte verfügen. Selbst wenn sie es schaffen, die Daten aus dem Cloudserver auszulesen, können alle anderen Benutzer mit diesen Daten nichts anfangen, da sie diese nicht entschlüsseln können. Die Erfindung lässt sich in Verbindung mit herkömmlichen
Cloudspeicherdiensten ohne große Änderungen implementieren und kann insbesondere im Unternehmensumfeld vorteilhaft eingesetzt werden. Denn die Erfindung ermöglicht es beispielsweise, dass ein Unternehmen auch auf die bei einem Cloudspeicherdienst gespeicherten Daten eines Mitarbeiters zugreifen kann, nachdem dieser das Unternehmen verlassen hat.
Weitere Merkmale, Vorteile und Aufgaben der Erfindung gehen aus der f ol- genden detaillierten Beschreibung mehrerer Ausführungsbeispiele und Ausführungsalternativen hervor. Es wird auf die Zeichnungen verwiesen, in denen zeigen:
Fig. 1 eine schematische Darstellung eines Systems mit einer Computerein- heit, einem mobilen Endgerät, einem Cloudserver zur Speicherung von Daten und einem Sicherheitsserver, die unterschiedliche Aspekte der vorliegenden Erfindung illustriert,
Fig. 2 eine Darstellung eines erfindungsgemäß bevorzugten Ablaufs bei der Speicherung eines neu erstellten Dokuments auf dem Cloudserver von Figur 1, Fig. 3 eine Darstellung eines erfindungsgemäß bevorzugten Ablaufs beim Abrufen eines auf dem Cloudserver von Figur 1 gespeicherten Dokuments,
Fig. 4 eine Darstellung eines erfindungsgemäß bevorzugten Ablaufs bei der Modifizierung eines auf dem Cloudserver von Figur 1 gespeicherten Dokuments, und
Fig. 5 eine Darstellung eines erfindungsgemäß bevorzugten Ablaufs beim Verwalten der Benutzerzugriffsrechte auf ein auf dem Cloudserver von Figur 1 gespeichertes Dokument.
Figur 1 zeigt eine schematische Darstellung der Komponenten eines erfindungsgemäßen Systems 10 sowie einige der Kommunikationsverbindungen zwischen diesen Komponenten, die unterschiedliche Aspekte der vorliegenden Erfindung illustriert.
Ein erstes Endgerät in Form einer Computereinheit 30, vorzugsweise ein Personal Computer (PC), ein Tablett Computer, ein Notebook, ein Netbook, eine Smartcard oder dergleichen, ist dazu ausgestaltet, über ein Kommunikationsnetzwerk 40 auf einen Cloudspeicherdienst, vorzugsweise in Form eines Cloudservers, 50 zuzugreifen, um auf diesem Cloudserver 50 elektronische Daten zu speichern (beispielsweise auf einer Datenbank 52 des Cloudservers 50) und von dort wieder abzurufen. Vorzugsweise handelt es sich bei dem Kommunikationsnetzwerk 40 um das Internet. Alternativ kann es sich bei dem Kommunikationsnetzwerk 40 um ein Intranet oder dergleichen handeln. Auf derartige Cloudserver 50, wie diese dem Fachmann unter den Namen Dropbox, Skydrive, Google Drive, Amazon Cloud Services und dergleichen bekannt sind, kann in der Regel mittels eines auf der Computereinheit 30 laufenden Webbrowsers, wie beispielsweise Internet Explorer, Firef ox, Google Chrome, Safari oder dergleichen, oder einer entsprechenden Applikation mit einer auf einem Display 32 der Computereinheit 30 dargestellten graphischen Benutzeroberfläche zugegriffen werden.
Ein zweites Endgerät in Form eines mobilen Endgeräts 12, vorzugsweise ein Smartphone oder dergleichen, ist ebenfalls dazu ausgestaltet, über das
Kommunikationsnetzwerk 40 auf den Cloudspeicherdienst 50 zuzugreifen. Mittels des mobilen Endgeräts 12 kann ebenfalls mittels eines darauf laufenden Webbrowsers mit einer auf einem Display 14 des mobilen Endgeräts 12 dargestellten graphischen Benutzeroberfläche zugegriffen werden. Alterna- tiv kann auf dem mobilen Endgerät 12 eine Applikation 22 installiert sein, die dazu ausgestaltet ist, auf den Cloudspeicherdienst 50 zuzugreifen.
Vorzugsweise verfügen sowohl die Computereinheit 30 als auch das mobile Endgerät 12 über einen besonders gesicherten Bereich, insbesondere zur Speicherung und Verarbeitung von sicherheitskritischen Daten. Bei der
Computereinheit 30 ist dieser gesicherte Bereich vorzugsweise in Form eines dem Fachmann bekannten Trusted Execution Environments (TEE) 34 mit einem gesicherten Speicherbereich 36 ausgebildet, in dem insbesondere eine eindeutige Benutzer- oder Endgerätkennung USRid sowie ein privater Schlüssel KUsr_Prv des Benutzers der Computereinheit 30 hinterlegt ist. Bei dem mobilen Endgerät 12 ist dieser gesicherte Bereich vorzugsweise durch ein Sicherheitselement 20, vorzugsweise in Form einer SIM-Karte, einer eUICC oder dergleichen, mit einem gesicherten Speicherbereich 24 ausgebildet, in dem insbesondere eine eindeutige Benutzer- oder Endgerätkennung USRid sowie ein privater Schlüssel Kusr_prv des Benutzers des mobilen Endgeräts 12 hinterlegt ist. Die Applikation 22 kann auf dem Sicherheitselement 20 oder auf einem anderen Teil des mobilen Endgeräts 12 installiert sein. Wie dies nachstehend im Detail beschrieben wird, umfasst das in Figur 1 dargestellte System 10 ferner eine Sicherheitsinstanz 60, vorzugsweise in Form eines Sicherheitsservers, die über das Kommunikationsnetzwerk 40 in Kommunikation mit den anderen Komponenten des Systems 10 steht. Vorzugsweise verfügt ebenso der Sicherheitsserver 60 über einen besonders ge- sicherten Bereich, insbesondere zur Speicherung und Verarbeitung von sicher heitskritschen Daten. Bei dem Sicherheitsserver 60 ist dieser gesicherte Bereich vorzugsweise in Form eines Hardware-Sicherheitsmoduls (HSM; hardware security module) 62 mit einem gesicherten Speicherbereich 64 ausgebildet, in dem insbesondere ein privater Schlüssel Kss_prv des Sicher- heitsservers 60 sicher hinterlegt ist.
Wie sich dies aus der nachstehenden detaillierten Beschreibung erfindungsgemäß bevorzugter Verfahrensabläufe ergibt, ist der Sicherheitsserver 60 dazu ausgestaltet, Informationen zu verwalten, und zwar über die Benutzer und deren Endgeräte, über die auf dem Cloudserver 50 gespeicherten Daten sowie die Zugriffsrechte der Benutzer auf diese Daten, diese Zugriffsrechte zu kontrollieren und beim Zugriff auf diese Daten kryptographische Operationen durchzuführen. Anhand der nachstehenden detaillierten Beschreibung wird der Fachmann erkennen, dass erfindungsgemäß in der Regel an den Sicherheitsserver 60 deutlich höhere Sicherheitsanforderungen und deutlich niedrigere Speicherplatzanforderungen als an den Cloudserver 50 gestellt werden. Für das Abspeichern von Daten und/oder das Zugreifen auf Daten sollten erfindungsgemäß sowohl der Sicherheitsserver 60 als auch der Cloudserver 50 verfügbar, d.h. online sein. Vorzugsweise wird der Sicher- heitsserver 60 von einer vertrauenswürdigen Instanz betrieben, beispielsweise einem Trusted Service Manager (TSM).
Bei den auf dem Cloudserver 50 hinterlegten Daten kann es sich um jede Art von elektronischen bzw. digitalen Daten handeln, wie beispielsweise eine Word- oder Excel-Datei, ein PDF-Dokument, ein Foto, eine MP3-Datei und dergleichen. In der nachstehenden Beschreibung werden diese Daten der Einfachheit halber als ein (elektronisches) Dokument DOC bezeichnet. Wie dies nachstehend im Detail beschrieben wird, wird erfindungsgemäß ein Dokument DOC in Form eines Dokumentencontainers DOCCOn auf dem
Cloudserver 50 bzw. einer Datenbank 52 des Cloudservers 50 abgelegt, der vorzugsweise die folgenden Elemente enthält: DOQd, DOCver, ENC(DOC, Ksec), ENC(Ksec || H(DOC) II H(DOCid || DOCver), KsS_Pub), SIG(DOCid || DOCver || ENC(Ksec II H(DOC) II H(DOCid || DOCver), Kss_Pub), KsS_prv), die nachstehend im Detail beschrieben werden. Das Dokument DOC liegt in diesem Dokumentencontainer DOCcon in verschlüsselter Form vor, und zwar aufgrund einer Verschlüsselung mit einem geheimen Dokumentenschlüssel Ksec, der für jedes neue Dokument DOC und jede neue Version eines Dokuments DOC neu erzeugt wird, vorzugsweise mittels eines Zufallszahlengenerators.
Unter weiterer Bezugnahme auf Figur 2, wird nachstehend zunächst das Abspeichern eines neu erstellten Dokuments auf dem Cloudserver 50 im Detail beschrieben. In Schritt S21 von Figur 2 wird auf der Computereinheit 30 ein neues Dokument DOC erzeugt, das auf dem Cloudserver 50 gespeichert werden soll. Hierzu fragt die Computereinheit 30 beim Sicherheitsserver 60 nach einer Dokumentenkennung, die sich vorzugsweise aus einer eindeutigen Doku- mentenidentifikationsnummer DOGd und einer Dokumentenversionsnum- mer DOCver zusammensetzt. Die Dokumentenversionsnummer DOCVer dient dazu, unterschiedliche Versionen des durch die Dokumentenidentifikationsnummer DOGd eindeutig identifizierten Dokuments DOC voneinander zu unterscheiden. Obwohl diese Ausgestaltung der Dokumentenkennung er- findungsgemäß bevorzugt ist, wird der Fachmann erkennen, dass die Erfindung auch dann vorteilhaft eingesetzt werden kann, wenn die Dokumentenkennung nur aus einer eindeutigen Dokumentenidentifikationsnummer besteht. In Reaktion auf die Anfrage der Computereinheit 30 in Schritt S21 von Figur 2 sendet der Sicherheitsserver 60 in Schritt S22 von Figur 2 die Dokumentenkennung, d.h. die eindeutige Dokumentenidentifikationsnummer DOGd und die Dokumentenversionsnummer DOCver, an die Computereinheit 30. Dabei kann der Sicherheitsserver 60 die Dokumentenkennung erzeugen, in- dem die Dokumentemdentifikationsnummer DOGd und die Dokumentenversionsnummer DOCver miteinander konkateniert werden, was in Schritt S22 von Figur 2 durch das Symbol " || " angedeutet ist. Obgleich die Doku- mentenidentifikationsnummer DOGd und/ oder die Dokumentenversionsnummer DOCver prinzipiell auch von der Computereinheit 30 erstellt wer- den könnten, ist es Vorteilhaft, dass diese Aufgabe vom Sicherheitsserver 60 übernommen wird, da dadurch verhindert werden kann, dass zwei Endgeräte, auf denen parallel Dokumente zur Speicherung auf dem Cloudserver 50 erstellt werden, dieselbe Dokumentenidentifikationsnummer erzeugen. In Schritt S23 von Figur 2 wird von der Computereinheit 30 ein geheimer Dokumentenschlüssel Ksec erzeugt, beispielsweise mittels eines Zufallszahlengenerators. Mit Hilfe dieses geheimen Dokumentenschlüssels Ksec werden die folgenden Teile eines Dokumentencontainers DOCCOn zur sicheren Speicherung des Dokuments DOC auf dem Cloudserver 50 erstellt: das Doku- ment DOC wird mit dem geheimen Dokumentenschlüssel Ksec verschlüsselt, d.h. ENC(DOC, Ksec), beispielsweise mittels des AES- Verschlüsselungsalgorithmus; und zur Sicherstellung der Authentizität und Integrität werden durch Anwendung einer Einwegfunktion vorzugsweise in Form einer Hash- funktion H die Hashwerte über das Dokument DOC und die Dokumenten- kennung DOQd || DOCver berechnet und zusammen mit dem geheimem Dokumentenschlüssel Ksec mit einem öffentlichen Schlüssel Kss_pub des Sicherheitsservers 60 verschlüsselt, d.h. ENC(Ksec || H(DOC) || H(DOCid || DOCver), Kss_pub), wobei H(X) den Hashwert des Datenelements X bezeichnet.
Wie der Fachmann erkennt, wird in der vorliegenden Anmeldung für die Verschlüsselung eines Datenelements X mit dem Schlüssel K die Notation ENC(X, K) verwendet. Dabei kann es sich bei den mit ENC bezeichneten Verschlüsselungsalgorithmen um symmetrische Verschlüsselungsverfahren, wie beispielsweise DES, AES oder dergleichen, oder um asymmetrische Verschlüsselungsverfahren, wie beispielsweise RSA oder dergleichen, handeln. Im Einzelnen kann der Fachmann aus dem Zusammenhang erkennen, ob erfindungsgemäß ein symmetrisches und/ oder ein asymmetrisches Verschlüsselungsverfahren eingesetzt werden kann.
Vorzugsweise enthält der Dokumentencontainer DOCcon ferner eine Signatur des Sicherheitsservers 60, die über die im Datencontainer DOCcon enthaltenen Datenelemente gebildet wird. Um gegenüber dem Sicherheitsserver 60 die Korrektheit der zu signierenden Datenelemente nachzuweisen, signiert die Computereinheit 30 diese Datenelemente mit deren privaten Schlüssel Kusr_prv , bevor diese an den Sicherheitsserver 60 geschickt werden, d.h. von der Computereinheit 30 wird die folgende Signatur erzeugt:
SIG(DOCid II DOCver II ENC(Ksec II H(DOC) || H(DOCid || DOCver), KsS_Pub), Kusr_Prv), die in Figur 2 als M4 bezeichnet ist, wobei SIG(X, K) für die elektronische Signarur des Datenelements X mit dem Schlüssel K steht.
Die Computereinheit 30 sendet eine eindeutige Benutzer- oder Endgerät- kennung USRid, die Dokumentenkennung (DOGd || DOCver), den verschlüsselten Dokumentenschlüssel Ksec und die über diese Datenelemente berechnete Signatur an den Sicherheitsserver 60. Dabei werden diese Datenelemente vorzugsweise miteinander konkateniert, wodurch sich das in Figur 2 als M5 bezeichnete Datenelement ergibt, d.h.
M5 = USRid II DOQd || DOCver || ENC(Ksec || H(DOC) || H(DOCid || DOCver),
Kss_pub) II
SIG(DOCid II DOCver II ENC(Ksec I H(DOC) || H(DOCid || DOCver), Kss_pub), Kusr_prv). Nachdem der Sicherheitsserver 60 das Datenelement M5 von der Computereinheit 30 erhalten hat, führt der Sicherheitsserver 60 in Schritt S24 von Figur 2 vorzugsweise die folgenden Überprüfungen durch. Zunächst überprüft der Sicherheitsserver 60 anhand der Benutzer- oder Endgerätkennung USRid und der Dokumentenkennung (DOGd || DOCver), dass der Benutzer bzw. dessen Endgerät bekannt sind, dass es sich um ein neues Dokument handelt, und dass dieser Benutzer dazu berechtigt ist, ein neues Dokument DOC anzulegen und auf dem Cloudserver 50 abzulegen. Ferner verifiziert der Sicherheitsserver 60 in Schritt S24 von Figur 2 die im Datenelement M5 enthaltene Signatur und stellt damit sicher, dass das Datenelement M5 tat- sächlich von der Computereinheit 30 stammt. Mit seinem privaten Schlüssel Kss_prv entschlüsselt der Sicherheitsserver 60 den Dokumentenschlüssel Ksec und die Hashwerte über das Dokument DOC und die Dokumentenkennung DOCid II DOCVer. Die Prüfung des Hashwerts über die Dokumentenkennung DOCid II DOCver ist für die Sicherheit des Systems wichtig, da sich ansonsten ein Endgerät unberechtigt Zugang zu einem fremden Dokument verschaffen könnte.
Falls die vorstehend beschriebenen Prüfungen durch den Sicherheitsserver 60 in Schritt S24 von Figur 2 erfolgreich waren, speichert der Sicherheitsserver 60, beispielsweise in einer Datenbank, die Dokumentenkennung
(DOGd II DOCver) zusammen mit der Benutzer- oder Endgerätekennung US- Rid und erstellt mit seinem privaten Schlüssel Kss_Prv die für den Dokumentencontainer benötigte Signatur:
SIG(DOCid II DOCver || ENC(Ksec II H(DOC) || H(DOCid || DOCver), KsS_pub),
Kss_prv), was in Figur 2 als SIG(M3, K5) abgekürzt worden ist. Diese Signatur schickt der Sicherheitsserver 60 zurück an die Computereinheit 30, die sich durch Überprüfung dieser Signatur mittels des öffentlichen Schlüssels KsS_pub des Sicherheitsservers 60 von der Korrektheit der mit der Signatur erfassten Datenelemente überzeugen kann.
Neben der Überprüfung der vom Sicherheitsserver 60 übermittelten Signatur SIG(M3, K5) komplettiert die Computereinheit 30 in Schritt S25 von Figur 2 den Dokumentencontainer DOCCOn mit dieser Signatur, so dass der vollstän- dige an den Cloudserver 50 zu übertragene Dokumentencontainer DOCCOn vorzugsweise in der folgenden Form vorliegt:
DOCcon = DOQd 1 DOCver || ENC(DOC, Ksec) II
ENC(Ksec II H(DOC) II H(DOCid II DOCver), Kss_pub) II
SIG(DOCid II DOCver II ENC(Ksec II H(DOC) || H(DOCid || DOCver), Kss_pub), Kss_prv)
In Schritt S26 von Figur 2 speichert der Cloudserver 50 den Dokumentencontainer DOCcon und bestätigt dies der Computereinheit 30 mittels einer Bestätigungsmeldung. Der von der Computereinheit 30 erzeugte Dokümentenschlüssel Ksec sollte, nachdem dieser zur Verschlüsselung des Dokuments DOC verwendet worden ist und in den Dokumentencontainer DOCCOn eingeflossen, auf der Computereinheit 30 gelöscht werden, beispielsweise nach Schritt S23 von Figur 2.
Im Zusammenhang mit Figur 3 wird nachstehend ein erfindungsgemäß bevorzugter Ablauf beim Abrufen des auf dem Cloudserver 50 als Teil des Dokumentencontainers DOCcon hinterlegten Dokuments DOC durch die Com- putereinheit 30 beschrieben.
In Schritt S31 von Figur 3 sendet die Computereinheit 30 die Dokumenten- kennung, d.h. die Dokumentenidentifikationsnummer DOQd und die Versionsnummer DOCver, an den Cloudserver 50, um den dazugehörigen dort hinterlegten und durch die Dokumentenkennung eindeutig identifizierten Dokumentencontainer DOCcon auf die Computereinheit 30 herunterzuladen (siehe Schritt S32 von Figur 3). Die Schritte S31 oder S32 könnten noch einen optionalen Schritt der Authentifizierung der Computereinheit 30 gegenüber dem Cloudserver 50 enthalten, was jedoch für die Sicherheit des Systems 10 nicht unbedingt erforderlich ist.
In Schritt S33 von Figur 3 überprüft die Computer einheit 30 die im Dokumentencontainer DOCcon enthaltene Signatur, die in Figur 3 als SIG(M3, K5) abgekürzt ist. Da es sich bei dem Schlüssel K5 um den privaten Schlüssel Kss_prv des Sicherheitsservers 60 handelt, erfolgt die Überprüfung der Signatur mit dem öffentlichen Schlüssel KsS_pub des Sicherheitsservers 60, der in Figur 3 als Kl definiert ist. Mittels dieser Überprüfung überzeugt sich die Computereinheit 30 von der Authentizität und Integrität der im Dokumentencontainer DOCcon enthaltenen Daten mit Ausnahme des noch verschlüs- selt vorliegenden Dokuments DOC. Die vollständige Überprüfung auch des Dokuments DOC erfolgt vorzugsweise erst zu einem späteren Zeitpunkt, wie dies nachstehend im Detail beschrieben wird. In dem vom Cloudserver 50 an die Computereinheit 30 übertragenen Dokumentencontainer DOCcon liegt der geheime Dokumentenschlüssel Ksec in verschlüsselter Form vor, und zwar, wie vorstehend im Zusammenhang mit Figur 2 bereits beschrieben, aufgrund einer Verschlüsselung durch die Computereinheit 30 mit dem öffentlichen Schlüssel KsS_pub des Sicherheitsservers 60. Dies hat zur Folge, dass nur der Sicherheitsserver 60 den verschlüsselten Dokumentenschlüssel Ksec mit seinem privaten Schlüssel KsS_Prv wieder entschlüsseln kann.
Demzufolge schickt die Computereinheit 30 in Schritt S33 von Figur 3 eine Anfrage an den Sicherheitsserver 60, die das in Figur 3 als M7 abgekürzte Datenelement vorzugsweise mit den folgenden Elementen enthält: die Benutzer- oder Endgerätkennung USRid, die Dokumentenkennung
(DOCid II DOCver), den verschlüsselten Dokumentenschlüssel Ksec und die Signatur SIG(M3, K5), die den verschlüsselten Dokumentenschlüssel Ksec an die Dokumentenkennung bindet.
Das Datenelement M7 kann in Schritt S33 von Figur 3 unverschlüsselt von der Computereinheit 30 an den Sicherheitsserver 60 übertragen werden. Denn ein Angreifer hat keine Möglichkeit, an den geheimen Dokumenten- schlüssel Ksec heranzukommen, da er keinen Zugriff auf den privaten Schlüssel Kss_prv des Sicherheitsservers 60 hat. Gemäß erfindungsgemäßer Varianten kann diese Übertragung von der Computereinheit 30 zum Sicherheitsserver 60 jedoch auch verschlüsselt erfolgen, damit ein Angreifer nicht in Erfahrung bringen kann, auf welche Dokumente ein Benutzer zugreift. Ιή Schritt S34 von Figur 3 werden vom Sicherheitsserver 60 anhand des von der Computereinheit 30 übertragenen Datenelements M7 mehrere Überprüfungen durchgeführt. Zunächst prüft der Sicherheitsserver 60 anhand der Benutzer- oder Endgerätkennung USRid und der Dokumentenkennung
(DOCid II DOCver), dass dem Sicherheitsserver 60 sowohl der Benutzer bzw. dessen Endgerät als auch das Dokument DOC bekannt sind, und dass dieser Benutzer dazu berechtigt ist, mit seinem Endgerät, d.h. der Computereinheit 30, auf das Dokument DOC zuzugreifen. Der Sicherheitsserver 60 verifiziert die Signatur SIG(M3, K5) und stellt damit sicher, dass der verschlüsselte Do- kumentenschlüssel Ksec auch tatsächlich zu diesem Dokument DOC gehört.
Für den Fall, dass die vorstehend beschriebenen Prüfungen durch den Sicherheitsserver 60 erfolgreich sind, entschlüsselt der Sicherheitsserver 60 den mit dem öffentlichen Schlüssel des Sicherheitsservers 60 verschlüsselten Teil des von der Computereinheit 30 übertragenen Datenelements M7, d.h.
ENC(Ksec II H(DOC) I H(DOCid || DOCver), Kss_pub)/ um den geheimen Dokumentenschlüssel Ksec und die Hashwerte H(DOC) und H(DOQd || DOCver) zu erhalten. Nach der Überprüfung der Korrektheit des Hashwertes über die Dokumentenkennung DOCid II DOCver werden diese Datenelemente vom Sicherheitsserver 60, vorzugsweise so schnell wie möglich, wieder verschlüsselt, und zwar mit dem öffentlichen Schlüssel KUSr_pub der Computereinheit 30, der in Figur 3 als Schlüssel K6 abgekürzt bezeichnet ist:
ENC(Ksec II H(DOC) || H(DOCid || DOCver), KUSr_Pub). Dies hat zur Folge, dass nunmehr nur die Computereinheit 30 den erneut verschlüsselten Dokumentenschlüssel Ksec wieder entschlüsseln kann. Zusätzlich signiert der Sicherheitsserver 60 diese Datenelemente mittels seines privaten Schlüssels KsS_prv, damit sich der Benutzer von der Unversehrtheit dieser Datenelemente überzeugen kann, d.h. der Sicherheitsserver 60 erzeugt die folgende Signatur:
SIG(DOCid II DOCver || ENC(Ksec || H(DOC) || H(DOCid || DOCver), KUSr_Pub), Kss_prv), was in Figur 3 als SIG(M8, K5) abgekürzt dargestellt ist.
Der Sicherheitsserver 60 schickt die erneut verschlüsselten Datenelemente und die Signatur an die Computereinheit 30. Ebenso wie die Übertragung der Daten von der Computereinheit 30 an den Sicherheitsserver 60 in Schritt S33 von Figur 3 können auch diese Daten unverschlüsselt übertragen werden, ohne die Sicherheit des Dokuments DOC zu gefährden. Falls jedoch in Schritt S33 von Figur 3 ein sicherer Kanal für die Übertragung der Daten zwischen der Computereinheit 30 und dem Sicherheitsserver 60 ausgebildet worden ist, kann dieser sichere Kanal vorzugsweise auch für die Übertragung der Daten vom Sicherheitsserver 60 an die Computereinheit 30 in Schritt S34 genutzt werden.
Insbesondere der Schritt der Entschlüsselung mit dem privaten Schlüssel Kss_prv des Sicherheitsservers 60 wird vorzugsweise im Hardware- Sicherheitsmodul (HSM) 62 des Sicherheitsservers 60 durchgeführt. Dies ist insofern vorteilhaft, als der private Schlüssel Kss_prv des Sicherheitsservers 60 dadurch vor potentiellen Angriffen geschützt ist. Wie bereits vorstehend erwähnt, findet die Verschlüsselung, insbesondere des geheimen Dokumentenschlüssels Ksec, durch den Sicherheitsserver 60 mit dem öffentlichen Schlüssel des Benutzers KUsr_pub in Schritt S34 von Figur 3 vorzugsweise unmittelbar im Anschluss ebenfalls im HSM 62 statt, ohne dass der geheime Dokumentenschlüssel Ksec das sichere HSM 62 unver- schlüsselt verlässt. Dies erhöht die Sicherheit für den Fall, dass ein Angriff auf den Sicherheitsserver 60 erfolgreich ist, da der Angreifer nicht auf den geheimen Dokumentenschlüssel Ksec zugreifen kann, der im sicheren HSM 62 nur kurzzeitig unverschlüsselt vorliegt.
Ebenfalls erfolgt die Berechnung der Signatur in Schritt S34 von Figur 3 vorzugsweise im HSM 62, um auch in diesem Fall den privaten Schlüssel Kss_prv des Sicherheitsservers 60 keinen Angriffen auszusetzen. In Schritt S35 von Figur 3 verifiziert die Computereinheit 30 die Signatur
SIG(DOQd II DOCver II ENC(Ksec II H(DOC) || H(DOQd || DOCver), Kusr_pub),
Kss_Prv) mit dem öffentlichen Schlüssel Kss_Pub des Sicherheitsservers 60, um sich von der Authentizität und Integrität der vom Sicherheitsserver 60 übermittelten Datenelemente zu überzeugen. Ferner verwendet die Compu- tereinheit 30 ihren privaten Schlüssel KUSr_prv, um den geheimen Dokumentenschlüssel Ksec und die mit diesem zusammen verschlüsselten Hashwerte im Klartext zu erhalten. Anschließend überprüft die Computereinheit 30 den Hashwert der Dokumentenkennung DOGd || DOCver und entschlüsselt mit dem geheimen Dokumentenschlüssel Ksec den Teil ENC(DOC, Ksec) des Do- kumentencontainers DOCcon, der das verschlüsselte Dokument DOC enthält. Zum Nachweis der Authentizität und Integrität des entschlüsselten Dokuments DOC wird noch dessen Hashwert H(DOC) überprüft. Das nun im Klartext vorliegende Dokument DOC kann nun in der Computereinheit 30 verwendet werden, beispielsweise bearbeitet werden.
Da ebenso wie der private Schlüssel Kss_prv des Sicherheitsservers 60 der private Schlüssel Kusr_prv des Benutzers von essentieller Bedeutung für die Sicherheit des Dokuments DOC ist, wird der private Schlüssel Kusr_prv des Benutzers, wie dies bereits vorstehend erwähnt worden ist, vorzugsweise in einem TEE 34 oder einem Sicherheitselement 20 des Endgeräts des Benutzers verwahrt. Eine optimale Sicherheit lässt sich durch eine Kombination von TEE und Sicherheitselement auf einem Endgerät erreichen, wenn das Sicherheitselement den privaten Schlüssel KUSr_Prv des Benutzers speichert und benutzt, während das TEE eine sichere Tastatur zur Eingabe einer PIN zur Freischaltung der Benutzung des privaten Schlüssels Kusr_prv des Benutzers bereitstellt und diese PIN zur Prüfung an das Sicherheitselement weiterreicht. Im Zusammenhang mit Figur 4 wird nachstehend ein erfindungsgemäß bevorzugter Ablauf bei der Modifizierung eines auf dem Cloudserver 50 gespeicherten Dokuments DOC beschrieben.
Für die Erstellung eines neuen Dokumentencontainers DOCcon wird eine neue Dokumentenkennung benötigt. Bei der in Figur 4 dargestellten bevorzugten Ausführungsform wird die Dokumentenkennung dadurch geändert, dass die DOGd beibehalten wird und eine neue Versionsnummer DOCver erstellt wird. Vorzugsweise wird die neue Versionsnummer DOCver von dem Sicherheitsserver 60 erstellt, da dadurch verhindert werden kann, dass zwei Endgeräte, auf denen parallel an demselben Dokument DOC gearbeitet wird, dieselbe Versionsnummer DOCver für unterschiedliche Versionen von ein und demselben Dokument DOC erstellen.
Im Einzelnen werden die folgenden Schritte durchgeführt. Zunächst wird in Schritt S41 von Figur 4 das Dokument DOC auf der Computereinheit 30 bearbeitet, welches der Benutzer der Computereinheit 30 auf dem Cloudserver 50 sichern möchte. Hierzu überträgt die Computer einheit 30 im Rahmen einer entsprechenden Anfrage die Dokumentenidentifikationsnummer DOQd des Dokuments DOC an den Sicherheitsserver 60, der in Schritt S42 zunächst überprüft, ob diese Dokumentenidentifikationsnummer DOQd ihm bekannt ist, d.h. beispielsweise ein entsprechender Eintrag in seiner Datenbank vor- . liegt. Ist dies der Fall, erstellt der Sicherheitsserver 60 eine neue Versionsnummer DOCver, vorzugsweise indem er die bisherige Versionsnummer in- krementiert, und sendet die geänderte Versionsnummer DOCver an die Computereinheit 30 zurück.
Die nachstehend beschriebenen Schritte S43 bis S46 von Figur 4 sind teilweise identisch zu den vorstehend beschriebenen Schritten S23 bis S26 von Figur 2, so dass teilweise auf die vorstehende Beschreibung der Schritte S23 bis S26 von Figur 2 verwiesen werden kann. Der wesentliche Unterschied besteht darin, dass bei den Schritten S43 bis S46 ein neu generierter Dokumentenschlüssel Ksec zum Einsatz kommt und ein neu erzeugter Dokumentencontainer DOCcon auf dem Cloudserver 50 gespeichert wird, der das modifizier- te Dokument DOC enthält. Dabei kann der neue Dokumentencontainer den bisher auf dem Cloudserver 50 hinterlegten Dokumentencontainer ersetzen oder alternativ neben dem bisherigen Dokumentencontainer auf dem Cloudserver 50 hinterlegt werden. In Schritt S43 von Figur 4 erzeugt die Computereinheit 30 einen neuen geheimen Dokumentenschlüssel Ksec/ mit dem Teile des neuen Dokumentencontainers DOCcon erzeugt werden. Hierzu wird das bearbeitete Dokument DOC mit dem neuen geheimen Dokumentenschlüssel Ksec verschlüsselt (ENC(DOC, Ksec)). Zur späteren Sicherstellung der Authentizität und Integri- tat werden durch Anwendung einer Einwegfunktion, vorzugsweise einer Hashfunktion H die Hashwerte über das modifizierte Dokument DOC und die neue Dokumentenkennung berechnet und zusammen mit dem neuen geheimem Dokumentenschlüssel Ksec mit dem öffentlichen Schlüssel Kss_pub des Sicherheitsservers 60 verschlüsselt, d.h.
ENqKsec II H(DOC) II H(DOCid II DOCver), Kss_Pub):
Vorzugsweise wird dem neuen Dokumentencontainer DOCcon als weiteres Datenelement eine Signatur des Sicherheitsservers 60 hinzugefügt. Um gegenüber dem Sicherheitsserver 60 die Korrektheit der zu signierenden Datenelemente nachzuweisen, signiert die Computereinheit 30 diese Datenelemente mit deren privaten Schlüssel KUSr_prv, bevor diese an den Sicherheitsserver 60 geschickt werden, d.h. von der Computereinheit 30 wird die folgende Signatur erzeugt:
SIG(DOCid II DOCver II ENC(Ksec II H(DOC) || H(DOCid || DOCver), K^b), Kusr_prv), die in Figur 4 als M4 bezeichnet ist.
Die Computereinheit 30 sendet deren Benutzer- oder Endgerätkennung
USRid, die neue Dokumentenkennung (DOQd || DOCver), den verschlüsselten neuen Dokumentenschlüssel Ksec und die darüber berechnete Signatur an den Sicherheitsserver 60. Diese Datenelemente werden vorzugsweise miteinander konkateniert, wodurch sich das in Figur 4 als M5 bezeichnete Datenelement ergibt, d.h.
M5 = USRid II DOGd || DOCver || ENC(Ksec || H(DOC) || H(DOCid || DOCver),
Kss_pub) II
SIG(DOCid 1 DOCver 1 ENC(Ksec II H(DOC) || H(DOCid || DOCver), KsS_Pub),
Kusr_prv). Nachdem der Sicherheitsserver 60 das Datenelement M5 von der Computereinheit 30 erhalten hat, führt der Sicherheitsserver 60 in Schritt S44 von Figur 4 vorzugsweise die folgenden Überprüfungen durch. Zunächst überprüft der Sicherheitsserver 60 anhand der Benutzer- oder Endgerätkennung USRid und der neuen Dokumentenkennung (DOGd || DOCver), dass der Be- nutzer bzw. dessen Endgerät bekannt sind, dass es sich um ein geändertes Dokument handelt, und dass dieser Benutzer dazu berechtigt ist, das geänderte Dokument DOC auf dem Cloudserver 50 abzulegen. Ferner verifiziert der Sicherheitsserver 60 die im Datenelement M5 enthaltene Signatur und stellt damit sicher, dass das Datenelement M5 tatsächlich von der Computereinheit 30 stammt. Mit seinem privaten Schlüssel KsS_Prv entschlüsselt der Sicherheitsserver 60 den neuen Dokumentenschlüssel Ksec und die Hashwer- te über das geänderte Dokument DOC und die geänderte Dokumentenken- nung DOCid || DOCver. Die Prüfung des Hashwerts über die geänderte Do- kumentenkennung DOCid || DOCver ist gemäß bevorzugter Ausführungsformen der Erfindung für die Sicherheit des Systems vorteilhaft, da sich ansonsten ein Endgerät unberechtigt Zugang zu einem fremden Dokument verschaffen könnte. Falls die vorstehend beschriebenen Prüfungen erfolgreich waren, ersetzt der Sicherheitsserver 60 in seinem Datenbankeintrag zu der Dokumentenidentifikationsnummer DOCid die bisherige Versionsnummer DOCver durch die neue Versionsnummer DOCver und erstellt mit seinem privaten Schlüssel Kss_prv die für den Dokumentencontainer benötigte Signatur:
SIG(DOCid I DOCver || ENC(Ksec || H(DOC) || H(DOCid || DOCver), KsS_Pub),
Kss_prv), was in Figur 4 als SIG(M3, K5) abgekürzt worden ist. Diese Signatur schickt der Sicherheitsserver 60 zurück an die Computereinheit 30, die sich in Schritt S45 von Figur 4 durch Überprüfung dieser Signatur mittels des öffentlichen Schlüssels KsS_pub des Sicherheitsservers 60 von der Korrektheit der mit der Signatur erfassten Datenelemente überzeugen kann. Statt die bisherige Versionsnummer DOCver durch die neue Versionsnummer DOCver zu ersetzen, kann der Sicherheitsserver 60 auch die neue Versionsnummer DOCver zusammen mit der bisherigen Versionsnummer DOCver speichern, damit es möglich ist, dass auf alte Versionen weiterhin zugegriffen wird. Neben der Überprüfung der vom Sicherheitsserver 60 übermittelten Signatur kombiniert die Computereinheit 30 in Schritt S45 von Figur 4 die Signatur mit den bereits vorliegenden Datenelemente zum neuen Dokumentencontainer DOCcon, so dass der vollständige an den Cloudserver 50 zu übertragene neue Dokumentencontainer DOCcon vorzugsweise in der folgenden Form vorliegt:
DOCcon = DOGd II DOCver || ENC(DOC, Ksec) II
ENC(Ksec II H(DOC) II H(DOCid || DOCver), Kss_pub) 1
SIG(DOCid II DOCver II ENC(Ksec II H(DOC) || H(DOCid || DOCver),
Figure imgf000028_0001
Wie dies der Fachmann erkennt, haben sich bei dem neuen Dokumentencontainer gegenüber dem im Zusammenhang mit den Figuren 2 und 3 beschriebenen bisherigen Dokumentencontainer die Versionsnummer DOCver, das Dokument DOC und der Dokumentschlüssel Ksec sowie die daraus abgeleiteten Datenelemente geändert.
In Schritt S46 von Figur 4 speichert der Cloudserver 50 den neuen Dokumentencontainer DOCcon und bestätigt dies der Computereinheit 30 mittels einer Bestätigungsmeldung. Dabei kann, wie bereits vorstehend beschrieben, der neue Dokumentencontainer den bisher auf dem Cloudserver 50 hinterlegten Dokumentencontainer ersetzen oder alternativ neben dem bisherigen Dokumentencontainer auf dem Cloudserver 50 hinterlegt werden, so dass auf beide Versionen des Dokuments zugegriffen werden kann.
Im Zusammenhang mit Figur 5 wird nachstehend ein erfindungsgemäß bevorzugter Ablauf beim Verwalten der Benutzerzugriffsrechte auf ein auf dem Cloudserver 50 in Form eines Dokumentencontainers DOCcon gespei- chertes Dokument DOC beschrieben. Dabei sind erfindungsgemäß die Benutzerzugriffsrechte vorzugsweise auf dem Sicherheitsserver 60 hinterlegt und werden dort verwaltet. Beim erstmaligen Erzeugen und Abspeichern eines Dokuments DOC ist gemäß bevorzugter Ausführungsformen der Erfindung vorgesehen, dass der Sicherheitsserver 60 implizit dem Benutzer, der das Dokument DOC erzeugt, die Zugriffsrechte auf sein Dokument DOC einräumt, beispielsweise indem diese Zugriffsrechte zusammen mit den anderen Daten des Dokuments DOC in einer Datenbank des Sicherheitsservers 60 hinterlegt werden, wie dies vorstehend im Zusammenhang mit Figur 2 beschrieben worden ist.
Vorzugsweise gehört zu diesen ursprünglichen Zugriffsrechten auch das Recht, anderen Benutzern bzw. anderen Endgeräten den Zugriff auf das Do- kument DOC zu gewähren, das auf dem Cloudserver 50 in Form eines Dokumentencontainers DOQon hinterlegt ist. Hierzu wählt der Benutzer auf seinem Endgerät, z.B. der Computereinheit 30, einen zusätzlichen Benutzer bzw. ein zusätzliches Endgerät, z.B. das mobile Endgerät 12, aus, dem er den Zugriff auf das Dokument DOC gewähren möchte. Vorzugsweise werden die Endgeräte und die jeweiligen Zugriffsrechte in einer geeigneten Datenstruktur kodiert. Diese Datenstruktur, die in Figur 5 als USRSacis bezeichnet ist, kann an Zugriffsteuerungslisten (access control lists; ACLs) angelehnt sein, die dem Fachmann wohlbekannt sind. In Schritt S51 von Figur 5 erzeugt die Computereinheit 30 vorzugsweise aus der eigenen Benutzer- oder Endgerätkennung USRid, der Dokumentenidentifikationsnummer DOCid und der Datenstruktur USRSacis sowie einer Signatur über diese Elemente, die mit dem privaten Schlüssel KUsr_prv der Computereinheit 30 erzeugt wird, ein Datenelement, das im Rahmen einer Anfrage zum Ändern der Benutzerzugriffsrechte an den Sicherheitsserver 60 übertragen wird.
In Schritt S52 von Figur 5 überprüft der Sicherheitsserver 60 anhand der Be- nutzer- oder Endgerätkennung USRid und der Dokumentenidentifikationsnummer DOQd, dass dem Sicherheitsserver 60 sowohl der Benutzer bzw. dessen Computereinheit 30 als auch das mit der Dokumentenidentifikationsnummer DOCid verknüpfte Dokument DOC bekannt sind, und dass der Benutzer bzw. dessen Computereinheit 30 dazu berechtigt ist, die Zugriffs- rechte auf dieses Dokument DOC zu verwalten.
Ferner überprüft der Sicherheitsserver 60 die in der Datenstruktur USRSacis enthaltenen zusätzlichen Benutzer- oder Endgerätekennungen USRid und verifiziert die Signatur, um sicherzustellen, dass die entsprechende Anfrage tatsächlich von der Computereinheit 30 stammt.
Falls die vorstehend beschriebenen Prüfungen erfolgreich gewesen sind, trägt der Sicherheitsserver 60 die in der Datenstruktur USRSacis definierten Zugriffsrechte in dem Eintrag zum Dokument DOC seiner Datenbank ein und bestätigt der Computereinheit 30 die erfolgreiche Änderung der Zugriffsrechte auf das Dokument DOC.
Nachstehend werden einige der im Zusammenhang mit den Figuren 2 bis 5 beschriebenen unterschiedlichen Aspekte der Erfindung noch einmal näher erläutert sowie einige erfindungsgemäße Varianten beschrieben.
Die Dokumentenidentifikationsnummer DOCid ist ein eindeutiger Identifier für ein Dokument DOC, das in verschiedenen Versionen vorliegen kann. Alle Versionen dieses Dokuments DOC besitzen die gleiche DOCid. Die Ver- sionsnumrner DOCver kennzeichnet eindeutig eine bestimmte Version des Dokuments DOC.
Es ist erfindungsgemäß vorstellbar, dass der Cloudserver 50 unterschiedli- che Versionen eines Dokuments DOC als zusammengehörige oder als unabhängige Dokumente betrachtet. Falls der Cloudserver 50 unterschiedliche Versionen eines Dokuments DOC zusammenhängend verwaltet, so sind erfindungsgemäß weitere sinnvolle Funktionen des Cloudservers 50 möglich, wie z.B. die Abfrage einer Liste mit allen vorliegenden Versionsnummern DOCver zu einer Dokumentenidentifikationsnummer DOGd, die Abfrage der neuesten Versionsnummer zu einer DOGd und das Lesen der neuesten Version eines Dokuments mit einer bestimmten DOGd.
Der Fachmann wird erkennen, dass die Erfindung bis auf die eindeutige Identifizierung eines bestimmten Dokuments sowie einer bestimmten Version dieses Dokuments keine Bedingungen an die Ausgestaltung der Dokumentenidentifikationsnummer DOGd und der Versionsnummer DOCver stellt. Beispielsweise kann es sich bei der Dokumentenidentifikationsnummer DOCid und der Versionsnummer DOCver statt um Zahlen um beliebige (jedoch) eindeutige Zeichenfolgen handeln. Mögliche Formate für die Do- kumenterddentifikationsnummer sind z.B. Dezimalzahlen, Text, Binärzahlen, URLs (Universal Resource Locators), UUIDs (Universal Unique Identifiers).
Ferner stellt die Erfindung keine Bedingungen an die Länge der Dokumen- tenidentifikationsnummer DOGd und der Versionsnummer DOCver. Gemäß erfindungsgemäßer Varianten ist es vorstellbar, dass eine Maximallänge für die Dokumentenidentifikationsnummer DOGd und/ oder die Versionsnummer DOCver definiert werden. Bei diesen erfindungsgemäßen Varianten kann es vorteilhaft sein, die vorstehend im Zusammenhang mit den Figuren 2 bis 5 beschriebenen Verfahren insofern zu vereinfachen, als anstatt des Hashwerts der Dokumentenidentifikationsnurnmer DOQd und/ oder der Versionsnummer DOCver die Dokumentenidentifikationsnummer DOGd und/ oder der Versionsnummer DOCver direkt verwendet werden können.
Ferner sind erfindungsgemäß unterschiedliche Varianten denkbar, wie eindeutige Dokumentenidentifikationsnummern DOQd und/ oder Versionsnummern DOCver erzeugt werden können. Die Dokumentenidentifikationsnummern DOCid und/ oder Versionsnummern DOCver können beispielsweise von dem Sicherheitsserver 60, wie vorstehend beschrieben, dem Cloud- server 50 und/ oder dem Endgerät 30 erzeugt werden. Vorzugsweise werden dabei fortlaufenden Nummern verwendet, ggf. in Verbindung mit einer Identifikationsnummer der erzeugenden Stelle. Alternativ können zufällig erzeugte Werte vergeben werden, sofern der Werteraum und der benutzte Zufallsgenerator die Eindeutigkeit der Werte mit einer hinreichenden Wahrscheinlichkeit garantieren können. Bei der Versionsnummer DOCver handelt es sich vorzugsweise um einen numerischen Wert, der bei 0 startet und mit jeder neuen Version um 1 erhöht wird.
Wie vorstehend bereits beschrieben, sind vorzugsweise auf dem Sicherheitsserver 60, beispielsweise in Form der Datenstruktur USRSacis, die Zugriffsrechte der Benutzer auf jeweilige Dokumente hinterlegt, welche ihrerseits in Form von Dokumentencontainern DOCCOn auf dem Cloudserver 50 abgelegt sind. Erfindungsgemäß können auf dem Sicherheitsserver 60 eine Vielzahl unterschiedlicher Rechte definiert sein. Bespiele für typische Rechte sind das Anlegen eines neuen Dokuments DOC, das Lesen, Verändern und Löschen eines auf dem Cloudserver 50 hinterlegten Dokuments sowie das Verwalten von Zugriffsrechten für andere Benutzer bzw. Endgeräte. Bei einfachen erfindungsgemäßen Varianten ist es denkbar, dass die Zugriff srechte auf ein Dokument DOC für alle Versionen dieses Dokuments gleich sind. Erfindungs gemäß sind jedoch auch komplexere Varianten der Zugriffsrechteverwaltung denkbar, bei denen Benutzer für unterschiedliche Versionen eines Dokuments DOC unterschiedliche Zugriffsrechte erhalten können. Bei derartigen Varianten speichert der Sicherheitsserver 60 vorzugsweise Informationen darüber ab, welcher Benutzer (bzw. welches Endgerät) der Ersteller eines geänderten Dokuments DOC und damit einer neuen Versionsnummer DOCver ist.
Bei den hier beschriebenen bevorzugten Varianten läuft die Verwaltung von Zugriffsrechten unabhängig vom Cloudserver 50, da diese lediglich das Zusammenwirken von Sicherheitsserver 60 und Computereinheit 30 regeln. Zusätzlich kann aber auch auf dem Cloudserver 50 eine eigene Verwaltung von Zugriffsrechten implementiert sein, über die das Schreiben und Lesen der Dokumentencontainer DOCcon durch die Computereinheit 30 kontrolliert werden kann.
Einer der vielen Vorteile der Erfindung besteht darin, dass ein auf dem Cloudserver 50 hinterlegter Dokumentencontainer DOCcon weder direkte Informationen (z.B. in Form der Benutzer- oder Endgerätkennung USRid) noch indirekte Informationen (z.B. in Form einer mit dem privaten Schlüssel des Benutzers Kusr_prv erstellten Signatur) über den Autor des Dokuments enthalten. Erfindungsgemäß sind derartige Informationen über den Autor eines Dokuments vorzugsweise auf dem Sicherheitsserver 60 hinterlegt, und zwar im Zusammenhang mit der Dokumentenidentifikationsnummer DOGd und der Versionsnummer DOCver eines Dokuments DOC. Wie bereits vorstehend beschrieben, wird die Authentizität und Integrität eines Documentencontainers DOCcon vorzugsweise durch eine vom Sicherheitsserver 60 mit seinem privaten Schlüssel KsS_Prv erstellte Signatur geschützt. Vorzugsweise erstreckt sich diese Signatur jedoch nicht über alle im Dokumentencontainer DOCcon enthaltenen Daten, sondern nur über die Dokumentenkennung (DOGd und DOCver) und die verschlüsselten Datenelemente. Vorzugsweise fließt das mit dem Dokumentenschlüssel K sec verschlüsselte Dokument DOC selbst nicht direkt in die Signaturberechnung ein, da es auch nicht im Rahmen der Anfrage von der Computer einheit 30 an den Sicherheitsserver 60 zum Ablegen eines neuen bzw. eines modifizierten Dokuments DOC auf dem Cloudserver 50 an den Sicherheitsserver 60 übertragen wird. Die Authentizität und Integrität des Dokuments DOC wird durch die Signatur jedoch indirekt abgesichert, da gemäß der vorstehend beschriebenen bevorzugten Ausführungsformen der Erfindung der Hash- wert des Dokuments DOC in dem Datenelement Ml enthalten ist. Hierzu sollte jedoch gemäß bevorzugter Ausführungsformen der Erfindung sichergestellt sein, dass zur Erstellung der Signatur der Sicherheitsserver 60 von der Computereinheit 30 den korrekten Hashwert über das Dokument DOC geliefert bekommt.
Wie vorstehend beschrieben, wird der geheime Dokumentenschlüssel Ksec vorzugsweise zusammen mit dem Hashwert über die Dokumentenkennung (DOCid und DOCver) verschlüsselt (siehe z.B. Schritt S23 von Figur 2 oder Schritt S43 von Figur 4). Hierdurch kann vorteilhaft verhindert werden, dass sich ein unberechtigter Benutzer (Angreifer) den geheimen Dokumentenschlüssel Ksec eines fremden Dokuments verschafft, indem der Angreifer zuerst diese Daten im Rahmen einer Anfrage der Computereinheit 30 an den Sicherheitsserver 60 zum Ablegen eines neuen bzw. eines modifizierten Dokuments DOC auf dem Cloudserver 50 an den Sicherheitsserver 60 schickt, um sich diese Daten signieren zu lassen und anschließend im Rahmen einer weiteren Anfrage den geheimen Dokumentenschlüssel Ksec auszuspähen.
Erfindungsgemäß ist es nicht unbedingt erforderlich, dass die Schritte S21 und S22 in Figur 2 besonders abgesichert werden. Ein Angreifer könnte zwar mittels einer Vielzahl von Anfragen eine Vielzahl von Dokumentenidentifikationsnummern DOGd durch den Sicherheitsserver 60 generieren lassen, die dann für andere Benutzer nicht mehr zur Verfügung stehen, oder als Ausbildung eines "Man in the middle"-Angriffs anderen Benutzern martipu- lierte Dokumentenidentifikationsnummern DOGd zukommen lassen. Dies würde jedoch nicht dazu führen, dass der Angreifer unberechtigten Zugriff auf fremde Dokumente erlangen kann. Gemäß bevorzugter Ausführungsformen der Erfindung können jedoch auch die Schritte S21 und S22 beispielsweise mittels einer Authentisierung und/ oder einer Verschlüsselung zusätzlich abgesichert werden.
Gemäß bevorzugter erfindungsgemäßer Ausführungsformen könnte der Sicherheitsserver 60 neben dem asymmetrischen Schlüsselpaar (Kss_Prv und KsS_pub) auch einen symmetrischen Schlüssel Kss_sec aufweisen, der ausschließ- lieh dem Sicherheitsserver 60 bekannt ist. Gemäß Varianten der Erfindung kann dieser symmetrische Schlüssel KsS_sec anstatt des öffentlichen Schlüssels zur Verschlüsselung des geheimen Dokumentenschlüssels Ksec und der im Dokumentencontainer DOCCOn enthaltenen Hashwerte verwendet werden. Im Einzelnen ergeben sich bei dieser Variante die folgenden Änderungen. In Schritt S24 von Figur 2 entschlüsselt der Sicherheitsserver 60 weiterhin die Nachricht M2 mit seinem privaten Schlüssel KsS_prv. Die entschlüsselten Datenelemente der Nachricht M2 werden nun mit dem symmetrischen Schlüssel Kss_sec des Sicherheitsservers 60 verschlüsselt und die Signatur wird über die mit dem symmetrischen Schlüssel Kss_sec des Sicherheitsservers 60 ver- schlüsselte Daten gebildet. Die mit dem symmetrischen Schlüssel KsS_sec des Sicherheitsservers 60 verschlüsselten Daten werden zusammen mit der Signatur darüber an die Computereinheit 30 übertragen. Daraufhin komplettiert die Computereinheit 30 den Dokumentencontainer DOCcon durch die mit dem symmetrischen Schlüssel KsS_seC des Sicherheitsservers 60 verschlüsselten Daten. Wie der Fachmann erkennen wird, ergeben sich bei dem in Figur 3 dargestellten Abrufen eines Dokuments DOC entsprechende Änderungen. Der Vorteil dieser Variante besteht darin, dass die Entschlüsselung des geheimen Dokumentenschlüssels Ksec mit dem symmetrischen Schlüssel Kss_sec des Sicherheitsservers 60 in der Regel schneller als die Entschlüsselung des geheimen Dokumentenschlüssels Ksec mit dem privaten Schlüssel KsS_prv des Sicherheitsservers 60 ist.
Wie vorstehend beschrieben, können bei der Anfrage eines Benutzers an den Sicherheitsserver 60 zum Speichern eines Dokuments DOC auf dem Cloud- server 50 automatisch dem Benutzer die notwendigen Zugriffsrechte erteilt werden, beispielsweise auch das Recht anderen Benutzern Zugriffsrechte auf das Dokument DOC zu gewähren, wie dies im Zusammenhang mit Figur 5 beschrieben worden ist. Gemäß Varianten der Erfindung ist es jedoch eben- falls vorstellbar, dass bereits im Rahmen der Anfragen (siehe z.B. Schritt S23 von Figur 2 oder Schritt S43 von Figur 4) der Benutzer und Autor des Dokuments DOC anderen Benutzern die Zugriffsrechte auf das Dokument DOC erteilt. Gemäß bevorzugter Ausführungsformen der Erfindung könnte der Sicherheitsserver 60 dazu ausgestaltet sein, die Zusammenfassung einzelner Benutzer in Benutzergruppen zu ermöglichen. Dies wäre insbesondere im Firmenumfeld wichtig. Die Gruppen bilden dann Abteilungen, Projekte oder Arbeitsgruppen ab. Einzelne Benutzer können mehreren Gruppen angehö- ren. Gruppen und Benutzer können weiteren Gruppen angehören, so können Abteilungen zu Bereichen zusammengefasst werden und diese wiederum zu noch größeren Einheiten bis hin zur gesamten Firma. Die Zugriffsrechte auf ein Dokument DOC können dann an einzelne Benutzer und an Gruppen erteilt werden.
Bei den vorstehend beschriebenen Ausführungsformen, ist jedem Benutzer genau ein Endgerät fest zugeordnet. Dabei wird die Kombination aus Benutzer und Endgerät über eine Benutzer- oder Endgerätkennung USRid identifi- ziert, die über einen privaten Schlüssel KUSr_prv verfügt. Die Erfindung kann jedoch ebenfalls auf Fälle angewendet werden, bei denen ein Benutzer mehrere Endgeräte verwendet, z.B. einen PC und ein Smartphone. Aber auch der Fall von mehreren Benutzern pro Endgerät wird von der Erfindung erfasst. Hierzu kann entweder jede vorgesehene Kombination aus Benutzer und Endgerät eine eigene USRid bekommen oder es werden getrennte Benutzerkennungen und Endgerätkennungen vergeben. Dann kann erfindungsgemäß ein Benutzer auf unterschiedlichen Endgeräten unterschiedliche private Schlüssel verwenden. Der Sicherheitsserver 60 kennt die Zuordnung von Benutzern und Endgeräten und unterstützt Zugriffsrechte auf Dokumente sowohl für bestimmte Benutzer allgemein als auch für bestimmte Benutzer mit bestimmten Endgeräten. Im Normalfall könnte der Sicherheitsserver 60 Zugriffsrechte an Benutzer erteilen, unabhängig vom verwendeten Endgerät. Es ist erfindungsgemäß aber auch möglich, festzulegen, dass auf ein besonders kritisches Dokument DOC nur von einem bestimmten Endgerät, z.B. einem stationären PC innerhalb einer Firma, zugegriffen werden darf und nicht von einem Smartphone aus, das leichter verloren gehen oder gestohlen werden kann. Ebenso ist es erfindungsgemäß vorstellbar, dass der Sicherheitsserver 60 den Zugriff für ein gestohlenes oder verlorenes Endgerät generell sperren kann, während der Benutzer über andere Endgeräte weiterhin auf die Dokumente zugreifen kann. Außerdem ist sowohl bei mehreren Endgeräten pro Benutzer als auch bei mehreren Benutzern pro Endgerät der Fall erfindungsgemäß denkbar, dass der Benutzer seine Identität und seine Schlüssel auf einem Sicherheitstoken wie z.B. einer Smartcard bereitstellt.
Anstatt der vorstehend beschriebenen Dokumentenkennung in Form einer Kombination aus Dokumentenidentifikationsnummer DOGd und Versionsnummer DOCver zur Identifikation einer bestimmten Version eines bestimmten Dokuments DOC könnte eine einzige Kennung verwendet werden. Dies könnte z.B. dann vorteilhaft sein, wenn diese Kennung durch den Cloudserver 50 vergeben wird. In diesem Fall wäre unter Umständen an den Kennungen jedoch nicht mehr erkennbar, welche Dokumentencontainer DOCCOn verschiedene Versionen eines Dokuments DOC beinhalten. Diese Verknüpfungen könnten dann mittels des Sicherheitsservers 50 abgebildet werden.
Die vorliegende Erfindung bietet insbesondere die folgenden Vorteile. Die vollständige Kontrolle der kryptographischen Schlüssel erfolgt auf Seiten des Benutzers, und zwar innerhalb einer durch den Benutzer kontrollierten sicheren Umgebung. Der Cloudserver benötigt keine besonderen Sicherheitsmaßnahmen, kann also ein beliebig angemieteter Server sein. Bestehende Cloudserver müssen nicht speziell modifiziert werden, so dass bekannte Cloudspeicherdienste genutzt werden können. Der Sicherheitsserver kann einzelne Endgeräte vom Zugriff nachträglich ausschließen, um die Sicherheit der Dokumente bei Verlust oder Diebstahl eines Endgeräts zu wahren. Der Sicherheitsserver besitzt Zugriff auf alle Dokumente, so dass beispielsweise ein Unternehmen noch auf Dokumente der Mitarbeiter zugreifen kann, die nicht mehr für das Unternehmen arbeiten. Ein Sicherheitsserver kann den Dokumentenzugriff für beliebig viele Cloudserver und beliebig viele Benutzer bzw. Endgeräte verwalten. Der Sicherheitsserver benötigt bis auf das Ver- und Entschlüsseln des geheimen Dokumentenschlüssels Ksec und das Signieren kleiner Datenpakete im Vergleich zum Cloudserver keine große Rechenleistung, außerdem nur überschaubaren Speicherplatz und eine Internetverbindung mit relativ geringer Bandbreite.

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zur Speicherung eines elektronischen Dokuments, das auf einem Endgerät (12, 30) vorliegt, auf einem Cloudspeicherdienst (50), wobei das Verfahren die folgenden Schritte umfasst:
das Erzeugen eines Dokumentenschlüssels Ksec auf dem Endgerät (12,
30);
das Verschlüsseln des elektronischen Dokuments mit dem Dokumentenschlüssel Ksec und das Verschlüsseln des Dokumentenschlüssels Ksec mit einem öffentlichen Schlüssel KsS_pub einer Sicherheitsinstanz (60);
das Übertragen eines Dokumentencontainers an den Cloudspeicherdienst (50), wobei der Dokumentencontainer das mit dem Dokumentenschlüssel Ksec verschlüsselte Dokument und den mit dem öffentlichen
Schlüssel Kss_pub der Sicherheitsinstanz (60) verschlüsselten Dokumentenschlüssel Ksec enthält; und
das Abspeichern des Dokumentencontainers im Cloudspeicherdienst
(50).
2. Verfahren nach Anspruch 1, wobei das Verfahren die folgenden weiteren Schritte umfasst:
das Übertragen des verschlüsselten Dokumentenschlüssels Ksec an die Sicherheitsinstanz (60), wobei die Sicherheitsinstanz (60) mit einem privaten Schlüssel KsS_prv der Sicherheitsinstanz eine Signatur des Dokumentenschlüssels Ksec erzeugt; und
das Empfangen der Signatur des Dokumentenschlüssels Ksec durch das Endgerät (12, 30);
wobei der Dokumentencontainer ferner die mit dem privaten Schlüssel Kss_prv der Sicherheitsinstanz (60) erzeugte Signatur enthält.
3. Verfahren nach Anspruch 1 oder 2, wobei das Verfahren ferner den Schritt des Erzeugens einer Dokumentenkennung umfasst, mit der das auf dem Endgerät (12, 30) erzeugte Dokument eindeutig identifiziert werden kann.
4. Verfahren nach Anspruch 3, wobei das Verfahren die folgenden weiteren Schritte umfasst:
das Erzeugen eines Hashwertes der Dokumentenkennung durch das Endgerät (12, 30);
das Verschlüsseln des Hashwertes der Dokumentenkennung mit dem öffentlichen Schlüssel KsS_Pub der Sicherheitsinstanz (60) durch das Endgerät (12, 30);
das Übertragen des verschlüsselten Hashwertes der Dokumentenkennung an die Sicherheitsinstanz (60); und
das Entschlüsseln des verschlüsselten Hashwertes der Dokumentenkennung und das Prüfen des Hashwertes durch die Sicherheitsinstanz (60).
5. Verfahren nach Anspruch 3 oder 4, wobei die Dokumentenkennung eine Dokumentenidentifikationsnummer zur eindeutigen Identifizierung eines Dokuments und eine Versionsnummer zur eindeutigen Identifizierung einer Version eines Dokuments umfasst.
6. Verfahren nach einem der Ansprüche 3 bis 5, wobei die Dokumentenkennung von der Sicherheitsinstanz (60) erzeugt wird.
7. Verfahren nach Anspruch 2, wobei das Endgerät (12, 30) die von der Sicherheitsinstanz (60) erzeugte Signatur des Dokumentenschlüssels Ksec überprüft, bevor der Dokumentencontainer an den Cloudspeicherdienst (50) übertragen wird.
8. Verfahren nach Anspruch 2, wobei der Schritt des Übertragens des verschlüsselten Dokumentenschlüssels Ksec an die Sicherheitsinstanz (60) ferner den Schritt des Übertragens einer Signatur des verschlüsselten Dokumentenschlüssels Ksec enthält, die von dem Endgerät (12, 30) mit einem pri- vaten Schlüssel Kusr_Prv des Endgeräts (12, 30) erzeugt wird.
9. Verfahren nach Anspruch 8, wobei die Sicherheitsinstanz (60) die vom Endgerät (12, 30) mit dem privaten Schlüssel KUSr_prv erzeugte Signatur des Dokumentenschlüssels Ksec überprüft, bevor die Sicherheitsinstanz (60) den verschlüsselten Dokumentenschlüssel Ksec entschlüsselt und mit dem privaten Schlüssel KsS_prv der Sicherheitsinstanz (60) eine Signatur des Dokumentenschlüssels Ksec erzeugt und speichert.
10. Verfahren nach einen der vorhergehenden Ansprüche, wobei die Si- cherheitsinstanz (60) einen Sicherheitsserver und der Cloudspeicherdienst
(50) einen Cloudserver (50) umfasst.
11. Verfahren zum Zugreifen von einem Endgerät (12, 30) auf ein elektronisches Dokument, das gemäü einem Verfahren nach einem der Ansprüche 1 bis 10 auf einem Cloudspeicherdienst (50) gespeichert worden ist, umfassend die Schritte:
das Übertragen des Dokumentencontainers an das Endgerät (12, 30), wobei der Dokumentencontainer das mit dem Dokumentenschlüssel Ksec verschlüsselte Dokument und den mit dem öffentlichen Schlüssel Kss_pub der Sicherheitsinstanz (60) verschlüsselten Dokumentenschlüssel Ksec enthält; das Weiterleiten des mit dem öffentlichen Schlüssel Kss_pub der Sicherheitsinstanz (60) verschlüsselten Dokumentenschlüssels Ksec an die Sicherheitsinstanz (60); das Entschlüsseln des mit dem öffentlichen Schlüssel KsS_Pub der Sicherheitsinstanz (60) verschlüsselten Dokumentenschlüssels Ksec durch die Sicherheitsinstanz (60);
das Verschlüsseln des Dokumentenschlüssels Ksec mit einem öffentli- chen Schlüssel Kusr_Pub des Endgeräts (12, 30);
das Übertragen des mit dem öffentlichen Schlüssel KUsr_Pub des Endgeräts (12, 30) verschlüsselten Dokumentenschlüssel Ksec an das Endgerät (12, 30);
das Entschlüsseln des mit dem öffentlichen Schlüssel KUSr_pub des End- geräts (12, 30) verschlüsselten Dokumentenschlüssels Ksec mit einem privaten Schlüssel Kusr_Prv des Endgeräts (12, 30); und
das Entschlüsseln des im Dokumentencontainer enthaltenen verschlüsselten Dokuments mit dem entschlüsselten Dokumentenschlüssel Ksec 12. Verfahren zum Abspeichern eines auf einem Endgerät (12, 30) modifizierten elektronischen Dokuments, das gemäß einem Verfahren nach einem der Ansprüche 1 bis 10 auf einem Cloudspeicherdienst (50) gespeichert worden ist, umfassend die folgenden Schritte:
das Erzeugen eines neuen Dokumentenschlüssels Ksec auf dem End- gerät (12, 30); ·
das Verschlüsseln des modifizierten elektronischen Dokuments mit dem neuen Dokumentenschlüssel Ksec und das Verschlüsseln des neuen Dokumentenschlüssels Ksec mit einem öffentlichen Schlüssel Kss_Pub einer Sicherheitsinstanz (60);
das Übertragen eines neuen Dokumentencontainers an den
Cloudspeicherdienst (50), wobei der neue Dokumentencontainer das mit dem neuen Dokumentenschlüssel Ksec verschlüsselte modifizierte Dokument und den mit dem öffentlichen Schlüssel KsS_Pub der Sicherheitsinstanz (60) verschlüsselten neuen Dokumentenschlüssel Ksec enthält; das Abspeichern des neuen Dokumentencontainers im Cloudspei- cherdienst (50).
13. Verfahren zum Ändern der Zugriffsrechte auf ein elektronisches Do- kument, das gemäß einem Verfahren nach einem der Ansprüche 1 bis 10 auf einem Cloudspeicherdienst (50) gespeichert worden ist, umfassend die folgenden Schritte:
das Definieren der Zugriffsrechte auf das elektronische Dokument in Form einer Datenstruktur USRSacis auf dem Endgerät (12, 30);
das Übertragen der Datenstruktur USRSacis an die Sicherheitsinstanz
(60); und
das Ändern der Zugriffsrechte auf das auf dem Cloudspeicherdienst (50) gespeicherte elektronische Dokument gemäß der Datenstruktur USRSacis auf der Sicherheitsinstanz (60).
14. Endgerät (12, 30), das dazu ausgestaltet ist, im Rahmen eines Verfahren nach einem der Ansprüche 1 bis 13 eingesetzt zu werden.
15. Sicherheitsinstanz (60), vorzugsweise in Form eines Sicherheitsservers (60), die dazu ausgestaltet ist, im Rahmen eines Verfahren nach einem der
Ansprüche 1 bis 13 eingesetzt zu werden.
16. System mit wenigstens einem Endgerät (12, 30) nach Anspruch 14, einer Sicherheitsinstanz (60) nach Anspruch 15 und wenigstens einem
Cloudspeicherdienst (50).
PCT/EP2014/003035 2013-11-19 2014-11-12 Verfahren, vorrichtungen und system zur online-datensicherung WO2015074745A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102013019487.3 2013-11-19
DE102013019487.3A DE102013019487A1 (de) 2013-11-19 2013-11-19 Verfahren, Vorrichtungen und System zur Online-Datensicherung

Publications (1)

Publication Number Publication Date
WO2015074745A1 true WO2015074745A1 (de) 2015-05-28

Family

ID=51900378

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2014/003035 WO2015074745A1 (de) 2013-11-19 2014-11-12 Verfahren, vorrichtungen und system zur online-datensicherung

Country Status (2)

Country Link
DE (1) DE102013019487A1 (de)
WO (1) WO2015074745A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102015001817A1 (de) 2015-02-13 2016-08-18 Giesecke & Devrient Gmbh Verfahren, Vorrichtungen und System zur Online-Datensicherung
US20230205908A1 (en) * 2021-12-28 2023-06-29 Acronis International Gmbh Protected storage for decryption data

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102015000895B3 (de) * 2015-01-23 2016-07-07 Giesecke & Devrient Gmbh Verteiltes Bearbeiten von zentral verschlüsselt gespeicherten Daten

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1130492A2 (de) * 1999-12-20 2001-09-05 Sony Corporation System und Verfahren zur Verarbeitung von gesicherten Daten
EP1237321A1 (de) * 2000-11-01 2002-09-04 Sony Computer Entertainment Inc. Verfahren und vorrichtung zur verteilung eines dateninhalts

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7921450B1 (en) * 2001-12-12 2011-04-05 Klimenty Vainstein Security system using indirect key generation from access rules and methods therefor
US20050015602A1 (en) * 2003-04-28 2005-01-20 Rees Robert Thomas Owen Method and apparatus for passing data securely between parties
DE102009001718B4 (de) * 2009-03-20 2010-12-30 Compugroup Holding Ag Verfahren zur Bereitstellung von kryptografischen Schlüsselpaaren
US20110016308A1 (en) * 2009-07-17 2011-01-20 Ricoh Company, Ltd., Encrypted document transmission
EP2839407B1 (de) * 2012-04-19 2018-09-05 Invenia As Verfahren zum gesicherten speichern und teilen einer datei über ein computerkommunikationsnetz und offene cloud-dienste

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1130492A2 (de) * 1999-12-20 2001-09-05 Sony Corporation System und Verfahren zur Verarbeitung von gesicherten Daten
EP1237321A1 (de) * 2000-11-01 2002-09-04 Sony Computer Entertainment Inc. Verfahren und vorrichtung zur verteilung eines dateninhalts

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
OMA: "DRM Architecture Approved Version 2.0 - 03 Mar 2006 Open Mobile Alliance OMA-AD-DRM-V2 0-20060303-A", INTERNET CITATION, 3 March 2006 (2006-03-03), XP002439607, Retrieved from the Internet <URL:http://www.openmobilealliance.org/release_program/docs/DRM/V2_0-20060303-A/OMA-AD-DRM-V2_0_20060303-A.pdf> [retrieved on 20070627] *
OPEN MOBILE ALLIANCE: "DRM Specification", 3 March 2006 (2006-03-03), pages 1 - 142, XP055009374, Retrieved from the Internet <URL:http://www.omadrm.ru/spec/version2/DRM specification.pdf> [retrieved on 20111012] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102015001817A1 (de) 2015-02-13 2016-08-18 Giesecke & Devrient Gmbh Verfahren, Vorrichtungen und System zur Online-Datensicherung
US20230205908A1 (en) * 2021-12-28 2023-06-29 Acronis International Gmbh Protected storage for decryption data

Also Published As

Publication number Publication date
DE102013019487A1 (de) 2015-05-21

Similar Documents

Publication Publication Date Title
DE112015006149B4 (de) Verfahren zum Speichern einer Datendatei eines Datenendgeräts in einer Speichereinheit und System sowie Proxyeinheit hierfür
EP3195556B1 (de) Verteilte datenspeicherung mittels berechtigungstoken
DE202018002074U1 (de) System zur sicheren Speicherung von elektronischem Material
EP3447667B1 (de) Kryptographische sicherung für eine verteilte datenspeicherung
DE10084964B3 (de) Verfahren zum sicheren Speichern, Übertragen und Wiedergewinnen inhaltsadresssierbarer Informationen
DE60311036T2 (de) Verfahren zur Authentisierung potentieller Mitglieder eingeladen, eine Gruppe anzuschliessen
DE69736310T2 (de) Erzeugung und Verteilung digitaler Dokumente
EP1290530B1 (de) Verschlüsseln von abzuspeichernden daten in einem iv-system
DE102012213807A1 (de) Steuerung des Lightweight-Dokumentenzugriffs mithilfe von Zugriffskontrolllisten im Cloud-Speicher oder auf dem lokalen Dateisystem
DE102007020775B4 (de) Geräteunabhängige Verwaltung kryptografischer Information
DE112018000779T5 (de) Tokenbereitstellung für Daten
DE102013203126B4 (de) System, Verfahren und Programmprodukt zum transparenten Zugreifen auf verschlüsselte nicht-relationale Daten in Echtzeit
CN106254324A (zh) 一种存储文件的加密方法及装置
DE10124111A1 (de) System und Verfahren für verteilte Gruppenverwaltung
DE102011077218B4 (de) Zugriff auf in einer Cloud gespeicherte Daten
DE112020000244T5 (de) Initialisierung einer Datenspeicherungsvorrichtung mit einer Managervorrichtung
Thummavet et al. A novel personal health record system for handling emergency situations
DE10393847T5 (de) Verfahren und Vorrichtung zum Auffinden einer gemeinsam genutzten vertraulichen Information ohne Beeinträchtigung nicht-gemeinsam genutzter vertraulicher Informationen
DE112022000906T5 (de) Trennen von blockchain-daten
DE112020000236T5 (de) Mehrrollenentsperrung einer datenspeicherungsvorrichtung
EP3248324B1 (de) Verteiltes bearbeiten eines produkts auf grund von zentral verschlüsselt gespeicherten daten
WO2015074745A1 (de) Verfahren, vorrichtungen und system zur online-datensicherung
DE102015103251B4 (de) Verfahren und System zum Verwalten von Nutzerdaten eines Nutzerendgeräts
DE112020000235T5 (de) Anmeldung einer vorautorisierten vorrichtung
DE112020000179T5 (de) Entsperren einer datenspeicherungsvorrichtung

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: 14798706

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14798706

Country of ref document: EP

Kind code of ref document: A1