WO2016139371A1 - Verfahren und system zum verwalten von nutzerdaten eines nutzerendgeräts - Google Patents

Verfahren und system zum verwalten von nutzerdaten eines nutzerendgeräts Download PDF

Info

Publication number
WO2016139371A1
WO2016139371A1 PCT/EP2016/054823 EP2016054823W WO2016139371A1 WO 2016139371 A1 WO2016139371 A1 WO 2016139371A1 EP 2016054823 W EP2016054823 W EP 2016054823W WO 2016139371 A1 WO2016139371 A1 WO 2016139371A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
key
user
user data
encrypted
Prior art date
Application number
PCT/EP2016/054823
Other languages
English (en)
French (fr)
Inventor
Aly Sabri
Original Assignee
Aly Sabri
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 Aly Sabri filed Critical Aly Sabri
Publication of WO2016139371A1 publication Critical patent/WO2016139371A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3006—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters

Definitions

  • Cloud computing generally refers to the use of distributed computing or storage resources of a cloud provider. These distributed storage resources may be accessed by an electronic user terminal (e.g., mobile smart devices, notebooks, personal computers, etc.) over a mostly public network (e.g., the Internet) such as local storage.
  • an electronic user terminal e.g., mobile smart devices, notebooks, personal computers, etc.
  • a mostly public network e.g., the Internet
  • Providers of such cloud storage devices promise convenience, availability and data security when storing user data.
  • Data storage in cloud storage is still fraught with security risks today. Access to the data is usually protected by an access password, if necessary also by a callback function (eg a dynamic code word that is sent via SMS). However, on the storage systems, the data are generally unencrypted, so that when an attack on the storing server, or by cracking the password (for example, phishing attacks) this data for third parties can be accessed.
  • a callback function eg a dynamic code word that is sent via SMS.
  • the data are generally unencrypted, so that when an attack on the storing server, or by cracking the password (for example, phishing attacks) this data for third parties can be accessed.
  • the user can in principle try to store his data already encrypted in the cloud. He then has to take care of the administration of the keys used; if he uses only a few or just one key, the data is not stored much more securely than before. If he uses a separate key for each file, the management is manually no longer manageable.
  • Cloud providers that use secure asymmetric encryption with a private and public key pair, which at least somewhat reduces the problem of key management (since encryption occurs via the public key, which is commonly known while decrypting with secret private key) are currently not known in the market.
  • this type of encryption has the disadvantage that data can no longer be shared via the cloud infrastructure, but only by the user decrypting them on his device and then forwarding them to the third party.
  • surfing data eg browsing history data, cookies, etc.
  • GPS and motion profiles e.g., GPS and motion profiles, payment transactions, or other data sets generated by current sensors (GPS sensors in the smartphone, fitness and health data from current smart wearables, measuring pulse, transpiration and body temperature, data from Google Glass, such as motion profiles and gaze profiles [in which direction and on which objects the user turns his gaze], the Apple Watch, eg fitness wristbands, which are also connected to the Internet are, ...), etc.
  • These usage and movement data are usually associated with small data record sizes compared to text, images or videos and are generally referred to below as "telematic data”.
  • the data control problem area can therefore be summarized as follows: The data control of the data generated by the user is entirely in the hands of a service provider and not the person who generated the data. This also applies to commercial income from this data, which currently does not benefit the user. Overview of the invention
  • user data is understood as meaning digital data or data records which are transmitted by one or more user terminals for storage to an external memory, for example a cloud memory, accessible via a network, as happens in cloud computing.
  • Data and keys can be stored on any - even insecure - storage, as they are each information-less or encrypted Movement data can be securely stored for its own use and, if necessary, for release to third parties, without the data itself being able to be modified by the user
  • user data is understood as meaning digital data or data records which are transmitted by one or more user terminals for storage to an external memory accessible via a network, as happens, for example, in cloud computing.
  • the invention uses so-called modules that are connected to different computers located in the network.
  • the modules can be considered functional units implemented as hardware or software.
  • the modules which are important for the invention will first be introduced. Following is an overview of some distributed in the network computers and their usual roles in the context of the invention. Finally, embodiments follow, in each of which concrete interconnections of the modules to achieve the above-mentioned advantages are presented.
  • the method according to the invention is based on the following modules, which can be connected to functional units to be communicated: a. Key-pair generator
  • the modules can be used all or only in parts to obtain problem-specific applications.
  • the inter-computer communication between interconnected modules always has to be done by means of a secure ⁇ encrypted communication (eg HTTPS / TLS / SSL).
  • an important aspect of the inventive method is that the user has an asymmetric key pair for asymmetric encryption.
  • a key pair generator can be used which generates an asymmetric key pair from a private key prK and a public key puK.
  • the decombiner divides the original data record D into two or more recombatable sub-data sets Di, D 2 , D n which the recombiner can then reassemble into the original jump data record.
  • the individual partial data sets may thereby taken alone, no information in the information theory sense. This means that any given set of source datasets can have any set of partial datasets, so that the distribution of ones and zeros in the binary data is subsequently random, and it is impossible to learn from a partial dataset on the content or part of the content to close the original data record. Likewise, if the source dataset is known, it should not be possible to conclude on the properties of the datasets (such as the distribution of ones and zeros). Preferably, the partial data sets are the same size.
  • the information contained in D, as well as the information contained in the partial data sets Di is described in the information theory by the degree of entropy, as well as the transinformation (mutual information).
  • a common entity for entropy is bits, and for any data sets D, it usually corresponds to the number of ones and zeros (ie bits) that make up D. In the information-theoretical sense, this entropy can be equated with the information contained in the message D, at least if every imaginable bit sequence represents a possible D, and every possible D is equally probable.
  • H (D) - ⁇ P () l ° g P () > where each x stands for a symbol (one bit) in D, and p (x) for the probability that this bit is exactly the value it has in D.
  • p (x) is exactly Vi, and the entropy exactly matches the number of bits in D.
  • the transinformation is a measure of the probability that D can be deduced to D using one of the sub-data sets. Ideally, the trans information is nearly zero. Mathematically defined this size as
  • the length of the sub-data sets must be dependent on the length of D: If D consists of n bits, then all the sub-data sets must again together contain at least n bits, otherwise a reconstruction would be impossible ; on the other hand, the partial data sets together can not be arbitrarily long, since this would limit the storage from a practical point of view.
  • These result bit sequences may be reconverted to the original data set in the recombiner by applying the inverse operation of the decoder, preferably such that the other bit sequences and internal parameters of the decoder used for the operation remain hidden.
  • the decoder performs a bijective (that is, invertible)
  • Operation fit (D) off and returns R and D, R here corresponds to the above internal parameter.
  • the recombiner then calculates accordingly
  • the set of R n is the set of internal parameters of the decombiner.
  • fo (D) as a symmetric encryption method with the randomly chosen key R.
  • R usually has a fixed length, and thus a shorter length than the original data set D, in particular for long data records, such as image data.
  • the content of fit (D) is automatically no longer information-free in the above sense, also can be easily distinguished in the transmission D and fk (D) on the basis of the length.
  • the random sequence R can be generated by means of a physical random number generator or a cryptographically secure pseudo random number generator.
  • a normal addition, or a blockwise addition with blockwise modulo, as well as other operations with the properties described above can be used.
  • the recombiner recombines the partial datasets to the original dataset.
  • the source data set may be a private key and / or small user data.
  • the recombiner performs recombination by applying the operation inverse to the decoder to the sub-data sets.
  • Metadata defines descriptive data of the respective file. These may be: date, resolution, file type, file name, thumbnails, etc.
  • the metadata are for easy indexing on a directory server that implements a directory storage module (see point e) and are not encrypted.
  • the degree of security desired also depends on the amount of metadata that is made available.
  • the module metadata generator exists, which extracts the desired metadata from files or data records in user-configurable manner.
  • the key generator generates a cryptographically secure, random key K for a symmetric encryption method at freely configurable intervals or according to freely determinable rules.
  • This key K is passed only to modules on the same physical machine, and only to an Encryptor or Distributor. With every new generation of a key this one becomes encrypted by the user's public key puK as K * and forwarded, eg to a key store or key server.
  • Encryptor / decryptor An important feature of the key generator is that a new key is not necessarily generated with each encryption operation; This can also be done according to time intervals. K can therefore be requested at any time by another module, K * leaves the key generator only when the key is recreated.
  • Encryptor / decryptor :
  • the Encryptor encrypts the incoming data symmetrically with a key K generated by a module key generator (see above).
  • the decryptor decrypts the data encrypted with the corresponding encryptor using K.
  • the distributor distributes received data packets to a set of external independent servers with memories that can form a cloud storage device, by first dividing these packets into smaller, preferably exactly equal packets and then, in any order, to a subset of available servers forwarded distributed storage.
  • the distributor becomes particularly necessary if the secure communication between a memory and the storing application has been compromised, and it is to be prevented that conclusions can be drawn on the user solely from the size and number of stored files.
  • the information is needed which part of the original data where was stored.
  • This tuple of storage locations is referred to as AC access code.
  • the distributor encrypts the access code AC with the private one Key of the user prK as encrypted access code AC * and sends it to another module for storage, such as a directory memory.
  • the encryption of the access code AC can also be performed separately with a module encrypter.
  • the retriever retrieves the distributed data packets from the cloud storage device and outputs them as a record to the subsequent module.
  • This module may be, for example, a decryptor.
  • the encryptor and the decryptor for encrypting or decrypting the access code AC in the distributor or retriever can each be integrated or formed separately.
  • the Directory Storage module links related metadata, access codes (from the distributor), and record IDs into a data structure stored in the directory store, allowing the directory store to selectively search for specific attributes / metadata and retrieve the associated access codes and Record IDs
  • the totality of all these data structures which in turn can be linked with each other, thus represents the file structure of all data of the user.
  • a targeted hacker attack can not be avoided here in that at least parts of the metadata an attacker visible (the access codes are so encrypted that only the user himself can decrypt them.) This is when selecting the metadata to be stored, and the location where the directory store is run (intranet, internet, on the user's device .. Alternatively, the metadata a be encrypted.
  • the directory storage may, if required, store various encrypted access codes (for each authorized user) to facilitate this access.
  • the directory memory can relate the stored data to each other; so version relations of files (predecessor vs. successor version), as well as hierarchical structuring (similar to a file system) can be mapped.
  • the keystore module stores the keys K * of the encryptor used together with information for which files this key is valid.
  • modules described above will be implemented on different computers or computer systems. While different levels may be added in an individual case, the following computers are usually involved:
  • Terminals usually represent exactly the places where the information originates or unencrypted is present, which should be securely stored in the invention on an external storage, such as a cloud storage.
  • ⁇ Data may also be processed on the user terminal in the context of any embodiment of the invention in unencrypted form. • Except on the User End Device, data may never be processed in such a way that it is wholly or partially unencrypted, as it can not be guaranteed that other devices (which are not under the control of the user) are completely secure.
  • the user terminal is also that entity which assigns to the data to be stored a random, as globally valid ID as possible (so-called UUID), which are generally forwarded to the key memory and the directory memory. See the later description of the embodiments.
  • a telematic device is used to collect small-scale data about the user, in part without his active participation.
  • a telematic sensor may also have the property of being not fully configurable by the user (for example, a smartphone may not be fully configurable in all circumstances, whereas on a personal laptop the commonly used operating systems give much more freedom; mounted on a motor vehicle provides data about the driving behavior of the user, although it is in the access area, but for him is otherwise not in its function to influence).
  • the authorization server which may be located on the user's intranet, for example, is defined here as an instance that stores users' public keys and uniquely associates them with users (similar to a certification authority).
  • an account For each user, an account is managed there, which stores in addition to the public key and general information about the user (such as a user ID) additional parts of the private key. For example, this may be a subset of a private key prK generated by the decoder.
  • the user can retrieve this partial data record and recombine with the aid of another partial data record which he has to the original data record, for example the private key.
  • the authorization server In addition to the private and public keys of a user, the authorization server also manages the group affiliation of the users. Each group will again have a public key, as well as a private key, but its components will be in the group members' accounts and will be different for each group member (see below, Sharing Group Keys).
  • key and directory memory are typically stored on stand-alone computers in the embodiments, which are then referred to as key or directory servers.
  • the keystore runs on its own key server. If, for example, the cryptor uses a separate key for each data record, the validity of the key K is restricted to this one data record. In this case, the key can be stored together with the access code. Key and directory storage then start up the same physical machine, which for the sake of simplicity is only called a directory server. However, if the encrypter chooses new keys depending on the date, the scope is marked by a date interval. storage server
  • the sub-records sent from the module "Distributor” are stored in an external memory, which are implemented as one or more storage servers.
  • these servers are only required to store data packets at an address (URL) and via
  • URL address
  • the filing and retrieval usually takes place via a user ID, which also allows the stored data packet to be reassigned to the user Therefore different accounts (user IDs) that do not resemble the user ID of the authorization server are to be used on different storage servers.
  • the user IDs and available storage servers are part of the configuration of the respective distributor module.
  • 1 is a diagram illustrating the module structure for generating a key pair and the secure storage of the private key according to the inventive method
  • Fig. 2 is a diagram showing the transfer of a private key of a
  • FIG. 4 is a diagram illustrating the module structure for decrypting and retrieving the stored encrypted user data according to the method of the present invention
  • the inventive method is implemented as a modular computer program in a cloud environment.
  • the authorization server, the directory server and the key server can be implemented on one or more computers in a preferably non-public computer network
  • the cloud environment includes, among other things, external storage, such as a cloud storage device that can be accessed by one or more user terminals over a network, such as the Internet, to store and retrieve user data thereon, as well as a non-public computer network of the user on which the user can not publicly store data of a user terminal and separately to the cloud storage device.
  • the cloud storage device may, for example, be a data center with many thousands of servers or even consist of several data centers that are communicatively connected to each other.
  • the non-public computer network may be, for example, an intranet of the user or a user group and may include, among other things, an authorization server, directory server and a key server. Storing the data on public servers while storing the structural directory information on a non-public server (directory server) has the following advantages:
  • the part described above as non-public may also be in the public domain (Internet instead of intranet).
  • the key management asymmetric key pairs and thus the authentication is described with reference to Figure 1, which, as already mentioned above, often represents a weak point.
  • administration - in particular with multiple keys - requires a lot of effort.
  • the key is shared and encrypted using the decoder. Each of these parts no longer receives any information for itself.
  • One of the parts is stored on a server and secured with a password, similar to the way cloud services are today.
  • the password can also be set again if it is authenticated by, for example, receiving an SMS or a recovery link received by mail , where the data of the subkey is preserved.
  • the second part of the key remains with the user and can be stored on each device.
  • the respective active version of the software can recover the private key from the server via a password-secured retrieval.
  • this key must then not persist on the terminal, so it must either be destroyed when the system is turned off or after some time of inactivity of the user. The supervision of the part of the key that remains with the user lies with the user himself.
  • a user terminal may include the key pair generator and decoder modules.
  • the key-pair generator module generates a private key prK and a public key puK.
  • the public key pUC is then stored externally on the above-described authorization server.
  • This authorization server can be implemented, for example, on a computer of an intranet of the user.
  • the module decoder generates from the data set of the private key prK together with a random sequence ⁇ as described above two recombinable sub-data sets prK + ⁇ and - ⁇ .
  • the partial data set prK + ⁇ remains on the user terminal, while the partial data set - ⁇ is stored externally, preferably on the authorization server.
  • the private key originally generated in the key pair generator is then preferably destroyed.
  • group releases can be made via a common key pair. All data to be encrypted is encrypted as usual using the public key puK of the group.
  • the second part is stored on the authorization server.
  • the forwarding user A modifies his key part by means of a random sequence (similar to the decoder). This modified part is sent directly to the new group member B.
  • A sends the random sequence to the authorization server. This checks if the current member A is authorized to transfer the key and adds the new member B to the group.
  • the second part of A's private key on the authorization server is modified by the random sequence, and added to the account of B. Since no user owns the private keys persistently on a device, a user can also subsequently be deprived of the group membership by deleting the second key part on the authorization server, so that the user can no longer start with his key part.
  • a user terminal of user A may include the module decombiner.
  • the module receives as input the part of the private group key prK + ⁇ that user A manages.
  • the decoder generates from the private key part together with a random sequence ⁇ as described above two recombinable sub-data sets prK + ⁇ + ⁇ and - ⁇ .
  • one part prK + ⁇ + ⁇ is sent directly to the user B terminal.
  • the second part - ⁇ is preferably sent to the authorization server together with the request to add user B to the group.
  • the authorization server may include the recombiner module.
  • the part - ⁇ is added via the recombiner together with the part - ⁇ to - ⁇ - ⁇ , and preferably the user data of user B.
  • user B now also gains access to the data stored for the group in the cloud environment, since the two parts prK + ⁇ + ⁇ and - ⁇ - ⁇ behave in the same way to one another as the user's original components prK + ⁇ and - ⁇ A.
  • FIG. 3 Cloud Storage
  • FIG 3 shows the encryption according to the invention and the storage of the user data D according to the preferred embodiment of the present invention.
  • the user terminal may further include the key generator, metadata generator, encryptor, and distributor modules.
  • the data packet D passes through the metadata generator to extract a set of features M from the data set that will later be searchable and visible in the directory store.
  • These data may include file name, type, size of the data D; the save date; a hierarchical relationship of the record D to other stored data; a reference to a previous version of the record; various additional information stored in the data (eg tags of a JPEG graphics file, which may contain, among other things, GPS coordinates and exposure time).
  • the module key generator supplies a symmetric key K, with which in the module Encryptor the user data D to D * are encrypted.
  • the symmetric key K is generated according to configurable rules in the key generator and can then be queried.
  • K is recreated with each record D. In an alternative embodiment, this is done at timed intervals, such as every four weeks.
  • the key K is preferably encrypted with the public key puK as K * in the case of new generation by the module key generator and forwarded to a key memory, which can for example be implemented on a computer (key server) in the user's intranet, and stored there together with the information for which data (ie for which date or for which data record) it is valid.
  • This information may consist, in part, of a unique record ID (UUID) created upon receipt of the data D in the system and of metadata such as e.g. the save date if the key is time-dependent, not file dependent.
  • UUID unique record ID
  • the module distributor decomposes the encrypted user data D * into the data packets Dl *, D2 *, Dn *, distributes them to arbitrary storage servers and creates an access code AC.
  • the module distributor preferably also encrypts the access code AC with internal key K and the encrypted access code AC * is preferably sent to a directory memory which, for example, is implemented on a computer (directory server) in the user's intranet can, and stored there together with the metadata M.
  • AC may also be forwarded unencrypted or encrypted with the user's public key puK.
  • both modules on a respective stand-alone directory server and key server would conveniently reside in a non-public computer network, i. an intranet.
  • the data volumes stored on the intranet are also significantly smaller than the volumes of data stored in the cloud, so that there are no special requirements for the storage capacity of the intranet.
  • the data from the distributor, which make up the volume can be stored on any (even unsafe) public servers in a cloud.
  • An alternative embodiment would keep directory storage or keystores on a user terminal to further restrict accessibility from the outside.
  • Another alternate embodiment dispenses with the metadata generator and merely deposits the unique ID of the record on the directory store. In this embodiment, M then only contains the ID.
  • FIG. 4 shows the retrieval according to the invention of the user data D * stored in the cloud storage device according to the preferred embodiment of the present invention.
  • the user terminal may further include the recombiner, decryptor, and retriever modules.
  • the module recombiner obtains the two recombatable sub-records prK + ⁇ and - ⁇ from the user terminal and the authorization server and recombines them to the private key record PRK.
  • an authentication of the user to the authorization server may optionally have previously occurred.
  • the private key is now used in the decryptor module to decrypt the encrypted symmetric key K * stored in the key server.
  • the then present symmetric key K can be used to decrypt the encrypted access code AC * stored in the directory server.
  • the decrypted access code AC is then sent to the module Retriever, which thus retrieve the stored user data packets Dl *, D2 *, Dn * from the cloud storage device, then to the encrypted user data D * put together and following the subsequent module Dekryptor to decrypt.
  • the encrypted user data D * are then decrypted with the aid of the symmetric key K and are ready for further use by the user terminal.
  • the steps of recalling and assembling the distributed user data packets Dl *, D2 *, Dn * by the module retriever and the recombining of the recombinable partial data records prK + ⁇ and - ⁇ from the user terminal and from the authorization server by the module recombiner can take place in any time Sequence are executed, in particular simultaneously.
  • the individual data records collected are significantly smaller than the data usually provided for cloud storage (such as pictures, music, videos).
  • cloud storage such as pictures, music, videos.
  • the Encryptor or the key generator not a new data record but a new depending on the date Key should use or generate, since in this case only one key per period for other authorized users must be released.
  • telematic data is a security problem, even if only because of its quantity; the single record is usually not very informative.
  • each sensor would have its own Encryptor, and thus have its own key circle. This would be a possible realization.
  • the Encryptor is no longer located on the device that collects the data (ie the sensor), but is accessible via a network; otherwise a large number of encoders would have to use the same internal key K on different terminals, which in turn would compromise its security.
  • Fig. 5 shows an embodiment of the cloud environment that enables the secure storage of telematic data of a user.
  • These telematic data are generated, for example, by a smart device with sensor integrated in or coupled to the user terminal, as described above.
  • At least one combination of the module decoder and metadata generator is implemented in the telematic terminal.
  • the metadata generator generates a minimum number of metadata from the data packet (such as eg what kind of date it is; for example, a payment process, a GPS motion profile, etc.), as well as a unique ID (in the manner of a UUID) of the data.
  • the data itself is decomposed in the decoder into two packets tD + AD and - AD. This is done in order to change the telematic data tD so that it is not available in unencrypted form on other external servers.
  • These two packages tD + AD and - AD are each forwarded via a module structure of the cloud storage solution and via secure channels (eg TLS) to two independent external systems for storage.
  • the keys of the encoders are preferably regenerated at a time interval (and not with each data record), preferably for example every four weeks, the generation time being offset from one cryptor of one server to that of the other server by two weeks. Since the original data can only be restored if both stored subpackets can be decrypted, data can be released exactly over two-week intervals (ie a later user can decrypt exactly only data in a two-week period with a released key pair).
  • the distributors of the two independent systems in FIG. 5 are not familiar with each other, but deliver the generated access code to one and the same directory server, which also receives both the metadata and the ID of the data from the smart device or the user terminal. Using the ID in the access code, these three packages can be combined to form a directory entry.
  • the newly generated keys K from the cloud memory module structures are each encrypted with the public key puK of the user and then stored in the key server.
  • the present invention enables secure management of the private key without a third party gaining access to the key, recovery of the key in the event of loss, and distribution of the private key over several terminals, that the security of the private key is not compromised even if a terminal is lost, see the section on authentication above.
  • the present invention further enables the creation and operation of a secure social network (secure FaceBook); Here is the peculiarity that data (set documents, short comments or pictures) should be made accessible to a whole group of members at the same time. This is easily ensured via the group key functionality (see above). The contents are then only visible to the group members, not to the service provider, as is the case with today's Facebook. Compared to a solution like Snap-Chat, where the "security" is to be guaranteed simply by a fast deletion (ie contributions have a very limited lifespan), content can be securely stored for any length of time and shared in a targeted manner.
  • data could also be stored directly in the treating institution (eg hospital) on its own servers, which allow read access from the Internet.
  • the private key could preferably be placed on the health card of the patient. In this case, data can only be read and decrypted if and only if the card is physically present to the reader.
  • the presented system allows a complete separation of the storage security of data and the content of data.
  • highly redundant systems are usually used so that data can still be read even if a subsystem fails.
  • the storing systems usually have to be equipped with further security features.
  • the redundant storage ie the multiplication of the data, is generally contrary to the secrecy of the data.
  • a storage system never has knowledge of the contents of the stored data.
  • the content is only accessible to the owner of the private key used.
  • the advantage is that even with faulty software on the servers (vulnerabilities such as Heartbleed) access data or content can never become public.
  • the system can severely separate between the data content and metadata, even filename, file type, and file size being counted as metadata.
  • Content is encrypted without reference to the filename / type, and possibly even decomposed into independent subpackets stored on a system of multiple servers.
  • a reconstruction of the original files, or even the metadata itself is not possible by accessing the storing server.
  • the system allows unlike existing systems - without additional
  • the invention offers the user data management within a cloud environment
  • the invention is not limited to the specific embodiment described. Rather, modifications with regard to the sequence of method steps and module and / or computer structure are conceivable without departing from the scope of the attached claims. For example, some modules may also be implemented integrated in another.
  • the Authorization Server, Directory Server, and Key Server computer units have been described as being implemented on standalone computer systems on an intranet or the Internet. In principle, however, these units can be located on any type of computing device that is under the access and control of the user, including on the user's end devices.
  • a novel system is conceivable that brings together the well-known classical aspects of cloud storage, collaboration (team collaboration on individual files) and the social network (such as Facebook or WhatsApp) in a single system.
  • the system is subdivided into an authorization server, a directory server and key server, any storage servers and one or more user terminals.
  • an entry may exist without referencing a record on external servers; in this case, the record is equivalent to a folder in a classic file system structure.
  • Each record on the directory server is referenced by a unique address, such as a URL or an ID.
  • multiple children ie nodes that are subordinate linked
  • the list of referenced children is encrypted, so that they can only be decrypted with knowledge of the key K.
  • K the list of children
  • the list of children could also be present as a normal table on the internal database of the directory server, while the addresses of the children within this table are only encrypted. In this case, it would be possible to simply let the number of children be determined on the directory server.
  • the URL for the directory server is readable; in this case, the list of children can be evaluated directly by the directory server; in an attack on the directory server, however, the attackers would be able to read the linking of the individual records (although the contents remain hidden, ie remain encrypted).
  • the concrete application case is determined by the security requirements and the access speed requirements.
  • the authorization server In order to gain access to the data, you first have to log in to the authorization server as described. This creates a token of time-limited validity for the current session, allowing the user to authorize against the directory and key server. About a well-known entry level URL or ID, the user can then retrieve the data of an entry node including his children on his terminal; From such entry-level nodes, the structure of the children or links can be traversed. In order to allow a view, as in classical social networks, the ID of the creating user as well as the date of creation are preferably stored under the public metadata; the structure describing the children would preferably be the creator of this link and the date of the link.
  • the link creator is not necessarily the creator of the linked record itself; it would be conceivable for a reader to link the post of another user as a comment to a post; of course preserving the original reading rights (ie the creator of the post under which someone has posted a link to another record may not be able to see the content of that link).
  • a search on the database of the directory server can be performed instead of a single entry node.
  • a possible search would be: "find all the nodes that the user has access to (ie, created by, or shared by) users, sorting them by date", in which case the result would be similar to that the user would see in a conventional social network: he would be able to see the most recent posts unlocked for him sorted by date
  • the decryption for the amount of records displayed on the user terminal would occur on the user terminal; Normally only a small subset of the total existing data sets can be displayed, this is easily possible in a short time only if the user decides to display more data sets (eg to scroll the screen) would be a renewed network access to the records and a renewed Decryption on the terminal necessary.
  • a simple rule for the authorization is to be used as an example when creating a new node: a new node created as a child of a node existing on the directory server first inherits the visibility settings / Shares of the parent node.
  • the user can create an empty node (folder, see above) and give it read rights to all known users of the network. If he adds a post to the folder, it would also be readable by all these users; these children could be the starting point for the user's social network.
  • the user creates new nodes under a folder that is only readable for them the children are also completely private; the folder can then represent the starting point of the cloud backup.

Landscapes

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

Abstract

Verfahren zum Verwalten von Nutzerdaten eines Nutzerendgeräts, wobei das Verfahren folgende Schritte aufweist: Erzeugen eines Schlüsselpaars aus privaten Schlüssel prK und öffentlichen Schlüssel puK, Aufteilen des privaten Schlüssels prK in mindestens zwei Teildatensätze, wobei die mindestens zwei Teildatensätze mittels einer bijektiven Operation rekombinierbar erzeugt werden, Verschlüsseln von Nutzerdaten D und Speichern der verschlüsselten Nutzerdaten D* in einer über ein Netzwerk zugänglichen externen Speichervorrichtung, und Wiederabrufen und Entschlüsseln der verschlüsselt gespeicherten Nutzerdaten D* aus der externen Speichervorrichtung, wobei das Wiederabrufen und Entschlüsseln ein Wiederher¬ stellen des privaten Schlüssels prK durch Rekombinieren der beiden Teildatensätze mittels der zum Aufteilen inversen bijektiven Operation aufweist.

Description

Beschreibung
Verfahren und System zum Verwalten von Nutzerdaten eines
Nutzerendgeräts
Stand der Technik
Die digitale Datenverarbeitung, Datenspeicherung und Vernetzung ist nahezu voll- ständig in das Leben eines jeden Bürgers eingedrungen. In der modernen Zivilisation gibt es heute kaum noch Menschen, die nicht Computer, mobile Smart Devices und das Internet benutzen. Insbesondere durch die Nutzung von mobilen Smart Devices (z.B. Smartphones, Phablets, Tablets, Smart-Watches, Smart-Bands, Smart Keychains, Smart Cards, etc.) fallen kontinuierlich riesige Datenmengen an. Diese Daten werden entweder vom Nutzer selbst erstellt, wie etwa Bilder, Videos und Dokumente, oder werden von den mobilen Smart Devices automatisch erzeugt, wie zum Beispiel Nutzungs- und Bewegungsdaten.
Die Speicherung von digitalen Daten erfolgt zunehmend mit Cloud-Computing auf externen Speichern, sogenannten Cloud-Speichern. Unter Cloud-Computing versteht man allgemein die Nutzung von verteilten Rechner- bzw. Speicherressourcen eines Cloud-Anbieters. Auf diese verteilten Speicherressourcen kann ein elektronisches Nutzer-Endgerät (z.B. mobile Smart Devices, Notebooks, PCs, etc.) über ein meist öffentliches Netzwerk (z.B. das Internet) wie auf einen lokalen Speicher zu- greifen. Anbieter von solchen Cloud-Speichern versprechen bei der Speicherung von Nutzerdaten Bequemlichkeit, Verfügbarkeit und Datensicherheit.
Dabei ergeben sich insbesondere beim Speichern und Wiederabrufen der Daten der jeweiligen Nutzer-Endgeräte in den Cloud-Speichern zunehmend Probleme in Be- zug auf Datensicherheit und Datenkontrolle, sowie dem Abwägen zwischen Nutzbarkeit versus Sicherheit. Diese drei Problemfelder sollen im Folgenden mit jeweils einem Bespiel veranschaulicht werden: Datensicherheit:
Die Datenspeicherung in Cloud-Speichern ist bis heute mit erheblichen Sicherheitsrisiken behaftet. Der Zugriff auf die Daten wird in der Regel durch ein Zugangspasswort geschützt, ggf. zusätzlich durch eine Rückruffunktion (bspw. ein dynamisches Codewort, das per SMS versendet wird). Auf den speichernden Systemen liegen die Daten jedoch in der Regel unverschlüsselt vor, so dass bei einem Angriff auf den speichernden Server, oder durch Knacken des Passwortes (z.B. über Phishing-Atta- cken) diese Daten für Dritte zugänglich werden können.
Um dieses Risiko zu umgehen, kann der Nutzer prinzipiell versuchen, seine Daten bereits verschlüsselt in der Cloud abzulegen. Er muss sich dann jedoch auch um die Verwaltung der verwendeten Schlüssel selber kümmern; verwendet er nur wenige oder nur einen Schlüssel, so sind die Daten nicht wesentlich sicherer abgelegt als zuvor. Verwendet er für jede Datei einen eigenen Schlüssel, ist die Verwaltung manuell mithin nicht mehr handhabbar.
Außerdem gehen durch dieses Vorgehen weitere Cloud-spezifische Features verloren. So ist es dem Nutzer nicht mehr ohne weiteres möglich, unter Beibehaltung der gewünschten Sicherheit Daten mit anderen zu teilen, da er dann auch jeweils die verwendeten Schlüssel teilen muss. Gelten diese für mehr als nur die geteilten Da- ten, werden unter Umständen auch andere Daten prinzipiell für den Empfänger nutzbar. Gleichzeitig geht der Nutzer das Risiko ein, dass der Dritte, mit dem geteilt werden sollte, die notwendigen Schlüssel nicht sicher genug verwahrt. Nutzerfreundlichkeit versus Sicherheit
Cloud-Anbieter, die eine als sicher geltende asymmetrische Verschlüsselung mit einem Schlüsselpaar aus privatem und öffentlichem Schlüssel verwenden, die zumindest das Problem der Schlüsselverwaltung einigermaßen reduziert (da die Ver- Schlüsselung über den öffentlichen Schlüssel erfolgt, der gemeinhin bekannt ist, während die Entschlüsselung mit dem geheimen privaten Schlüssel durchgeführt wird) sind derzeit nicht auf dem Markt bekannt. Gleichzeitig bietet diese Art der Verschlüsselung den Nachteil, dass Daten nicht mehr über die Cloud-Infrastruktur geteilt werden können, sondern nur, indem der Nutzer sie auf seinem Endgerät ent- schlüsselt und dann an den Dritten weitergibt.
Des Weiteren setzen diese asymmetrischen Methoden voraus, dass der identitätsge- bende private Schlüssel absolut geheim bleibt. Dieser Schlüssel liegt dabei in der Regel als Datei auf einem Rechner vor, die wiederum über ein Passwort gesichert ist. Bei einem Verlust dieses Passwortes oder einem Verlust der Datei (z.B. durch den Verlust aller sie speichernder Endgeräte) ist die weitere Nutzung des Schlüssels ausgeschlossen; alle Daten, die mit dem öffentlichen Schlüssel verschlüsselt wurden, sind dann unwiederbringlich verloren. Sollte dagegen die Datei mit dem privaten Schlüssel in falsche Hände geraten und das Passwort gefunden werden (weil es entweder nicht sicher genug war, oder der Nutzer es durch eine Fehlbedienung oder eine Phishing- Attacke preisgegeben hat), sind Daten als auch die Identität des Nutzers, falls der Schlüssel für Signaturen zum Einsatz kommt, kompromittiert. Aufgrund der komplexen Handhabung und der beschriebenen Nachteile werden diese Verfahren daher nur von einem Bruchteil von Nutzern eingesetzt.
Ein weiterer Nachteil, der bei einer Verschlüsselung entsteht, ist der, dass die Verwaltung der Daten durch das Fehlen entsprechender Metadaten erschwert wird. Die einzigen zur Verfügung stehenden Metadaten sind in der Regel noch die Dateinamen. Eine Vorschau z.B. von Bildern oder anderen Inhalten, wie sie den Nutzern heute in Diensten wie iCloud zur Verfügung steht, ist damit mithin ausgeschlossen. Datenkontrolle:
Mit der Verbreitung von Smart Devices und Online-Diensten werden von Nutzern in zunehmendem Maße Nutzungs- und Bewegungsdaten aufgezeichnet und gespei- chert.
Diese sind zum Beispiel Surfdaten (z.B. Browserverlaufsdaten, Cookies, etc.) im Internet, GPS- und Bewegungsprofile, Zahlungsvorgänge, oder weitere Datensätze, die von aktuellen Sensoren erzeugt werden (GPS-Sensoren im Smartphone, Fitness- und Gesundheitsdaten aus aktuellen Smart Wearables, die u.a. Puls, Transpiration und Körpertemperatur messen, Daten von Google Glass, wie z.B. Bewegungspro file und Blickprofile [in welche Richtung und auf welche Objekte der Nutzer seinen Blick wendet], der Apple Watch, z.B. Fitness-Armbändern, die ebenfalls mit dem Internet verbunden sind, ...), etc. Diese Nutzungs- und Bewegungsdaten sind im Vergleich zu Texten, Bildern oder Videos in der Regel eher mit geringen Datensatzgrößen assoziiert und seien im Folgenden generell als„telematische Daten" bezeichnet.
Zunehmend werden Fragen laut, wem diese Daten gehören bzw. wem die Nutzung und Verwertung zusteht. Im Moment hat der Nutzer nur die Möglichkeit den Nutzungsbedingungen des Anbieters zuzustimmen oder den Dienst oder Service gar nicht erst zu verwenden. Dies schränkt das Recht auf informationelle Selbstbestimmung erheblich ein. Zum Problemfeld Datenkontrolle kann daher wie folgt zusammengefasst werden: Die Datenkontrolle der vom Nutzer generierten Daten liegt komplett in der Hand eines Service- Anbieters und nicht bei dem, der die Daten erzeugt hat, dem Nutzer. Dies gilt auch für kommerzielle Erträge aus diesen Daten, die dem Nutzer derzeit nicht zugutekommen. Überblick über die Erfindung
In Anbetracht der oben beschriebenen Probleme ist es daher Aufgabe der Erfindung ein Verfahren und System zum Verwalten von Nutzerdaten von zumindest einem Nutzerendgerät zu schaffen, dass hinsichtlich der gespeicherten Nutzerdaten eine verbesserte Datensicherheit und -kontroUe sowie akzeptable Benutzerfreundlichkeit aufweist.
Diese Aufgabe wird jeweils durch die Merkmalskombinationen der unabhängigen Ansprüche gelöst. Vorteilhafte Ausführungsformen und Weiterentwicklungen sind Gegenstand der sich daran anschließenden Unter ansprüche.
Unter Nutzerdaten werden im Rahmen dieser Erfindung digitale Daten bzw. Datensätze verstanden, die von einem oder mehreren Nutzerendgerät zur Speicherung an einen über ein Netzwerk zugänglichen externen Speicher, beispielsweise einem Cloud-Speicher, gesendet werden, wie dies beim Cloud- Computing geschieht.
Das erfindungsgemäße Verfahren und System bietet folgende Vorteile:
Vollständige Datensicherheit vor dem Zugriff Dritter, inklusive des jeweili- gen Cloud-Anbieters, durch die ausschließliche Handhabung informationsloser oder verschlüsselter Daten auf Systemen außerhalb des Endgerätes des Nutzers.
Keine Abhängigkeit von einem Dienst- Anbieter im Sinne eines Trustcenters für die Verwaltung der Daten und/oder der Schlüssel
- Die Datenfreigabe (=Teilen von Daten) kann in Bezug auf beliebige Eigenschaften gesteuert werden. Z.B. Format der Datei, Erstellungsdatum, für einen Zeitraum, etc.
Daten und Schlüssel können auf beliebigen - auch unsicheren - Speichern abgelegt werden, da sie jeweils informationslos bzw. verschlüsselt vorliegen Bewegungsdaten lassen sich zur eigenen Verwendung und ggf. zur Freigabe an Dritte sicher speichern, ohne dass sich die Daten selber durch den Nutzer modifizieren lassen
Sicheres Speichern eines privaten Schlüssels durch Trennen in unterschied- liehe Bestandteile zur einfachen Rekonstruktion bei Verlust, und zur sicheren Weiterverbreitung auf mehreren Endgeräten
- Nutzung eines einzelnen Schlüsselpaares für eine ganze Gruppe von Nutzern, die jeweils unterschiedliche Bestandteile des Schlüssels kennen, und die auch einzeln wieder aus der Gruppe ausgeschlossen werden können, zur Vereinfachung der Handhabung der zahlreichen notwendigen Schlüssel.
Unter Nutzerdaten werden im Rahmen dieser Erfindung digitale Daten bzw. Datensätze verstanden, die von einem oder mehreren Nutzerendgerät zur Speicherung an einen über ein Netzwerk zugänglichen externen Speicher gesendet werden, wie dies beispielsweise beim Cloud-Computing geschieht.
Die Erfindung verwendet sogenannte Module, die auf unterschiedlichen im Netz befindlichen Rechner verbunden sind. Die Module können als Funktionseinheiten aufgefasst werden, die als Hardware oder Software implementiert sind. Im Folgen- den werden zunächst die für die Erfindung bedeutsamen Module eingeführt. Anschließend folgt eine Übersicht über einige der im Netz verteilten Rechner und ihrer im Rahmen der Erfindung üblichen Rollen. Zuletzt folgen Ausführungsbeispiele, in denen jeweils konkrete Zusammenschaltungen der Module zur Erreichung der oben erwähnten Vorteile vorgestellt werden.
Modulstruktur
Das erfindungsgemäße Verfahren basiert auf den folgenden Modulen, die zu kommunizierenden Funktionseinheiten verbunden werden können: a. Schlüsselpaar-Generator
b. Dekombinierer
c. Rekombinierer
d. Metadaten-Generator
e. (Symmetrischer) Schlüsselgenerator
f. Enkryptor
g- Dekryptor
h. Distributor
i. Retriever
j- Verzeichnisspeicher
k. Schlüsselspeicher
Die Module können alle oder nur in Teilen zum Einsatz kommen, um problemspezifische Anwendungen zu erhalten. Die rechnerübergreifende Kommunikation zwi- sehen zusammengeschalteten Modulen hat dabei immer mittels einer sicheren ^verschlüsselten) Kommunikation (bspw. HTTPS/TLS/SSL) zu erfolgen.
Im Folgenden werden die Funktionen der Module beschrieben: Schlüsselpaar-Generator
Ein wichtiger Aspekt des erfindungsgemäßen Verfahrens ist es, dass der Nutzer über ein asymmetrisches Schlüsselpaar für eine asymmetrische Verschlüsselung verfügt. Dazu kann ein Schlüsselpaar-Generator verwendet werden, der ein asymmetrisches Schlüsselpaar aus einem privaten Schlüssel (private Key) prK und einem öffentli- chen Schlüssel (public key) puK erzeugt.
Dekombinierer/Rekombinierer
Der Dekombinierer teilt den Ursprungsdatensatz D in zwei oder mehr rekombinier- bare Teildatensätze Di, D2, Dn die der Rekombinierer dann wieder zum Ur- Sprungsdatensatz zusammenfügen kann. Die einzelnen Teildatensätze dürfen dabei für sich genommen keine Information im informationstheoretischen Sinn enthalten. Dies bedeutet, dass bei einem gegebenen Ursprungsdatensatz jede beliebige Menge von Teildatensätzen entstehen kann, dass also die Verteilung von Einsen und Nullen in den Binärdaten hinterher rein zufällig ist, und es unmöglich ist, aus der Kenntnis eines Teildatensatzes auf den Inhalt oder einen Teil des Inhaltes des Ursprungsdatensatzes zu schließen. Genauso sollte bei bekanntem Ursprungsdatensatz nicht auf Eigenschaften der Teildatensätze (wie die Verteilung von Einsen und Nullen) geschlossen werden können. Vorzugsweise sind die Teildatensätzen gleich groß. Die in D enthaltene Information, sowie die in den Teildatensätzen Di enthaltene Information wird in der Informationtheorie beschrieben durch das Maß der Entropie, sowie der Transinformation (mutual Information). Eine übliche Einheit für die Entropie ist Bit, und für beliebige Datensätze D entspricht sie üblicherweise der Zahl von Einsen und Nullen (also Bits), aus denen D besteht. Diese Entropie kann im informationstheoretischen Sinn gleichgesetzt werden mit der in der Botschaft D enthaltenen Information, jedenfalls dann wenn jede denkbare Bitfolge ein mögliches D darstellt, und jedes mögliche D gleich wahrscheinlich ist. Definiert ist sie als H(D) = — Σά P( ) l°g P( )> wobei jedes x für ein Symbol (ein Bit) in D steht, und p(x) für die Wahrscheinlichkeit, dass dieses Bit genau den Wert annimmt, den es in D hat. Für gleichverteilte Bitfolgen ist p(x) genau Vi, und die Entropie entspricht genau der Zahl der Bits in D.
Die Transinformation ist ein Maß für die Wahrscheinlichkeit, mit der unter Verwendung eines der Teildatensätze Di auf D geschlossen werden kann. Idealerweise ist die Transinformation nahezu Null. Mathematisch definiert ist diese Größe als
Figure imgf000010_0001
I(D die bedingte Wahrscheinlichkeit bedeutet, D zu erraten, wenn Di bekannt ist. Null ist diese Wahrscheinlichkeit genau dann, wenn der Bruch V ^)^l den Wert 1 annimmt, da log(l)=0. Dies ist genau dann der Fall, wenn D und Di stochastisch unabhängig voneinander sind, oder in einfachen Worten: wenn eine beliebige gewählte Bitfolge immer einen Teildatensatz Di darstellen könnte, unabhängig von D; dies müsste gleichzeitig für alle Teildatensätze gelten, wobei aus den Teildatensätzen wiederum D re- konstruierbar sein müsste. Daraus ist bereits ersichtlich, dass dies nie vollständig der Fall sein wird, da beispielsweise die Länge der Teildatensätze von der Länge von D abhängig sein muss: besteht D aus n Bits, müssen alle Teildatensätze zusammen wieder mindestens n Bits enthalten, sonst wäre eine Rekonstruktion unmöglich; auf der anderen Seite können die Teildatensätze zusammen nicht beliebig lang sein, da dies unter praktischen Gesichtspunkten die Speicherung limitieren würde. Ziel der Implementierung des Dekombinierers muss es daher sein, die Transinformation zu minimieren; ein guter Zielwert für die Zerlegung in zwei Teildatensätze wäre / = 2~'D' , wobei \D | die Zahl der Bits von D bezeichnet. Dieser Zielwert wird genau dann erreicht, wenn die Teildatensätze vollständig zufällig, jedoch genauso lang wie D selber sind.
Allgemein gesprochen führt der Dekombinierer auf dem Datensatz selbst, sowie mindestens einer zufällig erzeugten Bitfolge bzw. einer Menge interner Parameter eine algebraische Operation aus, die eine Menge von Bitfolgen als Ergebnis hat. Diese Ergebnis-Bitfolgen können im Rekombinierer durch Anwenden der inversen Operation des Dekombinierers wieder in den ursprünglichen Datensatz verwandelt werden, vorzugsweise so, dass die anderen für die Operation verwendeten Bitfolgen und internen Parameter des Dekombinierers verborgen bleiben. Mathematisch gesehen führt der Dekombinierer eine bijektive (also invertierbare)
Operation fit(D) aus und liefert R und D zurück, R entspricht hier dem oben genannten internen Parameter. Der Rekombinierer berechnet f 1R(fR(D))=D. Für mehr als einen Datensatz kann der Dekombinierer die Ergebnisse fki(D), fR2(Rl), ... , fRn(Rn- ι) liefern. Der Rekombinierer berechnet dann entsprechend
Figure imgf000011_0001
Rn-2=
Figure imgf000011_0002
Ri= f 1R2(fR2(Ri)) und daraus schlußendlich
Figure imgf000012_0001
Die Menge der Rn ist die Menge der internen Parameter des De- kombinierers.
Eine mögliche Realisierung wäre es, als fo(D) ein symmetrisches Verschlüsselungs- verfahren mit dem zufällig gewählten Schlüssel R zu verwenden. Bei Verwendung eines Verschlüsselungsverfahrens besitzt R jedoch in der Regel eine feste Länge, mithin eine geringere Länge als der ursprüngliche Datensatz D, insbesondere bei langen Datensätzen, wie zum Beispiel Bilddaten. Damit ist der Inhalt von fit(D) automatisch nicht mehr informationslos im obigen Sinne, außerdem lassen sich bei der Übertragung D und fk(D) anhand der Länge leicht unterscheiden.
Eine bevorzugte Realisierung ist daher die Verwendung einer Operation fR(D)=D+R, wobei D und R in der Regel gleich lang, oder R mindestens so lang wie D, und diese Operation + auf der Menge der verwendeten Bitfolgen eine algebrai- sehe Gruppe bildet, d.h.
- die Operation ist geschlossen, d.h. das Ergebnis der Operation ist wieder eine Bitfolge
- die Operation ist assoziativ, (A+B+C) = (A+B)+C = A+(B+C)
- es gibt ein neutrales Element 0, A+0 = A (dies ist in der Regel eine Folge aus lauter Nullen)
- zu jedem A gibt es genau ein inverses Element -A, mit A+(-A) = 0
Eine mögliche Realisierung für den Dekombinierer ist daher die Erzeugung zweier Datensätze D1/D2 mit D1=D xor R, D2=R aus dem ursprünglichen Datensatz D und einer vollständig zufälligen Zufallsfolge R gleicher Länge unter Verwendung der bitweisen xor-Funktion. Dl und D2 sind dann ebenfalls vollständige Zufallsfolgen, der Ursprungsdatensatz lässt sich allerdings aus Kenntnis von Dl und D2 wieder zusammenfügen als D = Dl xor D2. Die Zufallsfolge R kann dabei mittels eines physikalischen Zufallszahlengenerators, oder eines kryptographisch sicheren Pseu- dozufallszahlengenerators erzeugt werden. Statt der xor-Operation kann auch eine normale Addition, oder eine blockweise Addition mit blockweisem Modulo, sowie andere Operationen mit den oben beschriebenen Eigenschaften verwendet werden.
Der Rekombinierer rekombiniert die Teildatensätze zum Ursprungsdatensatz. Der Ursprungsdatensatz kann ein privater Schlüssel und/oder kleinteilige Nutzerdaten sein. Der Rekombinierer führt beispielsweise in der obigen XOR-Realisierung die Operation Dl xor D2 = D aus, um D zu rekonstruieren. Allgemein gesprochen führt der Rekombinierer zum Wiederherstellen des privaten Schlüssels prK eine Rekombination durch Anwenden der zum Dekombinierer inversen Operation auf die Teildatensätze aus.
Metadaten-Generator :
Als Metadaten werden beschreibende Daten der betreffenden Datei definiert. Dies können sein: Datum, Auflösung, Dateityp, Dateiname, Thumbnails, etc. Die Metadaten dienen der einfachen Indizierung auf einem Verzeichnisserver, der ein Modul Verzeichnisspeicher (siehe Punkt e) implementiert, und werden nicht verschlüsselt. Der Grad an gewünschter Sicherheit ist damit auch abhängig von der Zahl an Meta- daten, die zur Verfügung gestellt werden. Zu diesem Zweck existiert das Modul Metadaten-Generator, welches in vom Nutzer konfigurierbarer Weise aus Dateien bzw. Datensätzen die gewünschten Metadaten extrahiert.
(Symmetrischer) Schlüsselgenerator
Der Schlüsselgenerator erzeugt in frei konfigurierbaren Intervallen oder nach frei bestimmbaren Regeln einen kryptographisch sicheren, zufalligen Schlüssel K für ein symmetrisches Verschlüsselungsverfahren. Dieser Schlüssel K wird nur an Module auf dem gleichen physikalischen Rechner weitergegeben, und nur an einen Enkryptor oder Distributor. Bei jeder Neuerzeugung eines Schlüssels wird dieser über den öffentlichen Schlüssel puK des Nutzers als K* verschlüsselt und weitergereicht, z.B. an einen Schlüsselspeicher bzw. Schlüsselserver.
Eine wichtige Eigenschaft des Schlüsselgenerators ist, dass nicht zwangsläufig mit jedem Verschlüsselungsvorgang ein neuer Schlüssel erzeugt wird; dies kann auch nach zeitlichen Abständen erfolgen. K kann also jederzeit durch ein anderes Modul angefordert werden, K* verlässt den Schlüsselgenerator nur bei einer Neuerzeugung des Schlüssels. Enkryptor/Dekryptor:
Der Enkryptor verschlüsselt die eingehenden Daten symmetrisch mit einem Schlüssel K, der von einem Modul Schlüsselgenerator (s.o.) erzeugt wurde.
Der Dekryptor entschlüsselt die mit dem entsprechenden Enkryptor verschlüsselten Daten unter Verwendung von K.
Distributor/Retriever:
Der Distributor verteilt empfangene Datenpakete auf eine Menge externer unabhängiger Server mit Speichern, die eine Cloud-Speichervorrichtung bilden können, indem diese Pakete zunächst in kleinere, vorzugsweise exakt gleich große Pakete auf- geteilt und dann in beliebiger Reihenfolge an eine Untermenge zur Verfügung stehender Server zur verteilten Speicherung weitergeleitet werden. Der Distributor wird vor allem dann nötig, wenn die sichere Kommunikation zwischen einem Speicher und der speichernden Anwendung unter Umständen kompromittiert wurde, und verhindert werden soll, dass allein aus der Größe und Zahl gespeicherter Dateien Rückschlüsse auf den Nutzer gezogen werden können.
Um derart verteilte Datenpakete wieder rekonstruieren zu können, wird die Information benötigt, welcher Teil der ursprünglichen Daten wo gespeichert wurde. Dieses Tupel aus Speicherorten wird als Zugriffskode AC bezeichnet. Mit der Speiche- rung der Daten verschlüsselt der Distributor den Zugriffskode AC mit dem privaten Schlüssel des Nutzers prK als verschlüsselten Zugriffskode AC* und sendet ihn zur Speicherung an ein anderes Modul, beispielsweise einen Verzeichnisspeicher. Die Verschlüsselung des Zugriffskodes AC kann auch separat mit einem Modul Enkryp- tor erfolgen.
Der Retriever ruft die verteilt gespeicherten Datenpakete aus der Cloud-Speicher- vorrichtung wieder ab und gibt sie als einen Datensatz an das nachfolgende Modul aus. Dieses Modul kann beispielsweise ein Dekryptor sein.
Optional können in Ausführungsformen der Erfindung der Enkryptor und der Dekryptor zum Ver- bzw. Entschlüsseln des Zugriffskodes AC im Distributor bzw. Retriever jeweils integriert oder separat ausgebildet sein.
Verzeichnisspeicher:
Das Modul„Verzeichnisspeicher" verknüpft zusammengehörige Metadaten, Zu- griffskodes (aus dem Distributor) und Datensatz-IDs in einer Datenstruktur, die im Verzeichnisspeicher abgelegt wird. So erlaubt der Verzeichnisspeicher eine gezielte Suche nach bestimmten Attributen / Metadaten und das Wiederfinden der zugehörigen Zugriffskodes und Datensatz-IDs. Die Gesamtheit aller dieser Datenstrukturen, die auch untereinander wiederum verknüpft sein können repräsentiert damit die Dateistruktur aller Daten des Nutzers. Bei einem gezielten Hackerangriff kann an dieser Stelle nicht vermieden werden, dass ggf. zumindest Teile der Metadaten einem Angreifer sichtbar werden (die Zugriffskodes sind so verschlüsselt, dass nur der Nutzer selbst sie entschlüsseln kann). Dies ist bei der Auswahl der zu speichernden Metadaten, und dem Ort, an dem der Verzeichnisspeicher betrieben wird (Intra- net, Internet, auf dem Endgerät des Nutzers...) zu berücksichtigen. Alternativ können die Metadaten auch verschlüsselt werden.
Um Dateien zwischen Nutzern zu teilen, ist eine Entschlüsselung des Zugriffskodes durch den Nutzer (als Eigentümer der Daten) und die nachfolgende Neuverschlüs- seiung über den öffentlichen Schlüssel des empfangenden Nutzers (=Nutzer der Daten) notwendig. Der Verzeichnisspeicher kann bei Bedarf verschiedentlich verschlüsselte Zugriffskodes (für jeden zugriffsberechtigten Nutzer) ablegen, um diesen Zugriff zu vereinfachen.
Gleichzeitig kann der Verzeichnisspeicher die gespeicherten Daten zueinander in Relation setzen; so können Versionsbeziehungen von Dateien (Vorgänger- vs. Nachfolgerversion), als auch hierarchische Strukturierung (ähnlich einem Dateisystem) abgebildet werden. Schlüsselspeicher:
Das Modul „Schlüsselspeicher" speichert die verwendeten Schlüssel K* des Enkryptors, zusammen mit einer Information, für welche Dateien dieser Schlüssel Gültigkeit besitzt.
Für die Abfrage des jeweils gültigen Schlüssels sind daher gezielte Informationen an den Schlüsselspeicher zu übergeben (Teile der Metadaten, Datum der Speicherung, ggf. eine eindeutige Datensatz-ID). Die abgelegten Schlüssel selber sind durch den Schlüsselserver nicht entschlüsselbar, da sie mittels des öffentlichen Schlüssels des Eigentümers verschlüsselt wurden (siehe Enkryptor). Beteiligte Recheneinheiten im Netzwerk
Vorzugsweise werden die oben beschriebenen Module auf unterschiedlichen Rechnern oder Rechnersystemen zur Ausführung kommen. Während im Einzelfall verschiedene Ebenen hinzukommen können, sind in der Regel die folgenden Rechner beteiligt:
Nutzer-Endgerät
Dies ist ein Gerät, das vollständig vom Nutzer kontrolliert wird, bspw. ein privater Rechner, ein Smartphone, ein Tablet, oder dergleichen. Endgeräte stellen in der Regel genau die Orte dar, an denen diejenige Information entsteht bzw. unverschlüsselt vorliegt, die im Rahmen der Erfindung sicher auf einem externen Speicher, beispielsweise einem Cloud-Speicher, gespeichert werden soll.
Aus dieser Definition ergeben sich automatisch zwei Konsequenzen:
· Daten dürfen auf dem Nutzer-Endgerät auch im Rahmen jeglicher Ausführungsform der Erfindung in unverschlüsselter Form bearbeitet werden. • Außer auf dem Nutzer-Endgerät dürfen Daten jedoch nie so verarbeitet werden, dass sie in Gänze oder zum Teil unverschlüsselt vorliegen, da nicht sichergestellt werden kann, dass andere Geräte (die nicht unter Kontrolle des Nutzers stehen) vollständig sicher sind.
Das Nutzer-Endgerät ist auch diejenige Instanz, die den zu speichernden Daten eine zufällige, möglichst global gültige ID vergibt (sog. UUID), welche in der Regel an den Schlüsselspeicher und den Verzeichnisspeicher weitergereicht werden. Siehe hierzu die spätere Beschreibung der Ausführungsformen.
Sensor, telematisches Gerät
Dies ist eine Sonderform eines Nutzer-Endgerätes, wie die eingangs erwähnten Smart Devices. Auf einem telematischen Gerät im Sinne dieser Erfindung werden kleinteilige Daten über den Nutzer erhoben, zum Teil ohne dessen aktive Mitwir- kung. Ein telematischer Sensor kann außerdem die Eigenschaft besitzen, nicht vollständig durch den Nutzer konfigurierbar zu sein (ein Smartphone bspw. ist nicht unter allen Umständen vollständig frei konfigurierbar, wohingegen auf einem privaten Laptop die üblicherweise verwendeten Betriebssysteme deutlich mehr Freiheiten einräumen; eine Sensorbox, die in einem Kraftfahrzeug montiert Daten über das Fahrverhalten des Nutzers liefert, befindet sich zwar in dessen Zugriffsbereich, ist für ihn aber ansonsten nicht in seiner Funktion zu beeinflussen). Autorisierungsserver:
Der Autorisierungsserver, der sich beispielsweise im Intranet des Nutzers befinden kann, ist hier als eine Instanz definiert, die öffentliche Schlüssel der Nutzer speichert und eindeutig den Nutzern zuordnet (ähnlich einer Zertifizierungsstelle).
Zu jedem Nutzer wird dort ein Account verwaltet, der neben dem öffentlichen Schlüssel und generellen Informationen über den Nutzer (wie z.B. eine Nutzerkennung) zusätzlich Teile des privaten Schlüssels speichert. Dies kann beispielsweise ein Teildatensatz von einem privaten Schlüssel prK sein, der vom Dekombinierer erzeugt worden ist. Der Nutzer kann durch eine Authentifizierung beispielsweise mittels Passwort oder Passphrase diesen Teildatensatz abrufen und mit Hilfe eines weiteren Teildatensatz, den er besitzt, zu dem Ursprungsdatensatz, beispielsweise den privaten Schlüssel, rekombinieren.
Neben dem privaten und öffentlichen Schlüssel eines Nutzers verwaltet der Autori- sierungsserver auch die Gruppenzugehörigkeit der Nutzer. Jede Gruppe besitzt dabei wieder einen öffentlichen Schlüssel, sowie einen privaten Schlüssel, dessen Bestandteile sich jedoch in den Accounts der Gruppenmitglieder befinden, und sich für jedes Gruppenmitglied unterscheiden (siehe auch weiter unten, Weitergabe von Gruppenschlüsseln).
Schlüssel- und Verzeichnisserver
Die oben beschriebenen Module Schlüssel- und Verzeichnisspeicher werden in den Ausführungsformen in der Regel auf eigenständigen Rechnern abgelegt, die dann als Schlüssel- bzw. Verzeichnisserver bezeichnet werden.
Dabei ist es nicht unbedingt notwendig, dass der Schlüsselspeicher auf einem eigenen Schlüsselserver läuft. Wird vom Enkryptor beispielsweise für jeden Datensatz ein eigener Schlüssel verwendet, ist die Gültigkeit des Schlüssels K auf diesen einen Datensatz beschränkt. In diesem Fall kann der Schlüssel zusammen mit dem Zu- griffskode abgelegt werden. Schlüssel- und Verzeichnisspeicher laufen dann auf dem gleichen physikalischen Rechner, der zur Vereinfachung nur noch Verzeichnisserver genannt wird. Wählt der Enkryptor jedoch datumsabhängig neue Schlüssel, ist der Gültigkeitsbereich durch ein Datumsintervall gekennzeichnet. Speicherserver
Die aus dem Modul„Distributor" gesendeten Teildatensätze werden in einem externen Speicher gespeichert, der als einer oder mehrere Speicherserver implementiert sind. An diese Server wird im Sinne der Erfindung nur die Anforderung gestellt, dass sie Datenpakete unter einer Adresse (URL) ablegen und über die gleiche Ad- resse auch den Abruf ermöglichen. Um sicherzustellen, dass Nutzer für den von ihnen ausgelösten Speicherverbrauch auch berechtigt sind, geschieht das Ablegen und Abrufen in der Regel über eine Nutzerkennung, die auch das abgelegte Datenpaket wieder dem Nutzer zuordenbar werden lässt. Vorzugsweise sind deshalb auf verschiedenen Speicherservern verschiedene Accounts (Nutzerkennungen) zu ver- wenden, die nicht der Nutzerkennung des Autorisierungsservers gleichen. Die Nutzerkennungen und verfügbaren Speicherserver sind Bestandteile der Konfiguration des jeweiligen Distributor-Moduls.
Ausführungsformen
Die vorliegende Erfindung wird im Folgenden unter Bezugnahme auf die begleitende Zeichnung weiter erläutert. Es zeigt
Fig. 1 ein Diagramm, das die Modulstruktur zur Erzeugung eines Schlüsselpaares und die sichere Speicherung des privaten Schlüssels gemäß dem erfindungsgemäßen Verfahren darstellt,
Fig. 2 ein Diagramm, das die Weitergabe eines privaten Schlüssels einer
Gruppe an ein neues Gruppenmitglied gemäß dem erfindungsgemäßen Verfahren darstellt, ein Diagramm, das die Modulstruktur zur Verschlüsselung und Speichi rung von Nutzerdaten eines Nutzerendgeräts gemäß dem erfmdungsgi mäßen Verfahren darstellt, Fig. 4 ein Diagramm, das die Modulstruktur zur Entschlüsselung und das Wiederabrufen der gespeicherten, verschlüsselten Nutzerdaten gemäß dem erfindungsgemäßen Verfahren darstellt, und ein Diagramm, das die Modulstruktur zur Behandlung von telemati- schen (=kleinteiligen) Nutzerdaten gemäß dem erfindungsgemäßen Verfahren darstellt.
Bei einer bevorzugten Ausführungsform wird das erfindungsgemäße Verfahren als ein modulares Computerprogramm in einer Cloud-Umgebung implementiert. Fer- ner kann der Autorisierungsserver, der Verzeichnisserver und der Schlüsselserver auf einem oder mehreren Rechnern in einem vorzugsweise nicht-öffentlichen Rechnernetz implementiert sind
Die Cloud-Umgebung weist unter anderem einen externen Speicher auf, beispiels- weise eine Cloud-Speichervorrichtung, auf den durch eine oder mehrere Nutzerendgeräte über ein Netzwerk, beispielsweise das Internet, zugegriffen werden kann, um darauf Nutzerdaten zu speichern und wieder abzurufen, sowie ein nicht öffentliches Rechnernetz des Nutzers, auf dem der Nutzer Daten eines Nutzerendgeräts nicht öffentlich und separat zu der Cloud-Speichervorrichtung speichern kann. Die Cloud-Speichervorrichtung kann beispielsweise ein Rechenzentrum mit vielen tausend Servern sein oder auch aus mehreren Rechenzentren bestehen, die untereinander kommunikativ verbunden sind. Das nicht öffentliche Rechnernetz kann beispielsweise ein Intranet des Nutzers oder einer Nutzergruppe sein und kann unter anderem einen Autorisierungsserver, Verzeichnisserver und einen Schlüsselserver enthalten. Die Speicherung der Daten auf öffentlichen Servern, während die strukturelle Verzeichnisinformation auf einem nicht-öffentlichen Server (Verzeichnisserver) abgelegt wird, birgt die folgenden Vorteile:
- Die im öffentlichen Bereich gespeicherten Datenpakete Dn sind deutlich umfangreicher als die Verzeichnisinformation im nicht-öffentlichen Bereich, ohne diese völlig nutzlos, da ohne Zugang zu den Zugriffscodes praktisch unentschlüsselbar, da sowohl die Inhalte verschlüsselt sind, als auch die Zugehörigkeit von Teildatensätzen zu einer Datei nicht mehr bekannt ist. - Damit kann eine Speicherung auf öffentlichen, redundanten Servern, wie sie von verschiedenen Anbietern auf dem Markt gemietet werden können, erfolgen, ohne Abstriche bei der Sicherheit der Speicherung zu machen.
Ist diese Stufe der Sicherheit nicht notwendig oder nicht gewünscht, kann der oben als nicht-öffentlich beschriebene Teil ebenfalls im öffentlichen Bereich (Internet statt Intranet) liegen.
Im Folgenden wird die bevorzugte Ausführungsform anhand der Fig. 1 bis 4 beschrieben, und im Anschluss anhand Fig. 5 eine weitere bevorzugte Ausführungs- form für telematische (kleinteilige) Datensätze.
Authentifizierung (Figur 1)
Zunächst wird anhand von Figur 1 die Schlüsselverwaltung asymmetrischer Schlüsselpaare und damit die Authentifizierung beschrieben, die wie bereits oben erwähnt, häufig einen Schwachpunkt darstellt. Zum einen ist die Verwaltung - insbesondere bei mehreren Schlüsseln - mit einem hohen Aufwand verbunden. Zum anderen besteht immer die Gefahr des Schlüsselverlustes und damit des Verlustes aller damit verschlüsselten Daten. In der vorliegenden Erfindung wird der Schlüssel mit Hilfe des Dekombinierers geteilt und verschlüsselt. Jeder dieser Teile erhält nun für sich keine Information mehr. Einer der Teile wird auf einem Server abgelegt und mit einem Passwort gesichert, ähnlich wie es heute bei Cloud-Diensten der Fall ist. Da dieses Passwort nur der Zugangskontrolle dient und keine Auswirkung auf die Verschlüsselung der Daten (in diesem Fall: des Teilschlüssels) hat, lässt sich bei entsprechender Authentifizierung über z.B. Empfang einer SMS oder einen per Mail empfangenen Recovery- Link das Passwort bei Verlust auch neu setzen, wobei die Daten des Teilschlüssels erhalten bleiben. Der zweite Teil des Schlüssels verbleibt beim Nutzer und kann auf jedem Endgerät abgelegt werden. Zur Laufzeit des Systems kann die jeweils aktive Version der Software den privaten Schlüssel über einen passwortgesicherten Abruf vom Server wiederherstellen. Dieser Schlüssel darf dann allerdings auf dem Endgerät nicht persistieren, muss also entweder beim Ausschalten des Systems oder nach einiger Zeit der Inaktivität des Nutzers vernichtet werden. Die Aufsicht über den Teil des Schlüssels, der beim Nutzer verbleibt, liegt beim Nutzer selber. Er kann allerdings beispielsweise an einen Treuhänder weitergegeben werden, der diesen zweiten Teil auf einem nicht an das Internet angebundenen Rechner verwahrt, für den Fall, dass tatsächlich sämtliche Versionen des zweiten Schlüsselteils verloren gegangen sind. Wichtig bei der Speicherung ist nur, dass die beiden Teilschlüssel niemals auf einem einzigen System unter Verlinkung über den Nut- zeraccount gespeichert werden (da ansonsten der private Schlüssel auch durch Dritte wieder hergestellt werden könnte).
Wie in Fig. 1 gezeigt, kann ein Nutzerendgerät die Module Schlüsselpaar-Generator und Dekombinierer enthalten. Das Modul Schlüsselpaar-Generator erzeugt einen privaten Schlüssel prK und einen öffentlichen Schlüssel puK. Der öffentliche Schlüssel puK wird dann extern auf dem vorstehend beschriebenen Autorisierungs- server gespeichert. Dieser Autorisierungsserver kann beispielsweise auf einen Rechner eines Intranets des Nutzers implementiert sein. Das Modul Dekombinierer erzeugt aus dem Datensatz des privaten Schlüssels prK zusammen mit einer Zufallsfolge ΔΑ wie oben beschrieben zwei rekombinierbare Teildatensätze prK+ΔΑ und -ΔΑ. Vorzugsweise verbleibt der Teildatensatz prK+ΔΑ auf dem Nutzerendgerät, während der Teildatensatz -ΔΑ extern gespei- chert wird, vorzugsweise auf dem Autorisierungsserver. Der im Schlüsselpaar- Generator ursprünglich erzeugte private Schlüssel wird danach vorzugsweise vernichtet.
Gruppenverwaltung von Schlüsseln (Figur 2)
Sollen sicher gespeicherte Daten an eine oder mehrere Gruppen freigegeben werden ist dies mit herkömmlichen Methoden aufwändig und umständlich, da für jeden einzelnen zu berechtigenden Nutzer ein Zugriffsschlüssel (K*) erzeugt werden müsste, bzw. birgt als Risiko die Kompromittierung der Sicherheit von nicht freigegebenen Daten, wenn auf die Verschlüsselung verzichtet, oder nicht für jeden Datensatz ein eigener Schlüssel gewählt wird.
In der vorliegenden Erfindung können Gruppenfreigaben über ein gemeinsames Schlüsselpaar erfolgen. Alle zu verschlüsselnden Daten werden wie gehabt mittels des öffentlichen Schlüssels puK der Gruppe verschlüsselt.
Alle Gruppenmitglieder besitzen nur einen Teil des privaten Gruppenschlüssels (wie oben beschrieben), der zweite Teil ist jeweils auf dem Autorisierungsserver gespeichert. Bei der Weitergabe des privaten Schlüssels eines Nutzers A an ein neues Mitglied B modifiziert der weitergebende Nutzer A seinen Schlüsselteil mittels einer Zufallsfolge (ähnlich wie im Dekombinierer). Diesen modifizierten Teil sendet er direkt an das neue Gruppenmitglied B. Gleichzeitig sendet A die Zufallsfolge selber an den Autorisierungsserver. Dieser prüft, ob das aktuelle Mitglied A zur Weitergabe des Schlüssels berechtigt ist, und fügt das neue Mitglied B der Gruppe hinzu. Hierzu wird auf dem Autorisierungsserver auch der zweite Teil des privaten Schlüs- sels von A durch die Zufallsfolge modifiziert, und dem Account von B hinzugefügt. Da kein Nutzer die privaten Schlüssel selber persistent auf einem Gerät besitzt, kann einem Nutzer auch nachträglich die Gruppenmitgliedschaft wieder entzogen werden, durch Löschen des zweiten Schlüsselteils auf dem Autorisierungsserver, so dass der Nutzer mit seinem Schlüsselteil nichts mehr anfangen kann.
Wie in Fig. 2 gezeigt, kann ein Nutzerendgerät von Nutzer A das Modul Dekombi- nierer enthalten. Das Modul erhält als Eingangsgröße den Teil des privaten Gruppenschlüssels prK+ΔΑ, den Nutzer A bei sich verwaltet. Als Ergebnis erzeugt der Dekombinierer aus dem privaten Schlüsselteil zusammen mit einer Zufallsfolge ΔΒ wie oben beschrieben zwei rekombinierbare Teildatensätze prK+ΔΑ+ΔΒ und -ΔΒ.
Vorzugsweise wird der eine Teil prK+ΔΑ+ΔΒ direkt an das Endgerät von Nutzer B verschickt. Der zweite Teil -ΔΒ wird vorzugsweise an den Autorisierungsserver verschickt zusammen mit der Anforderung, Nutzer B in die Gruppe hinzuzufügen. Der Autorisierungsserver kann das Modul Rekombinierer enthalten. Der Teil -ΔΒ wird über den Rekombinierer zusammen mit dem Teil -ΔΑ zu -ΔΑ-ΔΒ und vorzugsweise den Nutzerdaten von Nutzer B hinzugefügt. Damit erhält Nutzer B nun ebenfalls Zugriff auf die für die Gruppe abgelegten Daten in der Cloud-Umgebung, da die beiden Teile prK+ΔΑ +ΔΒ und -ΔΑ-ΔΒ sich zueinander genauso verhalten wie die ursprünglichen Anteile prK+ΔΑ und -ΔΑ des Nutzers A.
Cloud-Speicherung (Figur 3)
Fig. 3 zeigt die erfindungsgemäße Verschlüsselung und die Speicherung der Nutzerdaten D gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung.
Wie in Fig. 3 gezeigt, kann das Nutzerendgerät weiter die Module Schlüsselgenerator, Metadaten-Generator, Enkryptor und Distributor enthalten. Zunächst durchläuft das Datenpaket D den Metadaten-Generator, um eine Reihe von Merkmalen M aus dem Datensatz zu extrahieren, die später im Verzeichnisspeicher suchbar und sicht- bar sein sollen. Zu diesen Daten können gehören Dateiname, -typ, -größe der Daten D; das Speicherdatum; eine hierarchische Beziehung des Datensatzes D zu anderen gespeicherten Daten; eine Referenz auf eine Vorgängerversion des Datensatzes; ver- schiedentliche in den Daten abgelegte Zusatzinformationen (z.B. Tags eines JPEG- Grafikdatei, die u.a. GPSKoordinaten und Belichtungszeit enthalten können).
Das Modul Schlüsselgenerator liefert einen symmetrischen Schlüssel K, mit dem im Modul Enkryptor die Nutzerdaten D zu D* verschlüsselt werden. Der symmetrische Schlüssel K wird nach konfigurierbaren Regeln im Schlüsselgenerator erzeugt und kann dann abgefragt werden. In einer bevorzugten Ausführungsform wird K mit jedem Datensatz D neu erzeugt. In einer alternativen Ausführungsform geschieht dies in zeitlichen Intervallen, wie beispielsweise, alle vier Wochen.
Der Schlüssel K wird bei Neuerzeugung durch das Modul Schlüsselgenerator vorzugsweise mit dem öffentlichen Schlüssel puK als K* verschlüsselt und an einen Schlüsselspeicher weitergereicht, der beispielsweise auf einem Rechner (Schlüsselserver) im Intranet des Nutzers implementiert sein kann, und dort gespeichert, zusammen mit der Information, für welche Daten (d.h. für welches Datum oder für welchen Datensatz) er Gültigkeit besitzt. Diese Information kann in Teilen aus einer eindeutigen Datensatz-ID (UUID) bestehen, die mit Eingang der Daten D in das System erzeugt wurde, und aus Metadaten wie z.B. dem Speicherdatum, falls der Schlüssel zeitabhängig, nicht dateiabhängig, neu generiert wird.
Das Modul Distributor zerlegt die verschlüsselten Nutzerdaten D* in die Datenpakete Dl *, D2*, Dn*, verteilt sie auf beliebige Speicherserver und erstellt einen Zugriffskode AC. Das Modul Distributor verschlüsselt vorzugsweise den Zugriffs- kode AC ebenfalls mit internen Schlüssel K und der verschlüsselte Zugriffskode AC* wird vorzugsweise an einen Verzeichnisspeicher geschickt, der beispielsweise auf einem Rechner (Verzeichnisserver) im Intranet des Nutzers implementiert sein kann, und dort zusammen mit den Metadaten M gespeichert. In alternativen Ausführungsformen kann AC auch unverschlüsselt weitergegeben oder mit dem öffentlichen Schlüssel puK des Nutzers verschlüsselt werden.
Wie zuvor besprochen, ist der Ort, an dem Verzeichnisspeicher und Schlüsselspei- eher betrieben werden, unter Umständen ebenfalls wichtig für die Sicherheit, falls durch die Kompromittierung der Metadaten M bereits Schaden entstehen kann. Für ein Unternehmen lägen daher beide Module auf einem jeweils eigenständigen Verzeichnisserver und Schlüsselserver zweckmäßigerweise in einem nicht öffentlichen Rechnernetz, d.h. einem Intranet. Die im Intranet gespeicherten Datenmengen sind auch deutlich kleiner als die in der Cloud gespeicherten Datenvolumina, so dass keine besondere Anforderungen an die Speicherkapazität des Intranetzes besteht. Die Daten aus dem Distributor, welche das Volumen ausmachen, können auf beliebigen (auch unsicheren) öffentlichen Servern einer Cloud gespeichert werden. Eine alternative Ausführungsform würde Verzeichnisspeicher oder Schlüsselspeicher auf einem Nutzer-Endgerät halten, um die Zugriffsmöglichkeiten von außen noch weiter einzuschränken.
Eine weitere alternative Ausführungsform verzichtet auf den Metadaten-Generator und legt lediglich die eindeutige ID des Datensatzes auf dem Verzeichnisspeicher ab. In dieser Ausführungsform enthält M dann nur noch die ID.
Abruf von Daten aus der Cloud (Figur 4)
Fig. 4 zeigt das erfindungsgemäße Wiederabrufen der in der Cloud-Speichervorrich- tung gespeicherten Nutzerdaten D* gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung.
Wie in Fig. 4 gezeigt, kann das Nutzerendgerät weiter die Module Rekombinierer, Dekryptor und Retriever enthalten. Das Modul Rekombinierer bezieht die beiden rekombinierbaren Teildatensätze prK +ΔΑ und -ΔΑ vom Nutzerendgerät und vom Autorisierungsserver und rekombiniert sie zu dem Datensatz des privaten Schlüssels prK. Zum Abrufen des Teildatensatzes -ΔΑ kann optional zuvor eine Authentifizierung des Nutzers an dem Autorisierungsserver erfolgt sein. Der private Schlüssel wird nun im Modul Dekryptor zum Entschlüsseln des im Schlüsselserver gespeicherten, verschlüsselten symmetrischen Schlüssel K* benutzt. Der dann vorliegende symmetrische Schüssel K kann zum Entschlüsseln des im Verzeichnisserver gespeicherten, verschlüsselten Zugriffskode AC* verwendet werden. Der entschlüsselte Zugriffskode AC wird dann an das Modul Retriever geschickt, welches damit die gespeicherten Nutzerdatenpakete Dl *, D2*, Dn* aus der Cloud-Speichervor- richtung abrufen, dann zu den verschlüsselten Nutzerdaten D* zusammensetzen und im Anschluss an das nachfolgende Modul Dekryptor zum Entschlüsseln schicken kann. Im nachfolgenden Modul Dekryptor werden die verschlüsselten Nutzerdaten D* dann mit Hilfe des symmetrischen Schlüssels K entschlüsselt und stehen zur weiteren Verwendung durch das Nutzerendgerät bereit. Die Schritte des Wiederabrufens und Zusammensetzen der verteilt gespeicherten Nutzerdatenpakete Dl *, D2*, Dn* durch das Modul Retriever und des Rekom- binierens der rekombinierbaren Teildatensätze prK +ΔΑ und -ΔΑ vom Nutzerendgerät und vom Autorisierungsserver durch das Modul Rekombinierer können dabei in beliebiger zeitlicher Abfolge ausgeführt werden, insbesondere gleichzeitig.
Speicherung kleinteiliger (telematischer) Datensätze (Figur 5)
Im Bereich telematischer Daten sind die einzelnen erhobenen Datensätze deutlich kleiner als die für eine Cloud-Speicherung üblicherweise vorgesehenen Daten (wie Bilder, Musik, Videos). Bei einer Speicherung solcher kleinteiliger Datensätze, die wie oben beschrieben, beispielsweise von einem telematischen Gerät oder einem
Sensor eines Smart Device erzeugt werden, würde eine Reihe von Nachteilen entstehen, da die zur Verwaltung auf Verzeichnis- und Schlüsselserver notwendige Datenmenge die eigentlichen Nutzdaten mengenmäßig deutlich übersteigen würde. Hierfür ist es vorzuziehen, dass der Enkryptor bzw. der Schlüsselgenerator, wie oben erwähnt, nicht pro Datensatz sondern abhängig vom Datum einen neuen Schlüssel verwenden bzw. erzeugen sollte, da in diesem Fall nur ein Schlüssel pro Zeitraum für andere berechtigte Nutzer freigegeben werden muss. Üblicherweise sind telematische Daten auch nur aufgrund ihrer Menge ein Sicherheitsproblem; der einzelne Datensatz ist in der Regel wenig aufschlussreich.
Nimmt man jedoch an, dass die telematischen Daten von einer Vielzahl an Sensoren erzeugt werden, und diese Sensoren auf unterschiedlichsten Endgeräten lokalisiert sind, so müsste jeder einzelne Sensor einen eigenen Enkryptor, und damit einen eigenen Schlüsselkreis besitzen. Dies wäre eine mögliche Realisierung. Für die Kombinierung der unterschiedlichsten Sensordaten über einen gemeinsamen zeitbezogenen Schlüssel ist es jedoch notwendig, dass der Enkryptor nicht mehr auf dem Gerät lokalisiert ist, das die Daten erhebt (also dem Sensor), sondern über ein Netzwerk zugreifbar ist; ansonsten müsste eine Vielzahl von Enkryptoren auf verschiedenen Endgeräten den gleichen internen Schlüssel K verwenden, was dessen Sicherheit wiederum kompromittieren würde. Ein Versenden unverschlüsselter telematischer Daten an einen Rechner im Internet, auf dem ein Enkryptor läuft, ist jedoch aus sicherheitstechnischen Aspekten abzulehnen, da diese Daten auf dem empfangenden Rechner zunächst unverschlüsselt vorlägen; durch eine Manipulation dieses Rechners (der außerhalb des direkten Zugriffsbereichs des Nutzers läge, wo- mit eine Manipulation schwer nachzuweisen wäre) könnten diese Daten dauerhaft mitgelesen werden.
Fig. 5 zeigt eine Ausführungsform der Cloud-Umgebung, die die sichere Speicherung von telematischen Daten eines Nutzers ermöglicht. Diese telematischen Daten werden beispielsweise von einem in dem Nutzerendgerät integrierten oder damit koppelbaren Smart Device mit Sensor erzeugt, wie zuvor beschrieben.
Wie in Fig. 5 gezeigt, ist in dem telematischen Endgerät mindestens eine Kombination der Module Dekombinierer und Metadatengenerator implementiert. Der Meta- datengenerator erzeugt eine minimale Zahl von Metadaten aus dem Datenpaket (wie z.B. um welche Art von Datum es sich handelt; bspw. ein Bezahlvorgang, ein GPS- Bewegungsprofil, o.a.), sowie eine eindeutige ID (in Art einer UUID) der Daten. Die Daten selber werden im Dekombinierer in zwei Pakete tD+AD und - AD zerlegt. Dies geschieht, um die telematischen Daten tD so zu verändern, dass sie auf weite- ren externen Servern nicht unverschlüsselt vorliegen. Diese zwei Pakete tD+AD und - AD werden jeweils über eine Modulstruktur der Cloud-Speicher Lösung und über sichere Kanäle (bspw. TLS) an zwei unabhängige externe Systeme zur Speicherung weitergegeben. Die Schlüssel der Enkryptoren werden vorzugsweise in einem zeitlichen Abstand neu generiert (und nicht mit jedem Datensatz), und zwar vorzugs- weise z.B. alle vier Wochen, wobei der Generierungszeitpunkt von einem Enkryptor des einen Servers zu dem des anderen Servers um zwei Wochen versetzt ist. Da sich die originalen Daten nur dann wieder herstellen lassen, wenn beide gespeicherten Teilpakete entschlüsselt werden können, lassen sich Daten genau über zweiwöchige Intervalle freigeben (d.h. ein späterer Verwender kann mit einem freigegeben Schlüsselpaar genau nur Daten in einem zweiwöchigen Zeitraum entschlüsseln).
Die Distributoren der beiden unabhängigen Systeme in Fig. 5 kennen sich dabei gegenseitig nicht, liefern den erzeugten Zugriffskode jedoch an ein- und denselben Verzeichnisserver, der auch vom Smart Device bzw. vom Nutzerendgerät sowohl die Metadaten als auch die ID der Daten erhält. Über die ID im Zugriffskode können diese drei Pakete zu einem Verzeichniseintrag zusammengefügt werden.
Die jeweils neu erzeugten Schlüssel K aus den Cloud-Speicher Modulstrukturen werden jeweils mit dem öffentlichen Schlüssel puK des Nutzers verschlüsselt und anschließend im Schlüsselserver gespeichert.
Weitere Anwendungsbeispiele
Die vorliegende Erfindung ermöglicht eine sichere Verwaltung des privaten Schlüssels, ohne dass ein Dritter Zugriff auf den Schlüssel erhält, die Regenerierung des Schlüssels im Falle eines Verlustes, sowie die Verteilung des privaten Schlüssel so über mehrere Endgeräte, dass die Sicherheit des privaten Schlüssels selbst beim Verlust eines Endgerätes nicht kompromittiert wird, siehe den Abschnitt über Authentifizierung weiter oben. Die vorliegende Erfindung ermöglicht weiters die Erstellung und den Betrieb eines sicheren sozialen Netzwerkes (sicheres FaceBook); hier ist die Besonderheit, dass Daten (eingestellte Dokumente, Kurzkommentare oder Bilder) einer ganzen Gruppe von Mitgliedern gleichzeitig zugänglich gemacht werden soll. Dies ist über die Gruppenschlüssel-Funktionalität (s. oben) auf einfache Art sichergestellt. Die In- halte sind dann auch nur den Gruppenmitgliedern sichtbar, nicht dem Dienstanbieter, wie es beim heutigen Facebook der Fall ist. Gegenüber einer Lösung wie Snap- Chat, bei der die„Sicherheit" einfach durch ein schnelles Löschen garantiert werden soll (d.h. Beiträge besitzen eine sehr limitierte Lebensdauer) können hier Inhalte beliebig lange sicher aufbewahrt und gezielt geteilt werden.
Aufgrund des inhärenten Sicherheitsniveaus der Anwendung lassen sich mittels Cloud-Ansatz auch hochsensible Daten, wie sie beispielsweise im Gesundheitswesen entstehen, auf unsicheren / öffentlichen Servern ablegen. Hiermit ließen sich Anwendungsfelder wie beispielsweise das Gesundheitswesen erschließen. In Deutschland scheiterte bislang die Einführung einer Gesundheitskarte, die weitergehende gesundheitliche Details des Patienten speichern könnte, an Sicherheitsbedenken der Politik bzw. der Bevölkerung. In dem vorgestellten Cloud-System mit individueller Verschlüsselung einzelner Datensätze könnten diese Bedenken ausgeräumt werden:
- Gesundheitsdaten würden nicht auf der Karte des Patienten, sondern vom
Arzt jeweils über einen Enkryptor / Distributor im Netz abgelegt.
Daten könnten z.B. auch direkt in der behandelnden Einrichtung (z.B. Krankenhaus) auf eigenen Servern abgelegt werden, die Lesezugriff aus dem Internet erlauben. Der private Schlüssel könnte vorzugsweise auf der Gesundheitskarte des Patienten abgelegt werden. In diesem Fall können Daten nur genau dann gelesen und entschlüsselt werden, wenn die Karte dem Lesenden physikalisch vorliegt.
Das vorgestellte System erlaubt eine vollständige Trennung der Speichersicherheit von Daten und des Inhaltes von Daten. Zur Speichersicherheit werden üblicherweise hochredundante Systeme eingesetzt, damit Daten auch bei Ausfall eines Teilsystems noch gelesen werden können. Um den Inhalt der Daten geheim zu halten, müssen die speichernden Systeme üblicherweise mit weiteren Sicherheitsmerkmalen ausgerüstet werden. Insbesondere die redundante Speicherung, also die Vervielfachung der Daten, ist in der Regel konträr zur Geheimhaltung der Daten. So kann auch in einem hochsicheren Datencenter bei Tausch einer defekten Festplatte prinzipiell ein Teil des Platteninhaltes öffentlich werden, wenn diese nicht vorher speziell gelöscht wurde.
In dem vorgestellten System jedoch hat ein speicherndes System niemals Kenntnis vom Inhalt der gespeicherten Daten. Der Inhalt erschließt sich nur genau dem Eigentümer des verwendeten privaten Schlüssels. Der Vorteil liegt darin, dass selbst bei fehlerhafter Software auf den Servern (Sicherheitslücken wie z.B. Heartbleed) niemals Zugangsdaten oder Inhalte öffentlich werden können.
Gemäß der vorliegenden Erfindung kann das System streng zwischen dem Dateninhalt und Metadaten trennen, wobei selbst Dateiname, Dateityp, sowie Dateigröße zu den Metadaten gezählt werden. Inhalte werden verschlüsselt ohne Bezug auf den Dateinamen/-typ, und ggf. sogar zerlegt in unabhängige Teilpakete auf einem System mehrerer Server gespeichert. Eine Rekonstruktion der ursprünglichen Dateien, oder auch nur der Metadaten ist selbst mittels Zugriff auf die speichernden Server nicht möglich. Ein Vorteil gegenüber bestehenden Systemen besteht also darin, dass selbst bei einer vollständigen Kenntnis des Kommunikationsflusses zwischen Nutzer und Server durch einen Dritten Daten weder Inhalt noch beschreibende Daten jemals
entschlüsselt werden können.
Das System erlaubt im Gegensatz zu bestehenden Systemen - ohne zusätzlichen
Administrationsaufwand des Nutzers - die
Speicherung von Daten als per se unlesbare bzw. inhaltslose Datenpakete Verteilung der Datenpakete auf eine Vielzahl primär unbekannter Daten- Speicher
Beibehaltung der absoluten Datenhoheit bei optionaler gleichzeitiger Änderungsresistenz der Daten
Möglichkeit der Datenpaket spezifischen (nicht an Rechte innerhalb eines Dateisystems gebundenen) Freigabe ohne die Sicherheit anderer Datenpa- kete durch die Weitergabe des Schlüssels zu gefährden
Erhaltung der Datensicherheit selbst bei Kompromittierung eines oder mehrerer Datenspeicher
Möglichkeit die volumenträchtigen Datenanteile auf unsicherem (kostengünstigem) Speicherplatz zu speichern.
Die Erfindung bietet hinsichtlich der Nutzerdatenverwaltung innerhalb einer Cloud- Umgebung die
Unabhängigkeit von der Vertrauenswürdigkeit des Dienst- Anbieters Möglichkeit den privaten Schlüssel zur Verschlüsselung der Daten zu ver- wenden, ohne sich selbst um die Verschlüsselung bzw. Entschlüsselung und die Aufbewahrung und Zuordnung der Schlüssel kümmern zu müssen, gezielte Freigabe einzelner Datenpakete ohne die Sicherheit weiterer Datenpakete zu gefährden
Aufbewahrung des privaten Schlüssels ohne Dritten einen potentiellen Zu- griff auf diesem zu geben Möglichkeit den privaten Schlüssel sicher auf mehrere Endgeräte zu verteilen
Rekonstruktionsmöglichkeit im Verlustfall ohne Dritten den potentiellen Zugriff auf den privaten Schlüssel gegeben zu haben
Die Erfindung bietet hinsichtlich der Verwaltung von telematischen Nutzerdaten die Vorteile einer
Verschlüsselung der entstandenen Daten ohne der Verschlüsselungssicherheit (insbesondere der Sicherheit des implementierten Zufallszahlengenerators) im Daten erzeugenden Gerät vertrauen zu müssen, da die eigentliche Verschlüsselung auf einem weiteren Rechner erfolgt
sicheren Speicherung der entstehenden Daten mit ggf. Freigabemöglichkeit an Dritte über die Freigabe der Schlüssel eines bestimmten Zeitraums, und Garantie, dass die Daten nicht durch den Nutzer (Eigentümer der Daten) verändert worden sind
Die Erfindung ist jedoch nicht auf die konkret beschriebene Ausführungsform beschränkt. Vielmehr sind Abwandlungen hinsichtlich der Reihenfolge von Verfahrensschritten und Modul- und/oder Rechnerstruktur denkbar, ohne den Schutzbereich der beigefügten Ansprüche zu verlassen. Beispielsweise können manche Module auch in einem anderen integriert implementiert sein. Die Rechnereinheiten Autorisierungsserver, Verzeichnisserver und Schlüsselserver wurden als auf eigenständigen Rechnersystemen in einem Intranet oder im Internet implementiert beschrieben. Grundsätzlich können diese Einheiten sich aber auf jeder Art von Rechengerät befinden, das im Zugriff und unter der Kontrolle des Nutzers steht, unter anderem auch auf Endgeräten des Nutzers. Ferner ist mit der vorliegenden Erfindung auch ein neuartiges System denkbar, dass die bekannten klassischen Aspekte der Cloud-Speicherung, Kollaboration (Zusammenarbeit im Team auf einzelnen Dateien) und des sozialen Netzwerks (wie bspw. Facebook oder WhatsApp) in einem einzigen System zusammenführt.
Dabei wird das System, wie beschrieben, in einen Autorisierungsserver, einen Verzeichnisserver und Schlüsselserver, beliebige Speicherserver und ein oder mehrere Nutzer-Endgeräte unterteilt. Auf dem Verzeichnisserver liegen zu jeder Zeit mehrere Verzeichnis-Datensätze, z.B. öffentliche und private Metadaten zu jedem Da- tensatz D, sowie der verschlüsselte Zugriffscode AC* zum Wiederauffinden des kompletten Datensatzes D auf den Speicherservern. Ein Eintrag kann jedoch auch existieren, ohne dass ein Datensatz auf externen Servern referenziert wird; in diesem Fall ist der Datensatz äquivalent zu einem Ordner in einer klassischen Dateisystemstruktur. Jeder Datensatz auf dem Verzeichnisserver ist durch eine eindeutige Adresse, beispielsweise eine URL oder eine ID, referenzierbar. Des Weiteren können zu jedem solchen Datum auf dem Verzeichnisserver mehrere Kinder (d.h. Knoten, die untergeordnet verlinkt sind) referenziert werden. Herkömmlicherweise sind dies Dateien in einem Ordner (Dateisystem), oder Kommentare (wie in einem sozialen Netzwerk). Um die Anonymität und Sicherheit zu erhöhen, liegt die Liste der referenzierten Kinder beispielsweise verschlüsselt vor, so dass sie nur unter Kenntnis des Schlüssels K entschlüsselt werden kann. Dieser Fall ist der mit der höchsten Sicherheit, jedoch gleichzeitig mit den höchsten Anforderungen an die Netzwerkgeschwindigkeit und das Nutzer-Endgerät, da die Liste der Kinder dann nur auf dem Nutzer-Endgerät entschlüsselt werden kann. Beispielhaft könnte auch die Liste der Kinder als normale Tabelle auf der internen Datenbank des Verzeichnisservers vorliegen, während die Adressen der Kinder innerhalb dieser Tabelle nur verschlüsselt vorliegen. In diesem Fall wäre es möglich, die Zahl der Kinder einfach auf dem Verzeichnisserver bestimmen zu lassen. Es ist jedoch auch denkbar, dass die URL für den Verzeichnisserver lesbar vorliegt; in diesem Fall kann die Liste der Kinder direkt durch den Verzeichnisserver ausgewertet werden; bei einem Angriff auf den Verzeichnisserver wäre es den Angreifern jedoch möglich, die Verlinkung der einzelnen Datensätze zu lesen (wenn auch die Inhalte verborgen, d.h. verschlüsselt bleiben). Den konkreten Anwendungsfall entscheiden die Sicherheitsanforderungen und die Anforderungen an die Zugriffsgeschwindigkeit.
In einem solchen Verzeichnissystem können sowohl die Anforderungen herkömmlicher Dateisysteme erfüllt werden— es gibt Ordner und darunter gelegene Dateien oder ggf. weitere Ordner in einer Hierarchie— als auch die Anforderungen sozialer Netzwerke oder Chat-Systeme— nämlich dass es zu jedem Beitrag, sei es ein Bild, ein Video oder eine Wortmeldung Kommentare geben kann (zu denen es ggf. in weiteren Hierarchiestufen wiederum untergeordnete Kommentare geben könnte). Dieses Verzeichnissystem ist dabei vollkommen privat, da alle relevanten Inhalte (auch gewisse Metadaten) so verschlüsselt sind, dass nur berechtigte Nutzer oder Nutzergruppen diese einsehen können. Selbst ein Hackerangriff auf den Verzeich- nisserver kann keine zusätzlichen Informationen offenlegen. Die tatsächlichen Inhalte liegen ohnehin auf einem oder mehreren unabhängigen Speicherservern. Das bedeutet, dass sowohl ein völlig privates Abbild eines Dateisystems verwaltet werden kann— wie bei bekannten Cloud-Speicherdiensten, nur mit deutlich erhöhter Sicherheit, oder die Daten eines sozialen Netzwerks, wobei jeder Beitrag nur von denjenigen eingesehen werden kann, die persönlich von dem die Daten einstellenden Nutzer berechtigt wurden. Der Betreiber des Verzeichnisservers hat keine Möglichkeit, etwas über den Inhalt oder— in den oben beschriebenen höchsten Sicherheitsstufen— auch nur über die Struktur (wer verlinkt was, wer hat die meisten Kommentare, etc.) herauszufinden.
Um Zugriff auf die Daten zu erhalten, muss zunächst wie beschrieben ein Login auf dem Autorisierungsserver erfolgen. Dieser erstellt für die aktuelle Sitzung ein Token von zeitlich begrenzter Gültigkeit, das es dem Nutzer erlaubt, sich gegenüber dem Verzeichnis- und Schlüsselserver zu autorisieren. Über eine bekannte Einstiegs- URL oder ID kann der Nutzer auf seinem Endgerät dann die Daten eines Einstiegsknotens abrufen inklusive deren Kinder; von solchen Einstiegsknoten aus kann die Struktur der Kinder bzw. Links durchwandert werden. Um eine Sicht, wie in klassischen sozialen Netzwerken zu ermöglichen, sind vorzugsweise unter den öffentlichen Metadaten auch die ID des erstellenden Benutzers sowie das Datum der Erstellung abgelegt; bei der Struktur, die die Kinder beschreibt, wäre vorzugsweise der Ersteller dieses Links und das Datum der Verlinkung. Der Link-Ersteller ist nicht notwendigerweise der Ersteller des verlinkten Datensatzes selber; es wäre denkbar, dass ein Leser als Kommentar auf einen Beitrag den Beitrag eines anderen Nutzers verlinkt; wobei natürlich die ursprünglichen Leserechte erhalten bleiben (d.h. der Ersteller des Beitrags, unter dessen Beitrag jemand einen Link auf einen anderen Datensatz eingestellt hat, kann unter Umständen den Inhalt dieses Links nicht sehen).
Ist die Struktur wie oben ausgeführt vorhanden, kann statt eines einzelnen Einstiegsknotens auch eine Suche auf der Datenbank des Verzeichnisservers erfolgen. Eine mögliche Suche wäre:„ermittle alle Knoten, auf die der Nutzer Zugriff hat (d.h. die von ihm erstellt wurden oder die für ihn freigegeben wurden) und sortiere diese nach Datum absteigend". In diesem Fall wäre das Ergebnis beispielsweise ähnlich zu dem, dass der Nutzer in einem herkömmlichen sozialen Netzwerk sehen würde: er würde die neuesten, für ihn freigeschalteten Beiträge nach Datum sortiert sehen können. Die Entschlüsselung für die Menge der auf dem Nutzer-Endgerät dargestellten Datensätze würde auf dem Nutzer-Endgerät erfolgen; da hier in der Regel nur eine kleine Untermenge der insgesamt vorliegenden Datensätze dargestellt werden kann, ist dies ohne weiteres in kurzer Zeit möglich. Lediglich wenn der Nutzer sich entscheidet, weitere Datensätze darzustellen (z.B. den Bildschirm zu scrollen), würde ein erneuter Netzwerkzugriff auf die Datensätze und eine erneute Entschlüsselung auf dem Endgerät notwendig. Um die Nutzerführung bezogen auf die Vielzahl möglicher Berechtigungsprofile zu erleichtern, ist bei der Neuerstellung eines Knotens beispielhaft eine einfache Regel für die Berechtigung anzuwenden: ein neuer Knoten, der als Kind eines auf dem Verzeichnisserver existierenden Knotens erstellt wird, erbt zunächst die Sichtbar- keitseinstellungen / Freigaben des Eltern-Knotens. In diesem Fall kann der Nutzer einen leeren Knoten (Ordner, siehe oben) anlegen und diesem Leserechte auf alle ihm bekannten Nutzer des Netzwerks erteilen. Fügt er dem Ordner einen Beitrag hinzu, würde dieser ebenfalls für alle diese Nutzer lesbar sein; diese Kinder könnten den Ausgangspunkt für das soziale Netzwerk des Nutzers sein. Legt der Nutzer da- gegen neue Knoten unter einem Ordner an, der nur für ihn lesbar ist, sind die Kinder ebenfalls vollständig privat; der Ordner kann dann den Ausgangspunkt der Cloud- Sicherung darstellen.

