DE102005002340A1 - Digital trust information allocating, transmitting and using method for network system, involves transmitting token, with trust and secret information, and public key for asymmetric encryption to trust bearer, who is allowed as token`s user - Google Patents

Abstract

The method involves providing a trust source to produce digital trust information. A token, with the trust information in un-coded form and secret information in coded form, is issued by the source. The secret information is known only to the source. The token and a public key for asymmetric encryption are transmitted to a trust bearer. The bearer is allowed as the user of the token to the source for using the trust information. An independent claim is also included for a network system including a subscriber as a trust source.

Description

The The present invention relates to a method and a network system, in which digital trust information is given, passed on and / or can be used. Currently is a trend towards "ubiquitous computing" to make out at which computer penetrate into more and more areas of everyday life in more and more devices of the everyday Find a new life.

there is foreseeable that in the future Security systems providing the authorization information to the service user take off, opposite usual Systems that store the data centrally, users better be accepted. Furthermore, by decentralization of the authorization information the administra tion costs are lowered.

The Objective of the administration of user rights (Permission Management) is to determine which subjects which permissions in relation to a set to have objects. The objects are usually one Resource of some value, which is why you do not have access grant to everyone would like to. In the real world could an object e.g. be your own apartment: it is clear that on it not everyone should have access, and the people (subjects) who trustworthy are enough, get their own key; that's what she's for Access granted.

at the objects can also be more abstract resources, such as. a text document in a file system, main memory in a computer, computing time or access to a service, which offers a specific service. The subjects can also be more abstract nature, e.g. Processes, devices etc.

The Subject can conventionally on the object just above access an accessing mechanism that exists between the subject and the object is arranged. This implements a specific procedure to guarantee compliance with user permissions. comes he concludes that access is allowed, he allows him otherwise it prevents him. An access to the access mechanism over is not possible because it is the only interface for the object.

As a general rule There are two types of methods to grant user permissions Manage: Access Control Lists and Capabilities / Tickets / Tokens.

at Use of Access Control Lists the user information about Users and their permissions are stored in the object to be protected or at the instance that protects the object.

In In this case, the access mechanism therefore accesses an access control list (Access Control List, ACL), which specifies which Subject opposite the object has which rights.

at Use of capabilities, tickets and tokens owns the subject even the authorization in the form of a token. When accessing the Object, the content of the token is presented to the accessor; and this then decides whether the access is allowed. The different names for this procedure results from the different areas in which this authorization procedure is applied.

Around the rights for Manage objects in an operating system (e.g., for files, Process generation rights, etc.), were in the operating system Amoeba (and other research operating systems) introduced permissions in the form of "capabilities" consist of a data structure containing the authorization information contains and can across from Operating system functions are used as authorization. electronic Ticket systems represent an application which the procedure of the ticket purchase (e.g., theater ticket) on a technical level. The tickets contain a certain, less extensive form of the Authorization (space allocation for a small period of time), and are digitally signed by the exhibitor. To this functionality To replicate, a public-key infrastructure is necessary, which the keys managed.

• • Gebunden an ein gewisses Kontingent der Ressource, z.B. die Erlaubnis, 100 Blatt Papier auszudrucken Hier muss das System Buch führen, wieviel bereits verbraucht worden ist, damit das unerlaubte Kopieren des Tokens erkannt werden kann.
• • Eine generelle Berechtigung Hier ist keine zentrale Buchhaltung notwendig. Allerdings kann man dann nicht verhindern, dass ein Token (vom System unbemerkt) kopiert werden kann.

Token systems allow to store arbitrary permissions in a protected data structure. Anyone who possesses such a token can show this and thus initiate the corresponding actions or services. There are two classes of permissions that can be stored in the token:

• • Tied to a certain contingent of the resource, eg the permission to print 100 sheets of paper Here the system has to keep a record of how much has already been used, so that the unauthorized copying of the token can be recognized.
• • A general authorization No central accounting is necessary here. However, you can not prevent a token (unnoticed by the system) from being copied.

• • Der Dienstanbieter, welcher die Ressourcen anbietet und die entsprechenden Berechtigungen verwaltet.
• • Der Dienstnutzer, der Berechtigungen zugeteilt bekommt und die Dienste damit nutzen kann.

In the context of ubiquitous computing, the term service plays a central role. So the resources available become over Services provided. For example, access to a printer is enabled by a print service. The participants in these scenarios are thus:

• • The service provider that provides the resources and manages the appropriate permissions.
• • The service user who is granted permissions and who can use the services.

existing Token systems are designed to protect objects of high value. this will et al achieved by using a public key infrastructure (PKI). For objects with a lower value, such a procedure can also do without PKI, with the advantage that the procedure becomes simpler and now guarantees anonymity can.

unconditional anonymity is not necessarily desirable from the point of view of the service provider, there in the case of abuse a possibility for later Identification of identities helpful. On the other hand, anonymity offers the user a more pleasant Experience, which is ultimately in the interest of the provider.

One Problem that arises is proof of whether a token has been lawfully changed is. conventional Solve systems this problem by means of a PKI, by making any change by the corresponding Participant is signed. The token-in-charge system can now check (using the public keys from the PKI), if the signature is correct, and the signer is entitled to pass on these rights.

adversely however, this requires that a public-key infrastructure be created, in the case of each participant who makes changes and the Token signed, for all other participants accessible a public one key must be deposited. The technical effort is therefore large and suitable not synonymous for the above-mentioned ubiquitous Computing with a not only very big, but also strong changing number of participants.

The The present invention therefore has for its object a token-based Method and a token-based Network system available too provide, in a simple way, access to services secured carried out can be.

These The object is achieved by the method according to claim 1 and the network system solved according to claim 48. Advantageous developments of the method and the network system according to the invention are in the respective dependent claims given.

critical in the present invention is now that a source of trust, For example, a service or the like another participant as a trust carrier issue and submit a token by the authority of this participant, the service and the like the source of trust or a service associated with it or the like to use. According to the invention now contains the Token not just the trust information, such as a permission, but also in addition a secret of the source of trust - possibly together with the trust information or a hash value thereof - in encrypted form. The encryption takes place with any key with any encryption method, symmetrical or asymmetrical. In the case of a symmetric key is this secret from the source of trust. advantageously, the encryption takes place but with the same public key a key pair for asymmetric encryption, which was added to the token or passed separately from the token becomes. As a secret you can serve any digital data that only the Trust source are known.

Instead of is the initial trust information encrypted to insert in the token is it also possible the initial trust information at or through the trust source to save or save. A source of trust can a single network participant or a composite of several Be participants.

On this way it is possible that at redemption of the token, i. at presentation by a participant of the token at the trusted source, only the source of trust exclusive to the associated private key knows the key pair, completely decrypt the encrypted information contained in the token and on integrity as well on unauthorized changes the right, e.g. an unauthorized extension, can check. This ensures that that any unauthorized modification of the Tokens at the source of trust can be determined. Should be one change have been made, the token can be invalidated.

Otherwise the user may be granted the authorization granted to him in the token be granted for the use of a service or the like.

Of course, the token can be passed on as a digital data structure between individual participants of the network or possibly also copied. Here and in the following between a token and his Copy, since data structures can be copied in an indistinguishable manner. Thus, if we talk about a token in the following, then this can also be a copy of the token itself and vice versa.

Of the Sharing participants as trust can use the token in the Change passing on. For this he can use the trust information in the token, e.g. Authorization, replace with another trust information or supplement by a reduced or otherwise modified trust information. This change can additionally the token in encrypted Form are added, with different encryption options to offer.

To the one can change or new trust information with the present public key encoded become. This ensures that that only the source of trust is final to this encrypted information can come and check, whether in the unencrypted Part of the token modifications were carried out unauthorized. Alternatively, the relaying trust can also use this trust information with a key known only to him for the symmetric encryption encrypt. This has the advantage that the encryption procedure due to the shorter Length of the symmetrical key compared with the public key a key pair for the asymmetric encryption much faster and with less computation and less storage space carried out can be. This symmetric key can then also be the token in encrypted Form with the encryption of the symmetric key with the public key he follows. Even so, it is guaranteed that the source of trust in presentation the token opposite her also to the enigmatic, changed Trust information comes and so can perform an integrity check.

Essential Here can still be further secured the method by at every re-encryption an unencrypted Token component by one of the trusted carriers of this the unencrypted Component not encrypted independently, but also at least with parts of the already encrypted Share in the token. In this way can be effected that the encryption result for the to be re-encrypted Part of that already encrypted part of the token. this leads to to further improve the integrity verifiability of the token. As such again mitzuverschlüsselnder already encrypted Part of the token offers the secret of trust or also a part of it. The encryption can also be done with block separation done so that with further later encryptions always only the same already multiple encrypted part the token is re-encrypted becomes.

In another variant is sufficient it too, instead of the complete one encrypted, changed trust information just a hash value of the changed trust information the token in encrypted Add form, being the encryption also with the public Key, possibly together with the one or more times already encrypted Secret of the source of trust can be done. In this case is it necessary, all Confidence change information in plain text in the token to deposit in the decryption the integrity every step of the token change.

The inventive system has a lot of advantages over those in the prior art already existing systems. First, it creates the natural trust as is usual between people is down to the digital level. Because as in the natural Case a person can give an authorization to a second person, e.g. to use customer information and this permission then can delegate (possibly in limited form), can also here grant an authorization and continue to be delegated. The trust can be expressed digitally be enforced by the system.

In same as in the natural one System allows the present invention complete anonymity of the user. The user does not have to face identify the system, but merely present the token. So there are no user-related usage data central or elsewhere. In existing systems, such as authentication systems, the user must register so that usage data is at one central location and linked to the user can. This opens a not inconsiderable abuse potential, which is already the case with the respective user to changed Working behavior, often with reduced efficiency of the overall system leads. In the present invention However, the user can be guaranteed that no abuse due to centrally stored usage data is available.

Last but not least, the present system allows the usual consensus-bound identification in natural systems. Every security system as well as this one must be prepared for the event that a participant misuses the trust placed in it and improperly uses the acquired, for example, inherited rights. In the natural system, whose functio With the present invention, it is usually possible to identify the abusive user in order to check the existing relationships of trust and to motivate the participants not to allow this case of abuse to occur in the future.

Also Here, the abuse prevention or abuse control takes place in the prior art digital systems by authentication of a Participant to participate in the system. For this he has his identity reveal what all the above already described disadvantages draws.

at According to the present invention, a "consensus-bound identification" becomes possible User who redeems a token, can locate later be done by tracking the token's passing chain over all passing participants away. For this it is only necessary that every participant for records to which other participant he the token (or his Copy). So, starting from the source of trust all participants in the chain of trust about the misuse of trust informed, so can to confirm this, to whom you passed the token. That's the way it is possible, determine the last owner of the token. As in the natural However, it is synonymous for one system Trust carrier, who has passed on a token, possible, the responsibility for the abuse to take on and the true identity of the abuse causing Protect participant. The request to whom a trusted agent passes the token has, can thereby advantageously by a participant of the network system who is particularly entitled to do so, ie an "abusive officer." A follow-up however, may also be along the relaying chain of the token, for example based on the source of trust.

Farther is the inventive method and the system of the invention very simple of user rights management. Firstly, a very simple Rights distribution by the trust only issuing tokens and otherwise nothing else to worry about. It is not additional administrative effort required. The source of trust just needs to be protected Form the private key of the key pair for the asymmetric encryption record.

Summarized the following advantages result with the method according to the invention:

incorruptibility

No Participant can create tokens without authorization.

Possibility to change (Modification) of the token

Everyone Participant can own a token to pass on to another participant. He can do that too by asking only a subset of the trust information given to him, for example, permission, passes. The trust information or their value is thus ringerbar within the relay chain or also qualitatively, for example with regard to different authorizations, Restrictable.

Protection against unauthorized change (Integrity protection)

A unauthorized modification of the token, such as an increase in the Confidential or an extension of rights is prevented, so that no use of resources over each inherited level of trust out possible is.

Subsequent traceability the chain of trust

Also the subsequent, Consensual pursuit of the chain of trust is guaranteed by the consensus-bound identification of each token received Participant. It is therefore possible the chain of trust over the individual participants who receive a token and, if necessary, to pass on, to construct clearly.

Subsequent legal modification is possible if, in addition to the invention described so far, a possibility is created of centrally locking a token or modifying its content. This is necessary if, after issuing or passing on a token, too many or too few rights or the like have been granted. Such subsequent rights modification can be enabled by the use of a Permission Update List (PUL). This can be set up centrally in the network and is used to store changes or blocks of trust information or tokens. When checking a token for its content and integrity, it is now possible to check in the PUL whether a modification, for example a higher or lower authorization or the like, has been deposited for this token. If so, the trust information in the token can be modified accordingly. Different priority modes can be used. For example, if the modification is later Timestamp as the last change of the token itself, the modification stored in the PUL can be taken into account. Alternatively, the least privilege stored in the PUL or the token itself can be taken into account.

One Protection against unauthorized disclosure or copying a token is also possible. For this purpose, various methods are already available in the prior art, for example through the personalization of tokens or through password-protected storage of the token with the respective trust carrier. This can be, for example also using a personal, digital assistant (PDA) with password prompt, fingerprint scanner or the like. This allows it to be centralized To renounce the authentication of the trust carrier.

One Copy protection can be achieved by adding more information to the token added be, e.g. a bit is set, stating that this token may not be copied. Together with the use of so-called "safer Hardware "can a copy protection can be achieved. It makes sense, if under certain Conditions not only the source of trust but every trusted in the Pass-through chain of the token insert this information into the token or may put in this.

in the Below are some examples of the inventive design a method or a network structure. Show it

1 a diagram of the passing of a token within a network;

2 the passing on of tokens with change of the trust information;

3 to 9 various embodiments of the present invention.

In 1 the general data flow is shown in a network system. Such a system includes a plurality of subscribers, in 1 at least the "service provider" as a source of trust ("trust source"), as well as three other participants as a trust ("trust bearer", "user"). The trusted entities are divided into the two groups "Trust Bearer" and "User".

The service provider as a source of trust in the present example represents a service or service provider (eg for a print service). This issues a token which contains a specific trust information, here as in the following examples an authorization to use its service. Such a privilege represents a trust towards the first trust bearer who receives the token from the source of trust. The flow of trust ("Trust Flow") is in 1 modeled as a cycle, with the service provider being the source of that cycle. The trust, which is physically represented as a token, can now be passed on via several trusted entities as a stopover until it arrives at the last trusted bearer as user ("user") 1 the token at the service provider to initiate a service. As in 1 indicated by the reduced width of the arrows in the course of the flow of trust, any trust in the transfer of the token can change the trust, preferably lower, so restrict the permissions received.

There in this network the information (tokens) only in one direction flows, is from a user perspective, the communication needs minimized. There are just the steps "Authorization get "and" permission redeem "in the minimal case required. The delegation of trust to another trust is offline possible, i.e. without access to a central infrastructure.

• • Benutzerberechtigungen für einen Dienst (z.B. Druckdienst, Kaffeeautomat, Hausbussteuerung, Dateidienst etc.)
• • Vertrauensinformationen
• • Kontextinformationen, in dem das Token gültig ist (z.B. Zeiträume, Ort etc.)
• • Kontextinformation zu dem Kontext, in dem das Token ausgestellt worden ist (z.B. Zeitpunkt, Ort, etc.)
• • Situation

The method presented here and also the embodiments according to the invention, as from 3 uses tokens to convey trust information. Trust information can be included:

• • User privileges for a service (eg print service, coffee machine, house bus control, file service, etc.)
• • trust information
• • Context information in which the token is valid (eg time periods, location, etc.)
• Context information about the context in which the token was issued (eg time, place, etc.)
• • situation

2 shows an extension of this in 1 represented network and method. In 2 It can be seen that a token issued by a service provider contains, on the one hand, a secret of the service provider and an authorization value (Permission) whose value was selected as 10 for the present example. This token is sent to the first trust. The first trust can now pass the token to a second trust. He has the ability to modify the authority provided with the token authorization, in particular to reduce. This can be done by, as in 2 shown, the content of the token is supplemented by another permission information perm = 5. The second trusted entity can then pass the token to a third trusted trust. In 2 this is done under Add The third trusted entity may give this token to the service provider and redeem the permission perm = 3 ascribed to it in the token for use of a service.

The order of the data fields in the token is in 2 and the other figures selected only by way of example and has no special meaning.

When New trust information can be provided by the trusted party Passing not just a changed one Trust information, but also information about how the original Trust information should be modified to be added to the token. For example, the difference to the previous authorization, The relationship or a subset of permissions.

3 now shows a system and a method according to the present invention. This system also provides protection against unauthorized modification (integrity assurance).

For this the service provider gets a key pair from public Key "pub" and private key "priv" of a key pair for the asymmetric encryption. When passing on the token he has generated to the first trust carrier Added a secret to the service provider's token. This Secret as well as the initial permission perm = 10 will be public key encrypted by the service provider and subsequently the permission perm = 10 and the public key pub added to the token. The token contains So initially the public key pub, the permission perm = 10 in plain text, the secret secret the service provider in encrypted Form as well as the permission perm = 10 in encrypted form. The encryption takes place in both cases with the public Key, advantageously such that the secret secret as well as the authorization perm = 10 encrypted together and thereby the encryption result of the service secret of the whole to be encrypted Information depends.

For integrity assurance The right modifications are made every time you add rights trust carrier the previously encrypted Part of the token along with a description of the restricted rights again with the public key of the service provider (which accompanies the token) is encrypted. there a method is applied in which the encryption result of the service secret depends on all information to be protected. Now can the service provider by decrypting the token only to the original Secret, even if all changes have been correctly decrypted are. A manipulation of the token is thus excluded. So would e.g. a separation of the encrypted rights restriction cause that the whole token is no longer decryptable.

In 3 this process is exemplified. The service provider issues a token with an initial scope of rights to the trusted entity at the bottom right. This thus contains the secret secret and the initial permission perm = 10 in encrypted (= hatched) form. In addition, it still contains the rights in unencrypted form and the public key pub. This trust now generates a token with restricted rights perm = 5 and passes it on to the bearer on the bottom left. The encrypted part of the token is now extended by the restricted rights, recognizable by the hatched "perm = 5", and the current rights are also contained unencrypted in the token.Then a final restriction to the right level "3", which also applies the encrypted part of the token was added and saved in plain text.

4 explains the process of encryption. It shows the token, on which a total of three encryption operations have taken place: the first initial encryption of secret and original rights (1), then the restriction of the authorization to the value "5" (2nd encryption) and the last restriction to the value " 3 "(3rd encryption).

The Secret secret and the permission perm = 10 are thus in total three times with the public key encrypted pub, the authorization perm = 5 only twice with the public key pub encoded and the permission perm = 3 only once with the public key pub encrypted.

The service provider can now check the user-redeemed token for legality. For decryption, first the encryption no. 3 is undone, then no. 2, and at the end the initial encryption of the secret. If the secret can be reconstructed through these steps, this is proof that the token is complete and has not been manipulated. After decrypting a token, the service provider has all the restrictions made and can now check for legitimacy. If he detects a violation of the rules (eg unauthorized extension of the rights), the token is invalid and a corresponding error message appears generated.

Encrypting all encrypted public-key information with every passing-on and token-to-trust modification requires a lot of computing and memory overhead. This computing and memory overhead can be significantly reduced by the in 5 illustrated variant of the inventions to the invention process.

at This procedure is not always the entire information with the public Key pub re-encrypted, if the trusted the Token changed and pass on. Rather, the trust carrier generates for one issued to him and pass on token a new symmetrical Key, the for the first trust carrier with "A" and for the second Trust carrier with "B" is designated. Now is not the inserted security information perm = 5 or perm = 3 with the public key encrypted but with the symmetric key A or B of the trust carrier. This will then be followed with the public key encrypted possibly together with the complete, already encrypted part of the token.

6 shows the structure of a token as seen by the second trust in 5 is produced. In this case, the symmetric key B is encrypted only with the public key.

The one with the curly brace " 1 "designated secret of the trust source (" secret ") and the trust information" perm = 10 "are encrypted with the public key, then encrypted together with the trust information" perm = 5 "with the symmetric key A (see parenthesis" 2 The symmetric key A is encrypted first with the public key and then together with the key A encrypted elements again with the key B.

takes assume that the authorization information is greater than the key length of a symmetric key, This results in a gain in performance for the encryption and the decryption.

A similar gain in encryption or decryption performance results from only selective encryption. This is in 7 illustrated by an example. It is with the brace and the reference numeral " 1 The part of the token which is originally encrypted by the source of trust with the public key is represented by block separation of the encryption results, the secret secret and the authorization perm = 10 by the first trusted carrier when passing on and adding the permission perm = 5 to encrypt the secret secret and the permission perm = 5 once more or for the first time with the symmetric key A. In the same way it is then possible for the further trust carrier to obtain the secret secret with the permission perm = 3 added by means of the symmetric key B to encrypt (reference numeral " 3 In this case too, the symmetric keys A and B are encrypted with the public key added to the token 7 In the variant selected, the unencrypted permission perm = 10 is first given by the unencrypted permission perm = 5 and then by the unencrypted permission perm = 3, as in 7 shown in this state, replaced. The recipient of the token thus has access to both the public key pub and knowledge about the permission perm = 3 granted to him. However, he is not aware of the permissions that the previous owners of the token had. Since the protection of a token is based on the fact that the secret of the source of trust can only be extracted if all the information of the token is present in an unchanged manner, this optimized method illustrated here also fulfills the desired protection goal.

A another variant of the present method and of the present System according to the invention it is a hash value from the authorization information added by a trusted bearer and only this instead of the complete authorization information Encrypted with the secret of the trust source Add tokens. This makes it possible the history of rights restriction to make the token accessible. This variant offers the same Safety as the addition the encrypted Authorization information itself because the token is not recognized as valid if any information protected by this method changed becomes. Since the hash value is significantly shorter than the authorization information belonging to it, is the encryption and decryption effort also reduced. This variant can therefore be similar to the use of private keys, as shown above, used for performance optimization because the space requirement of a hash value is of the same order of magnitude like the one for private key lies.

However, in order to enable a subsequent tracking of the chain of trust, it is now necessary for every trusted person who passes on a token to insert an encrypted secret into the token which is known only to him and via which he can assign a token to a recipient of the token.

This is in 8th represented here, where here A and B do not represent symmetrical keys, but secrets of the first trust carrier (A) and the second trust agent (B). These secrets are in 8th together with the authorization added by the trusted entity as well as the previously encrypted part of the token again encrypted with the public key pub.

These secrets represent unique identification information that allows the allocation of tokens and receiving trusted bearers in the passing trust. This allows the consensus-based identification, ie the subsequent tracking of the chain of trust, since the storage of the secrets the entire chain of trust is stored in the token. In this case, however, one relies in each case on the disclosure of the associated recipient by the relaying trust carrier, since only the relaying trusted entity can assign the trust information decrypted by the source of trust to the respective recipient. The trusted entity can then pass that information to whom the token was passed on to the trusted carrier in front of it in the chain of trust or trust. The source of trust itself can not do anything with the information in the token alone, since the secrets in the token become meaningful only through additional information stored in the trust carriers. It is advantageous here, however, that these data do not occur centrally on a server and therefore the possibility of a central data misuse is excluded. The in the 5 to 7 illustrated variants of the present invention using private keys A and B provides a closer look at a special case in 8th illustrated variant using secret A and B, since the in the 5 to 7 used symmetric keys A and B examples of secrets A and B according to the 8th are.

Last shows 9 an example in which a subsequent legal modification is possible. In this example, a Permission Update List (PUL) is provided, into which each participant in the network, ie each trust source and each trust bearer, can make entries. This provides a central instance for storing security settings for a service. The PUL contains information regarding modification of privileges that are to be valid in addition to or substitute for specific permissions that have been or will be inserted into the token. The priority of the authorization entries in the token or in the PUL is then taken into account in each case by the service provider in accordance with a predetermined priority.

In 9 If the trustor subsequently concludes that the entitlement "3" would be more appropriate, he can deposit this information in the PUL.

With This mechanism may therefore be e.g. a given token is subsequently invalidated, by depositing a token in the PUL without any permissions becomes. On the other hand, so but also later Permissions are extended when a token with higher privileges is deposited becomes.

The Association between the current entry in the token and the entry in the PUL, in the present example, the symmetric key ("A") is used as identification information, which is a secret that only the exhibitor of the respective Tokens and the service is known. The user, however, is this ID only in unreadable, encrypted Form before.

A other view of the PUL is that it represents an ACL service, at which authorized user store security settings can. The deposited information is however with a certain trust token associated and can only be used with this, which makes a difference to conventional ACL-based access method represents the classical method that you can drop permissions on the object without issuing a token, is not applicable here, since in this case no association between the token to be redeemed and the deposited PUL entry can be made.

The So PUL provides a central instance for storing security settings for a service dar. When reviewing a Tokens, especially when extracted from this a modification is checked, so in the PUL, whether for a modification deposited was, for example, with a later timestamp. If so, so can depend on from the priority these are used instead of the right just extracted from the token.

In summary, in contrast to conventional methods, the proposed method and the proposed system offer the following advantages:
The process is not based on a public-key infrastructure, thereby avoiding centralized data collections, including their abuses opportunities.

The System guaranteed the anonymity of User within the system.

The Token and thus the permissions or trust information given by them variable or restrictable.

Farther Is it possible, later consensus-based a particular trust in the chain of owners to determine a token.

The following is a concrete example of the passing on of security tokens. It shows a procedure as it is in 8th shown and described.

One Service Provider (Service Provider) would like a token for the offered Create a service. It creates a public / private key pair ("Pub", "priv"). Further generated he uses a random number as secret for the service ("secret").

Now the service selects the set of permissions that can be passed on and selects a method for their encoding, for example the encoding in an XML file. For example, the authorization could be the quantity of devices for which the token is to be valid, as well as the time of day of validity and the expiration date of the token. The devices could be encoded as a binary string, where each bin corresponds to a device. Thus, for two devices, the right encoding "11" would mean permission for both devices, "10" for the first, but not for the second, "01" for the second, but not for the first, and "00" for neither device , For example, a possible right-token encoding of a token would be "11/09: 00-17: 00 / 31.12.2004," meaning that this token is valid for all (two) available devices, daily from 9: 00-17: 00, and expires on December 31, 2004. This encoding of rights is generally abbreviated as "perm." In order to establish the initial token, the service provider concatenates the original (maximum) rights "perm1" with the secret service and encrypts this data with the public key "pub." The result of the encryption consists of the encrypted portion of the privilege ("crypt1 ") and the encrypted service secret (" secret1 "), whose encryption by the previous concatenation depends on the encryption of the rights.The initial token now looks like this:
pub / perm1 / crypt1 / secret1

The Order of the fields and the problem of field separation is for the general procedure is irrelevant and therefore does not in this example considered. This token is now sent to the first authorized user output, e.g. the system administrator of the service.

This now wants to derive from a limited security token and pass. He creates a restricted variant "perm2" from the permissions "perm1". Furthermore, it generates a random number "A", which is stored internally together with the information to whom this token was given, and concatenates the new permissions "perm2", the random number "A" and the already encrypted service secret "secret1" and Encrypts both with pub, with the result "crypt2" and "secret2". The new token looks like this:
pub / PERM2 / crypt2 / crypt1 / secret2

This can be continued as desired. Thus, a modified token would look like this, with crypt3 / secret3 encoding the concatenation of perm3, B, and secret2:
pub / PERM3 / crypt3 / crypt2 / crypt1 / secret3

• • zu prüfen, dass bei der Weitergabe die Rechte nie unrechtmäßig erweitert worden sind,
• • zu verifizieren, dass das Token von ihm stammt, und
• • die anonymisierte Weitergabehistorie des Sicherheitstoken zu extrahieren, um die nachträgliche konsensbasierte Identifikation zu ermöglichen.

This will now be redeemed as an example at the service provider. Its task now is to

• • to verify that the rights were never unlawfully extended in the transfer,
• • verify that the token is from him, and
• • Extract the anonymized propagation history of the security token to allow for subsequent consensus-based identification.

To For this purpose, he has to token in three rounds with only himself decrypt the known private key "priv" First, "crypt3" and "sccret3" are concatenated and decoded together. As a result receives he "perm3", "B" and "secret2" The received "perm3" will now be with the compared to "perm3" passed in the token; it does not match the token is invalid.

In the second round will be "crypt2" from the token with "secret2" (from the last one) Round) decoded together, which yields "perm2", "A" and "secret1" as a result checked whether "perm3" has a constraint (or equivalence) of "perm2" is not the case, i. if "perm3" is an invalid extension representing the rights to "perm2" is that Token invalid.

In the third and last round will be "crypt1" from the token together with "secret1" (from the last one) Round) decrypted, which gives "perm1" and "secret". Again must checked if "perm2" from the last Round one inadmissible Extension opposite the now obtained "perm1" represents what the Token invalid would do.

are all these steps are satisfactory, can be excluded that rights have been improperly extended on this token. Last still has to be tested whether the received "secret" with the in the service stored "secret" matches only if this If this is the case, this token is a token issued by this service and never in integrity been violated, and the service can now authorized with this token Provide service. The obtained anonymized forwarding identifiers "A" and "B" can be used in case of abuse, the passing on history of the Tokens later determine: For this purpose, the authority appointed for the investigation occurs to the first token receiver and to whom he passed the token with the identification "A". The first token receiver can now the token receiver using its own stored data and this information either issue to the investigating entity or the responsibility for the abuse to take on.

Repeated Applied, this way can complete the transfer history of the token and consensus of all involved the author of the abuse.

Claims (101)

A method for awarding, passing on and / or using digital trust information in a network with at least one participant as trusted source that generates trust information, and at least one other participant as trusting entity who obtains trust information and, if appropriate, forwards and / or uses, characterized in that the at least one source of trust issues at least one token containing at least one trust information in unencrypted form, and only information known as the trust source in encrypted form, the token and a public key of the trust source of an asymmetric encryption key pair to a first trusted bearer and, if appropriate, subsequently passed on to further trusted parties, and one of the trusted bearers as a user gives the token to the source of trust in order to use the trust information. Method according to the preceding claim, characterized Characterized that the secret with any key, one Key for the symmetrical encryption a key a key pair for the asymmetric encryption or public key encrypted the source of trust becomes. Method according to one of the preceding claims, characterized in that the token further contains the at least one confidence information or a hash value thereof in public key encrypted Contains form. Method according to one of the preceding claims, characterized characterized in that the token and the public key are separated be passed on. Method according to one of claims 1, 2 or 3, characterized that the token is public key contains. Method according to one of the preceding claims, characterized marked that the trust information and the secret the source of trust are encrypted so that the encryption result from the whole to be encrypted Information depends Method according to the preceding claim, characterized marked with the public key the trust information and the secret of the source of trust encrypted together become. Method according to one of the two preceding claims, characterized marked that the encryption the trust information and the secret of the source of trust with block separation of the encryption result the confidence information and the encryption result of the secret the source of trust. Method according to one of the preceding claims, characterized marked that the public key and the token or a copy of the token as a token from a trusted bearer to a another trust carrier be passed on. Method according to the preceding claim, characterized characterized in that the at least one token before and / or at Disclosure between two trusted entities with a confidence change information to change the content of the existing in the token trust information provided becomes. Method according to the preceding claim, characterized in that the confidence change information contains new or changed trust information, information about the change of the previous trust information, for example a difference or a relationship to ago is trust information, information for maintaining or restricting permissions or the like. Method according to one of the two preceding claims, characterized characterized in that the confidence change information is dependent on the trust between the communicating participant and the recipient Participant is determined. Method according to one of claims 10 to 12, characterized that the at least one token before and / or when passing between two trusted with the confidence change information in unencrypted Form and with a derived from the confidence change information Information in encrypted Form is provided. Method according to the preceding claim, characterized characterized in that the information derived from the change of confidence the confidence change information itself or a hash code of the trust change information. Method according to one of the two preceding claims, characterized characterized in that derived from the confidence change information Information at least with the already encrypted secret of the source of trust or with the already encrypted Part of the token of the trust source is encrypted in such a way that the encryption result from the whole to be encrypted Information depends. Method according to the preceding claim, characterized characterized in that derived from the confidence change information Information at least with the already encrypted secret of the source of trust or with the already encrypted Part of the token is encrypted together become. Method according to one of the two preceding claims, characterized marked that the encryption the one from the trust change information derived information at least with the already encrypted Secret of the trust source or with the already encrypted part of the token with block separation of the encryption result of the confidence change information derived information and the encryption result of the already encrypted Secret of trust source or already encrypted Part of the token takes place. Method according to one of claims 13 to 17, characterized that the encryption before or when passing the token with the public key. Method according to one of claims 13 to 17, characterized that the encryption before or when passing the token with a key for a symmetric encryption method which is known only to the disclosing agent of trust is, and the contents of the token around the symmetric key, the with the public key encoded was expanded. Method according to one of the preceding claims, characterized characterized in that the forwarding trust bearer Passing the token the contents of the token to only known to him information expanded as a secret, the secret is encrypted. Method according to the preceding claim, characterized characterized in that the secret of the relaying trust with the public key encoded is. Method according to claim 20, characterized in that that the secret of the relaying trust with a symmetric key the relaying trust is encrypted and the contents of the token around the symmetric key, the was encrypted with the public key, is extended. Method according to one of the two preceding claims, characterized characterized in that the secret of the relaying trust and the already encrypted Secret of the source of trust or the already encrypted part of the token with the same key encoded becomes. Method according to the preceding claim, characterized characterized in that the secret of the relaying trust, the passes the token so encrypted that the encryption result from the encryption result simultaneous encryption the already encrypted Secret of trust source or already encrypted part depends on the token. Method according to the preceding claim, characterized characterized in that the secret of the relaying trust and the encrypted Secret of the source of trust or the encrypted part of the token or encrypted together with his copy become. Method according to the preceding claim, characterized in that the encryption of the secret of the pass the trusted entity and the encrypted secret of the trust source or the encrypted part of the token with block separation of the encryption result of the secret of the relaying trusted carrier and the encryption result of the re-encrypted secret of the trust source or the re-encrypted part of the token. Method according to one of claims 20 to 26, characterized that the secret of a trust carrier is an identification information assignable to the token, one for re-encryption of the encrypted Secret of the token or its copy used symmetric key and / or the hash code of the trusted party prior to passing the token added to the contents of the token Confidence change information is. Method according to one of Claims 9 to 27, characterized that a trust, which forwards a token to another trust, information about the Tokens and the Trust stores. Method according to the preceding claim, characterized characterized in that the information about the token that from the relaying trusted the Tokens added Secret is. Method according to one of the two preceding claims, characterized characterized in that for tracking the relay chain of a Token an affiliate re of a passed token with the trusted party that passed on the token, requesting transfer information whether and, if applicable, to whom it has passed the token. Method according to the preceding claim, characterized characterized in that on request a trust carrier information, if and to whom he passed the token and / or himself a further participant received forwarding information to a requesting participant or the trusted entity or source of trust, from whom he received the token. Method according to one of claims 13 to 31, characterized that with every change the content of the token by a trusted carrier the re-encrypted secret the source of trust, re-encrypted secrets of a trust, again encrypted symmetric key of trust carriers or the entire re-encrypted Part of the token is added to the token or its equivalent previous encrypted Replace parts of the token. Method according to one of the preceding claims, characterized characterized in that the trust source after receiving a token from a trusted entity all performed on the contents of the token encryptions reverses and the match the decrypted secret the source of trust with the original source of trust only known secret checks. Method according to the preceding claim, characterized characterized in that the source of trust is the exercise of Right by the user in accordance with the trust information contained in the token, most recently added to the token or trust change information allows, if the decrypted Secret with the original encrypted by the source of trust Secret coincides. Method according to one of the two preceding claims, characterized characterized in that the source of trust is the exercise of Rights in accordance with the trust information contained in the token through the User does not allow and / or optionally generates an error message if the decrypted secret with the original encrypted by the source of trust Secret does not match. Method according to one of Claims 33 to 35, characterized that checks the source of trust, whether the trust information contained in the token is unauthorized and / or unjustifiably changed by a participant, For example, a privilege has been extended, and optionally the exercise of rights in accordance with the trust information contained in the token through the User does not allow and / or optionally generates an error message. Method according to one of the three preceding claims, characterized indicates that the trust source checks for a token in a database Trust information or trust change information is stored are, and the source of trust depending on a predetermined priority the exercise of rights by the user in accordance with in the Token contained in the database or the information contained in the database contained confidence information. Method according to the preceding claim, characterized characterized in that the confidence information contained in the database Has priority. Method according to one of the two preceding claims, characterized characterized in that the trust information has priority, the exercise of the user lesser rights. Method according to one of the three preceding claims, characterized characterized in that the trust information has priority, which generates later has been. Method according to one of claims 32 to 40, characterized that by any source of trust and trust in relation to a token passed through it, trust information can be stored in the database. Method according to one of Claims 32 to 41, characterized that the trust information stored in the database with an identifier information is stored, each a token is clearly assignable. Method according to the preceding claim, characterized in that the tag information uniquely assignable to the token is just encrypted in the token is present. Method according to one of Claims 32 to 43, characterized the tag information uniquely assignable to the token is the The secret is that of the trust information in the database saving participant before or when passing the token in the Token inserted becomes or became. Method according to one of the preceding claims, characterized characterized in that a subscriber has a stored at or by him Protects tokens against unauthorized copying. Method according to the preceding claim, characterized characterized in that the subscriber has a stored at or by him Tokens encrypted and / or password protected stores. Method according to one of the two preceding claims, characterized characterized in that the subscriber in the token information insert that prohibited the copying of the token. Network system with at least one participant as Source of trust, by which trust information can be generated, and at least one other participant as a trusted person for whom one Trust information can be received and forwarded if necessary and / or usable, characterized, that by the at least one trust source can be issued at least one token is, at least, a trust information in unencrypted form and an information known only to the source of trust as Secret only in encrypted Contains form, of the Token and a public one key the source of trust of a key pair for the asymmetric encryption to a first trust carrier and optionally subsequently to other stakeholders can be redistributed and by one of the trusted as Users of the tokens can be trusted to obtain the trust information to use. Network system according to the preceding claim, characterized in that the secret with any Key, a key for the symmetric encryption, a key a key pair for the asymmetric encryption or the public key of the Trust source encrypted is. Network system according to one of the two previous ones Claims, characterized in that the token further comprises the at least one Trust information or a hash value thereof in public key encrypted Contains form. Network system according to one of the previous three Claims, characterized in that the token and the public key are separated can be passed on. A network system according to any of claims 48 or 50, characterized in that the token contains the public key. Network system according to one of the preceding claims, characterized marked that the trust information and the secret the source of trust are so encrypted that the encryption result from the whole to be encrypted Information depends Network system according to the preceding claim, characterized in that with the public key the Trust information and the secret of the source of trust together with the public key encoded are. Network system according to one of the two previous ones Claims, characterized in that the trust information and the secret of the Trust source with block separation of the encryption result of the trust information and the encryption result the secret of the source of trust are encrypted. Network system according to one of claims 48 to 55, characterized in that the public key and the token or a copy of the token as a token from one trusted bearer to another trust carrier can be passed on. Network system according to the preceding claim, characterized in that the at least one token before and / or when passing between two trusted entities with a confidence change information to change the content of the existing in the token trust information provided is. Network system according to the preceding claim, characterized in that the confidence change information is a new one or changed Trust information, information about the change of the previous trust information, for example a difference or ratio to the previous trust information, information to retain or restriction of permissions or the like. Network system according to one of the two previous ones Claims, characterized in that the confidence change information in dependence of the trust between the disclosing participant and the recipient is determinable. Network system according to one of claims 57 to 59, characterized in that the at least one token before and / or when passing between two trusted entities with the trust change information in unencrypted Form and with a derived from the confidence change information Information in encrypted Form is provided. Network system according to the preceding claim, characterized in that the from the change of confidence derived information the confidence change information itself or a hash code of the trust change information is. Network system according to one of the two previous ones Claims, characterized in that derived from the confidence change information Information at least with the already encrypted secret of the source of trust or with the already encrypted Part of the token of the trust source is so encrypted, that the encryption result from the whole to be encrypted Information depends. Network system according to the preceding claim, characterized in that the from the Ver trust change information derived information at least with the already encrypted secret the source of trust or the already encrypted one Part of the token is encrypted together are. Network system according to one of the two previous ones Claims, characterized in that derived from the confidence change information Information at least with the already encrypted secret of the source of trust or with the already encrypted Part of the token with block separation of the encryption result of the confidence change information derived information and the encryption result of the already encrypted Secret of trust source or already encrypted part encrypted the token are. Network system according to one of claims 60 to 64, characterized in that the encryption before or on passing of the token with the public Key, contained in the token is feasible. Network system according to one of claims 60 to 64, characterized in that the encryption before or on passing of the token with a key for a symmetric encryption network system carried out is known only to the passing on of trust is, and the contents of the token around the symmetric key, the with the public key encoded was, is extended. Network system according to one of claims 48 to 66, characterized in that by the relaying trust carrier before Passing the token, the contents of the token by information known only to him is extended as a secret, the secret is encrypted. Network system according to the preceding claim, characterized in that the secret of the relaying trust with the public key encoded is. Network system according to Claim 67, characterized that the secret of the relaying trust with a symmetric key encrypted by the disclosing trust and the contents of the token around the symmetric key, the was encrypted with the public key, is extended. Network system according to one of the two previous ones Claims, characterized in that the secret of the passing trust carrier and the already encrypted Secret of the source of trust or the already encrypted part of the token with the same key encoded are. Network system according to the preceding claim, Characterized in that the secret of the relaying trust, the Pass on token, so encrypted is that the encryption result from the encryption result simultaneous encryption the already encrypted Secret of the source of trust or already encrypted Part of the token depends. Network system according to the preceding claim, characterized in that the secret of the relaying trust and the encrypted Secret of the source of trust or the encrypted part of the token or encrypted together with his copy are. Network system according to the preceding claim, characterized in that the secret of the passing Trust carrier and the encrypted Secret of the source of trust or the encrypted part of the token with block separation the encryption result of the Secret of the passing trust and the encryption result the re-encrypted Secret of trust source or re-encrypted Part of the token encrypted are. Network system according to one of claims 67 to 73, characterized in that the secret of a trust carrier a the token assignable identification information, one for re encoding of the encrypted Secret of the token or its copy used symmetrical key and / or the hash code of the trusted party prior to passing the token Content of the token added Confidence change information is. Network system according to one of claims 56 to 74, characterized in that by a trust carrier, the passing on a token to another trust, information about the token and the trust carrier are storable. Network system according to the preceding claim, characterized in that the information about the token that of the passing trust carrier added to the token Secret is. Network system according to one of the two previous ones Claims, characterized in that for tracking the relaying chain a token from a participant regarding a passed on Tokens at the trust that passed the token distribution information is available, if and where appropriate to whom he passed the token. Network system according to the preceding claim, characterized in that on request by a trusted carrier information, if and to whom he passed the token and / or himself a further participant received forwarding information to a requesting participant or the trusted entity or source of trust, from whom he received the token can be passed on. Network system according to one of claims 60 to 78, characterized in that with each change of the contents of the token by a trusted carrier the re-encrypted Secret of the source of trust, once again encrypted secrets of a trusted entity encrypted symmetric key of trust carriers or the whole encrypted again Part of the token added to the token are or through this the corresponding previous encrypted Parts of the token are replaceable. Network system according to one of claims 48 to 78, characterized in that by the trust source after Receive a token from a trusted bearer all in the contents of the token conducted encryptions reversible feasible are and the match of the decrypted Secret of the source of trust with the original, only the source of trust known secret testable is. Network system according to the preceding claim, characterized in that by the source of trust the exercise of Right by the user in accordance with the trust information contained in the token, most recently added to the token or trust change information zulaßbar is when the decrypted Secret with the original encrypted by the source of trust Secret coincides. Network system according to one of the two previous ones Claims, characterized in that by the source of trust the exercise of rights in accordance with the trust information contained in the token through the User not allowed and optionally an error message can be generated if the decrypted secret with the original encrypted by the source of trust Secret does not match. Network system according to one of claims 80 to 82, characterized in that it can be checked by the source of trust whether the trust information contained in the token has been changed unauthorized and / or in an unauthorized manner by a subscriber, for example, an authorization has been extended, and optionally the exercise of rights in accordance with the confidence information contained in the token by the user is not allowable and / or optionally an error message can be generated. Network system according to one of claims 80 to 83, characterized in that it is testable by the source of trust, whether in a database for the token trust information or trust change information are stored, and by the source of trust in dependence from a predetermined priority the exercise of rights by the user in accordance with in the Token contained in the database or the information contained in the database contained trust information is admissible. Network system according to the preceding claim, characterized in that the confidence information contained in the database Has priority. Network system according to one of the two previous ones Claims, characterized in that the confidence information takes precedence that has the user exercising lesser rights. Network system according to one of the previous three Claims, characterized in that the one trusted information priority has that later was generated. Network system according to one of Claims 79 to 87, characterized in that by each trust source and every trust carrier with respect to a token passed through it, trust information can be stored in the database. Network system according to one of Claims 79 to 87, characterized in that the stored in the database Trust information is stored with identification information, each unique to a token is assignable. Network system according to the preceding claim, characterized in that the token clearly assignable Identification information in the token is only encrypted. Network system according to one of Claims 79 to 90, characterized in that the token clearly assignable Identification information is the secret of which the trust information in the database storing participants before or on passing of the token inserted into the token becomes or became. Network system according to one of claims 48 to 91, characterized in that at or by a participant saved tokens is protected against unauthorized copying. Network system according to the preceding claim, characterized in that the at or by a participant stored tokens encrypted and / or password protected is stored. Network system according to one of the two previous ones Claims, characterized in that the token contains information that prohibited the copying of the token. Method or network system according to one of the preceding Claims, characterized in that a token is either an original of a token issued or changed later, or a token Copy of such a token is. Method or network system according to one of the preceding Claims, characterized in that the participants devices, services and / or users are. Method or network system after the preceding Claim, characterized in that the devices are computers, mobile phones or the like. Method or network system according to one of the preceding Claims, characterized in that the trusted sources are service providers or service providers and / or other subscribers. Method or network system according to one of the preceding Claims, characterized in that the at least one token as trust information Access rights of the user to devices and / or services of the source of trust or a participant, for which the trust source issues tokens (credentials) and / or Confidence values regarding the trust of the source of trust or a Participant, for which the trust source issues tokens, into a trust carrier that receives the token directly or indirectly from the source of trust (trust token) and / or evaluating acts of a trusted person who receives the token directly or indirectly from the source of trust (valuation token) contains. Method or network system according to one of Claims 95 to 98, characterized in that the services include an information offer, a resource access and / or an access to an In infrastructure such as building management systems. Method or network system according to one of the preceding Claims, characterized in that the at least one token further information, optionally as part of the trust information such as the context in which it was exhibited, date of issue, exhibition location, the context, for it was issued, validity period the information and / or information contained in the token for identifying and / or checking the content of the token.