Claims

Ansprüche
Verfahren zum Verwalten von Nutzerdaten eines Nutzerendgeräts, wobei das Verfahren folgende Schritte aufweist:
- Erzeugen eines Schlüsselpaars aus privaten Schlüssel prK und öffentlichen Schlüssel puK,
- Aufteilen des privaten Schlüssels prK in mindestens zwei Teildatensätze, wobei die mindestens zwei Teildatensätze mittels einer bijektiven Operation rekombinierbar erzeugt werden,
- Verschlüsseln von Nutzerdaten D und Speichern der verschlüsselten Nutzerdaten D* in einer über ein Netzwerk zugänglichen externen Speichervorrichtung, und
- Wiederabrufen und Entschlüsseln der verschlüsselt gespeicherten Nutzerdaten D* aus der externen Speichervorrichtung, wobei das Wiederabrufen und Entschlüsseln ein Wiederherstellen des privaten Schlüssels prK durch Rekombinieren der beiden Teildatensätze mittels der zum Aufteilen inversen bijektiven Operation aufweist.
Verfahren nach Anspruch 1 , wobei das Verschlüsseln von Nutzerdaten D ferner folgende Schritte aufweist:
- Erzeugen eines symmetrischen Schlüssels K, und
- Verschlüsseln der Nutzerdaten D mit dem symmetrischen Schlüssel K.
Verfahren nach Anspruch 1 oder 2, wobei das Speichern von Nutzerdaten D ferner aufweist:
- Zerlegen und verteiltes Speichern der verschlüsselten Nutzerdaten D* in der externen Speichervorrichtung und
- Erzeugen eines Zugriffskodes AC. Verfahren nach Anspruch 3, wobei das Wiederabrufen und Entschlüsseln der verteilt gespeicherten, verschlüsselten Nutzerdaten D* ferner aufweist:
- Abrufen des gespeicherten Zugriffskode AC,
- Abrufen der verteilt gespeicherten verschlüsselten Nutzerdaten D* mit Hilfe des Zugriffskode AC, und
- Wiederherstellen der Nutzerdaten D durch Entschlüsseln der verschlüsselten Nutzerdaten D* mit dem symmetrischen Schlüssel K.
Verfahren nach Anspruch 4, das ferner ein Verschlüsseln des Zugriffskodes AC mit dem symmetrischen Schlüssel K, ein Speichern des verschlüsselten Zugriffskode AC* und ein Entschlüsseln des Zugriffskodes AC mit dem symmetrischen Schlüssel K aufweist
Verfahren nach Anspruch 1 bis 5, wobei die Nutzerdaten D kleinteilige Datensätze tD eines telematischen Geräts sind, die mittels einer bijektiven Operation in mindestens zwei Teildatensätze derart aufgeteilt werden, dass die mindestens zwei Teildatensätze miteinander rekombinierbar verknüpft sind.
Verfahren nach einem der Ansprüche 1 bis 6 , das ferner vor dem Speichern der Nutzerdaten D ein Extrahieren von Metadaten aus den Nutzerdaten aufweist.
Verfahren nach eine der Ansprüche 1 bis 7, das vor dem Wiederherstellen des privaten Schlüssels prK ferner ein Authentifizieren des Nutzers vorsieht.
Verfahren nach einem der Ansprüche 2 bis 8, wobei der symmetrische Schlüssel K erst nach Ablauf einer vorbestimmten Zeitdauer neu erzeugt wird. Verfahren nach einem der Ansprüche 2 bis 9, das ferner ein Verschlüsseln des symmetrischen Schlüssels K mit dem öffentlichen Schlüssel puK und ein Entschlüsseln des verschlüsselten symmetrischen Schlüssel K* mit dem privaten Schlüssels prK aufweist.
Verfahren nach einem der Ansprüche 1 bis 10, das ferner zur Verwaltung von Nutzergruppen zumindest eine weitere Aufteilung des privaten Schlüssels prK mittels einer weiteren bijektiven Operation vorsieht.
System zum Verwalten von Nutzerdaten eines Nutzerendgeräts, wobei das System aufweist:
• mindestens ein Nutzerendgerät
• mindestens eine externe Speichervorrichtung, auf die das mindestens eine Nutzerendgerät über ein vorzugsweise öffentliches Netzwerk zugreifen kann, um darauf Nutzerdaten, die von dem mindestens einem Nutzerendgerät erzeugt werden, zu speichern und wieder abzurufen, und
• eine Mehrzahl an mit einander kommunizierenden Modulen, wobei die Mehrzahl an Modulen zum Ausführen eines Verfahrens nach Anspruch 1 zumindest aufweist:
- einen Schlüsselpaar-Generator,
- einen Dekombinierer,
- einen Enkryptor
- einen Distributor,
- einen Rekombinierer,
- einen Retriever und
- einen Dekryptor.
13. System nach Anspruch 12, das zum Ausführen eines Verfahrens nach den Ansprüchen 2 bis 11 ferner ein Modul Schlüsselgenerator und einen Schlüsselserver aufweist.
14. System nach Anspruch 12 oder 13, das ferner einen Autorisierungsserver aufweist.
System nach Anspruch 12 bis 14, das ferner einen Verzeichnisserver aufweist.
System nach Anspruch 15, wobei der Autorisierungsserver, Schlüsselserver und der Verzeichnisserver auf einem oder mehreren Rechnern implementiert sind, der/die sich in einem vorzugsweise nicht öffentlichen Rechnernetz des Nutzers befindet/befinden.
17. System nach einem der vorhergehenden Ansprüchen 12 bis 16, das ferner ein Modul Metadatengenerator zum Extrahieren von Metadaten aus den Nutzerdaten aufweist.
18. System nach einem der vorhergehenden Ansprüchen 12 bis 17, wobei der mindestens ein Nutzerendgerät ein telematisches Gerät ist, dass kleinteilige Datensätze erzeugt, und ferner zum Ausführen eines Verfahrens nach Anspruch 7 zwei unabhängige externe Server aufweist.
PCT/EP2016/054823 2015-03-05 2016-03-07 Verfahren und system zum verwalten von nutzerdaten eines nutzerendgeräts WO2016139371A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102015103251.1A DE102015103251B4 (de) 2015-03-05 2015-03-05 Verfahren und System zum Verwalten von Nutzerdaten eines Nutzerendgeräts
DE102015103251.1 2015-03-05

Publications (1)

Publication Number Publication Date
WO2016139371A1 true WO2016139371A1 (de) 2016-09-09

Family

ID=55486660

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2016/054823 WO2016139371A1 (de) 2015-03-05 2016-03-07 Verfahren und system zum verwalten von nutzerdaten eines nutzerendgeräts

Country Status (2)

Country Link
DE (1) DE102015103251B4 (de)
WO (1) WO2016139371A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111586445A (zh) * 2020-05-14 2020-08-25 中国人民公安大学 一种视频数据传输方法及装置
DE112021001766B4 (de) 2020-06-03 2024-06-06 International Business Machines Corporation Inhaltskontrolle durch datenaggregationsdienste dritter

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102017219261A1 (de) * 2017-10-26 2019-05-02 Bundesdruckerei Gmbh Bereitstellen physiologischer Daten
EP4027282A1 (de) * 2021-01-11 2022-07-13 Siemens Aktiengesellschaft Vorrichtung, system und verfahren zur zugriffsbeschränkten bereitstellung einer zeitabhängigen benutzungs-kennzahl für ein gerät

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003065639A2 (en) * 2002-01-30 2003-08-07 Cloakware Corporation System and method of hiding cryptographic private keys
DE202008007826U1 (de) * 2008-04-18 2008-08-28 Samedi Gmbh Anordnung zum sicheren Austausch von Daten zwischen Dienstleister und Kunde, insbesondere zur Terminplanung
US20130208893A1 (en) * 2012-02-13 2013-08-15 Eugene Shablygin Sharing secure data
WO2014172773A1 (en) * 2013-04-25 2014-10-30 FusionPipe Software Solutions Inc. Method and system for decoupling user authentication and data encryption on mobile devices
CA2886511A1 (en) * 2013-06-11 2014-12-18 Yin Sheng Zhang Assembling of isolated remote data

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6072876A (en) * 1996-07-26 2000-06-06 Nippon Telegraph And Telephone Corporation Method and system for depositing private key used in RSA cryptosystem

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003065639A2 (en) * 2002-01-30 2003-08-07 Cloakware Corporation System and method of hiding cryptographic private keys
DE202008007826U1 (de) * 2008-04-18 2008-08-28 Samedi Gmbh Anordnung zum sicheren Austausch von Daten zwischen Dienstleister und Kunde, insbesondere zur Terminplanung
US20130208893A1 (en) * 2012-02-13 2013-08-15 Eugene Shablygin Sharing secure data
WO2014172773A1 (en) * 2013-04-25 2014-10-30 FusionPipe Software Solutions Inc. Method and system for decoupling user authentication and data encryption on mobile devices
CA2886511A1 (en) * 2013-06-11 2014-12-18 Yin Sheng Zhang Assembling of isolated remote data

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111586445A (zh) * 2020-05-14 2020-08-25 中国人民公安大学 一种视频数据传输方法及装置
CN111586445B (zh) * 2020-05-14 2022-04-12 中国人民公安大学 一种视频数据传输方法及装置
DE112021001766B4 (de) 2020-06-03 2024-06-06 International Business Machines Corporation Inhaltskontrolle durch datenaggregationsdienste dritter

Also Published As

Publication number Publication date
DE102015103251B4 (de) 2017-03-09
DE102015103251A1 (de) 2016-09-08

Similar Documents

Publication Publication Date Title
DE102018127126A1 (de) Erneute Registrierung von physikalisch unklonbaren Funktionen aus der Ferne
DE112017006020T5 (de) Verfahren und System für suchmusterblinde dynamische symmetrische durchsuchbare Verschlüsselung
DE102009001719B4 (de) Verfahren zur Erzeugung von asymmetrischen kryptografischen Schlüsselpaaren
DE60020293T2 (de) Erzeugung eines wiederholbaren kryptographischen Schlüssels basierend auf variablen Parametern
US20200404023A1 (en) Method and system for cryptographic attribute-based access control supporting dynamic rules
EP2409452B1 (de) Verfahren zur bereitstellung von kryptografischen schlüsselpaaren
DE112018000779T5 (de) Tokenbereitstellung für Daten
DE202018002074U1 (de) System zur sicheren Speicherung von elektronischem Material
DE112020005429T5 (de) Zufallsknotenauswahl für zulassungsbeschränkte Blockchain
DE102012213807A1 (de) Steuerung des Lightweight-Dokumentenzugriffs mithilfe von Zugriffskontrolllisten im Cloud-Speicher oder auf dem lokalen Dateisystem
DE102017214768A1 (de) Kryptographische Sicherung für eine verteilte Datenspeicherung
DE102015103251B4 (de) Verfahren und System zum Verwalten von Nutzerdaten eines Nutzerendgeräts
DE112021005561T5 (de) Implementieren einer widerstandsfähigen deterministischen verschlüsselung
DE112021003270T5 (de) Deduplizierung von mit mehreren schlüsseln verschlüsselten daten
EP3629516B1 (de) Dezentralisierte identitätsmanagement-lösung
DE102019101195A1 (de) Verfahren zum sicheren Übermitteln einer Datei
EP2807788A2 (de) Verfahren zum schreiben und lesen von daten
DE102013019487A1 (de) Verfahren, Vorrichtungen und System zur Online-Datensicherung
EP3747151B1 (de) Verfahren zur generierung metadaten-freier bäume
DE102008042406A1 (de) Verfahren zum sicheren Austausch von Daten
EP2110980B1 (de) Sichere serverbasierte Speicherung und Freigabe von Daten
DE102006009725A1 (de) Verfahren und Vorrichtung zum Authentifizieren eines öffentlichen Schlüssels
DE202015005361U1 (de) Vorrichtung, die Zugriffsschutz für strukturhaltige verteilte Daten realisiert
EP4033694B1 (de) Verfahren und vorrichtung zur vereinheitlichung von blockchain adressen
DE102018126763B4 (de) Kryptographieverfahren

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

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 16708652

Country of ref document: EP

Kind code of ref document: A1