DE102014114432A1 - A method, apparatus and computer program for controlling access to a service within a network - Google Patents

Abstract

Embodiments relate to a method for controlling access to a service (100) within a network, comprising receiving (110) a record (200) indicating authorization to access at least one service, and identifying an authorized user (100); 120) for which the record (200) was created. It is checked (130) whether the record (200) was received from the authorized user. Granting access to the service (140) occurs when the record has been received from the authorized user.

Description

Technical area

Embodiments of the present invention relate to a method of controlling access to a service within a network and to a method of accessing a service in a network.

background

Within a network of computers or digital devices, different services or functionalities are often used concurrently or concurrently by multiple users or clients. Examples of such services include access to memory, access to printers, access to an SMTP service, or the like. Examples of protocols used to access such services are Server Message Block (SMB) or Common Internet File System (CIFS). In order to be able to use a service offered by a host computer or in general by another identity in the network, it is usually necessary for the user to be authenticated to the provider of the service or to be authorized to use the service. A well-known possibility of authentication or proof of authorization is the input of a user name and a corresponding password, so that the provider of the service can check whether the entered password matches the password stored in the network for the password, then access to grant the offered service.

In order not to have to perform such time-consuming user authentication with every file access or every print job, single sign-on authentication methods (SSO) have become established, in which a user only has to go through the authentication mechanism once, whereas subsequent authentications to the services in the Network automatically, based on records that indicate a user's permission to access at least one service. In SSO procedures, a client or user first authenticates to an SSO authentication service, which is still referred to as SAS. The authentication with respect to the SAS can be carried out by various authentication methods, for example by the already mentioned combination of user name and password, by means of a smart card, or by other authentication methods. After a successful authentication (also referred to as SAS AuthN in the following), the client has an authentication token available for the services available on the network. This is also referred to below as a service authentication token (SAT). In general, a service authentication token may be referred to as a record indicating an authorization to access at least one service. The specific information contained in the record may differ. In some authentication methods, such as LAN Manager (LM) LM or NT LAN Manager (NTLM), the records contain a hash value or information derived from the hash value. The hash value is generated from a password entered during login or from random numbers.

Other techniques, such as Kerberos, may be based on a record whose contents are encrypted. In the case of Kerberos, for example, a ticket granting ticket (TGT) comprises a record used to obtain so-called service tickets for the benefit of a service on the network, such as a session key for encrypted communication with an authoritative server and the user ID of the same A user who has the authority to use services on the network. With Kerberos, the information within the record is further encrypted with the key of the authoritative server, the so-called Key Distribution Center (KDC).

Regardless of the specific nature of the information contained in the record indicating authorization to access at least one service, the client or user is in possession of a record or service authentication token after successful initial authentication (SAS AuthN), which provides access to the services available on the network. In the following sections, the data record is also synonymously called Service Authentication Token (SAT). In many single-sign-on methods, the data set or the SAT, ie the access to the service, is not secured. Therefore, if this record is stolen by a potential attacker, it may be used to unauthorized log on to services or their providing servers within the network by obtaining the rights of another actually authorized user by using the foreign record. Although the specific nature of a possible attack may differ for the particular protocols used, the privilege to use a service or service is usually based only on the generated record or the SAT so that a user can gain access to permissions by stealing it. who are not entitled to this.

Susceptibility to such attacks is independent of the security of the first Authentication method, as even after a particularly secure procedure for single sign-on a record is used to qualify for other services. For example, two-factor authentication, which requires username and password, for example, and the presence of an additional smart card to authenticate for the first time (to the SSO authentication service SAS), does not reduce this security risk. Thus, for example, a user who authenticates with valid user-defined user data during the initial authentication with respect to the SAS can then use services under another user identifier based on a foreign data record or gain access to services for which he has no authorization. The authentication data for the initial authentication and the subsequent authentication to services are independent of each other. Service authentication does not even require initial authentication if a user is already connected to the network. Thus, for example, an attack could first be done with stolen first authentication data, which generally provides access to the network. The subsequent services could then be used based on the records owned by another user to use the services with the permission of another user. In other words, the single sign-on can be performed with a different (stolen) identity, such as the use of the services following the single sign-on, which could be used with the authority of another (stolen) identity. Some computer operating systems that have been used for many years have known this type of attack, known inter alia as a "pass-the-hash" attack and as a "pass-the-ticket" attack.

There is thus a need to improve the control of access to a service within a network.

Summary

Embodiments of a method for controlling access to a service within a network by enabling, when receiving a record indicating a privilege to access at least one service, identifying the authorized user for whom the record was created are enabled. It is also checked whether the data record was received from the authorized user or if this was not the case. Access to the service is granted or permitted only if the record was received from the authorized user. This makes it possible to prevent unauthorized users, who have been unauthorized in the possession of the record, to use services in a foreign name, which in turn closes the vulnerability described above. Access to the service is prevented if the record was not received from the authorized user.

Users or clients within a network gain access to a service within the network by embodiments of the present invention by first communicating a record indicating authorization for an authorized user to access at least one service. In the case of authorized access, these users have themselves received the record on the first authentication. In the event of unauthorized access, these users have created the record themselves upon initial authentication. Furthermore, the users receive a request to create a response indicating the identity of the user and transmit the associated response indicating the identity of the user to gain access to the service upon a correctly answered prompt.

Brief Description

Embodiments are explained below with reference to the accompanying figures. Show it:

1 a flow chart of an embodiment of a method for controlling access to a service within a network;

2a an example of a record indicating an authorization to access at least one service;

2 B another example of a record indicating an authorization to access at least one service;

3 a flow chart of an embodiment for obtaining access to a service within a network;

4 a flowchart of an embodiment of a method for accessing a service in a network;

5 an example of a topology of a network, in which an embodiment according to 4 is implemented; and

6 a schematic representation of a device for controlling an access to a service.

description

Various embodiments will now be described in more detail with reference to the accompanying drawings, in which some embodiments are illustrated. In the figures, the thickness dimensions of lines, layers and / or regions may be exaggerated for the sake of clarity.

In the following description of the attached figures, which show only some exemplary embodiments, like reference characters may designate the same or similar components. Further, summary reference numerals may be used for components and objects that occur multiple times in one embodiment or in a drawing but are described together in terms of one or more features. Components or objects which are described by the same or by the same reference numerals may be the same, but possibly also different, in terms of individual, several or all features, for example their dimensions, unless otherwise explicitly or implicitly stated in the description.

Although embodiments may be modified and changed in various ways, exemplary embodiments are illustrated in the figures as examples and will be described in detail herein. It should be understood, however, that it is not intended to limit embodiments to the particular forms disclosed, but that embodiments are intended to cover all functional and / or structural modifications, equivalents and alternatives that are within the scope of the invention. Like reference numerals designate like or similar elements throughout the description of the figures.

Note that an element referred to as being "connected" or "coupled" to another element may be directly connected or coupled to the other element, or intervening elements may be present. Conversely, when an element is referred to as being "directly connected" or "directly coupled" to another element, there are no intervening elements. Other terms used to describe the relationship between elements should be interpreted in a similar manner (e.g., "between" versus "directly in between," "adjacent" versus "directly adjacent," etc.).

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the embodiments. As used herein, the singular forms "a," "a," "an," and "the" are also meant to include the plural forms unless the context clearly indicates otherwise. Furthermore, it should be understood that the terms such as e.g. "Including," "including," "having," and / or "having," as used herein, indicates the presence of said features, integers, steps, operations, elements, and / or components, but the presence or addition of a resp one or more features, integers, steps, operations, elements, components, and / or groups thereof.

Unless defined otherwise, all terms (including technical and scientific terms) used herein have the same meaning as commonly assigned to one of ordinary skill in the art to which the embodiments pertain. Further, it should be understood that terms, e.g. those that are defined in commonly used dictionaries are to be interpreted as having the meaning consistent with their meaning in the context of the relevant art, and not to be interpreted in an idealized or overly formal sense, unless this is so is explicitly defined.

1 FIG. 12 shows a flowchart of one embodiment of a method for controlling access to a service within a network. The method includes receiving 110 a record indicating permission to access at least one service. The method further includes identifying an authorized user 120 for which the record was created. During the review 130 , it is checked if the record has been received from the authorized user. Provide access to the service 140 occurs when the record has been received from the authorized user.

1 also shows an optional step of actively preventing access 150 to the service if the record was not received from the authorized user. According to further exemplary embodiments, this active step can also be omitted by completely omitting a response to the received data record to the sending user. Alternatively, as in 1 optionally, the access is actively prevented, for example, by actively terminating the user's data connection, for example by terminating a connection corresponding to a transport protocol by terminating an encrypted connection to the sending user of the data set, or the like.

According to some embodiments, in identifying an authorized user, information identifying the authorized user is extracted from the data set itself. The information, for example when using the NTLM Security Support Provider (NTLMSSP) or the Kerberos protocol, can consist of the user ID (user ID or UID) itself, which is stored, for example, within a TGT or an NTLMSSP data record. However, according to further embodiments, it does not have to be the user ID. Rather, any information can be used or extracted that allow a clear assignment to a specific user or client. In this case, the information which identifies the authorized user can also be obtained from parts of the data protocol with which the data record is sent, for example from header information of a transport protocol or the like. The information that identifies the authorized user can also be obtained from any other metadata, for example a session ID or an IP address. According to some embodiments, for the purpose of identifying the authorized user, the record is compared to a list of stored records that includes an association of the records originally created during the authentication with the authenticating users. For example, the received record could be bit-wise compared to the records of the list to identify, in a match, the user associated with the record in the list as the entitled user.

When extracting information that can be uniquely assigned to a user or a client, it can be checked whether the received record was actually received by the authorized user or possibly by another user. A user as used herein is not necessarily a natural person. Rather, the user is any identity that is able to use a particular service, such as another service. A user can thus correspond to a natural person, but also to other identities in the network, for example other computers or clients or machines, or even software modules that provide their own identity-defining functionality. Accordingly, a network is also to be understood as an aggregation of users who have the possibility of communicating with one another within the network. It is irrelevant how the communication is physically, this can be done, for example, corded or wireless, depending on the implementation also in parallel. The type of communication protocols used is arbitrary. Likewise, arbitrary protocols can be used at different levels of the protocol stack. The different identities or users or processes within a network can be assigned to different or even the same hardware or executed on the same hardware, including on the same processor. An example of a network is the entirety of the devices, services, and users that are communicating within a common domain. Likewise, a record may be any amount of information in any representation that allows a permission to access a service. A data record can thus have a very wide variety of logical contents, in different representations, for example as a binary code or as a hexadecimal code. A record may correspond to a data packet transmitted over the network, or even only part of such a data packet. Furthermore, the data record can also be transmitted by means of several data packets within the network. The record may have been created due to a successful previous authentication of a user. The record may be adapted to provide access to a service to a user without further user interaction.

In the exemplary embodiments described below, for the sake of simplicity, it is predominantly assumed that the user is a natural person, without thereby restricting the application of further exemplary embodiments of the invention to other identities.

In some embodiments, verifying that the record has been received from the authorized user includes transmitting a request to a sending user from which the record was received to confirm its identity. That is, after or before the authorized user for whom the record was created has been identified, the sending user from which the record was received is requested to confirm its identity by any mechanism, for example by performing a re-authentication , If the identity of the sending user and the identity of the authorized user match, it can be concluded that the record was received from the authorized user.

The implementation according to which the sending user confirms his identity can be chosen freely. For example, a challenge-response method can be used in which a task is submitted to and transmitted to the sending user whose solution is provided by one of the users within the network clearly identifiable or identifying information. The sending user solves the task and the solution of the task is received by the sending user. If the received solution matches or corresponds to a control solution determined using the information identifying the authorized user, it may be considered confirmed that the record has been received from the authorized user and thus provides access to the service is. An example of a task to be solved by the sending user would be, for example, the signing of a random number with the user ID of the sending user or another information uniquely identifying the sending user. If the same random number with the extracted user ID of the authorized user is verified or signed as the control solution and both solutions match, it is verified that the sending user is actually the authorized user of the data record. According to other embodiments, the information used by the sending user to solve the task may be different from the information extracted as the authorized user-identifying information. That is, the task can be solved, for example, by means of another feature, as the extracted feature from the data set, as long as the extracted feature and the feature used to solve the task are causally linked together or correlated such that by comparing the different solutions it can be concluded whether the sending user is the authorized user.

According to further embodiments, without further interaction with the sending user, further information identifying the sending user will be determined so that it can be confirmed that the record was received from the authorized user, if the information identifying the authorized user and the sending user User identifying additional information identifying the same user. For example, the further information identifying the sending user may be an IP address of the user, or a session number or session ID uniquely assigned to a user, the association between the further information, ie the IP or the session ID and the user identified thereby can be obtained from other services or identities in the network, for example from a DHCP server or a domain controller.

As already mentioned above, it must be in the information that is obtained or extracted by the received data record and the other information with which this information is compared, insofar as the two information are clearly correlated.

In accordance with some other embodiments, verifying the question of whether the record was received from the authorized user comprises creating an encrypted connection with the user from which the record was received. The information extracted from the record and identifying the authorized user is compared with another user identifying information which is used to establish the secure encrypted connection. Again, different types of information uniquely associated with the user may be compared, for example, a user-assigned hash value or key used to construct the encrypted connection, and a user ID associated with the user, which may be derived or extracted from the data set has been.

According to some embodiments, checking whether the record has been received from the authorized user is repeated at predetermined time intervals or randomly. The time intervals may or may not be the same length. This can prevent a verification-enabling component, for example a smart card within a card reader, from being removed in the meantime, so that it may no longer be possible to ensure that the user currently using the service is actually still the authorized user. In other words, the continuous presence of the actual calculated user can be checked.

According to some embodiments, access to the service upon successful verification is granted by transmitting to the sender of the record another record indicating to the authorized user to the service provider an authorization to access the service. That is, according to some embodiments, after successful authentication, the authorized user is sent another record that identifies this user as legitimate to the particular requested service.

According to some embodiments, the flow of data between the service and the user is controlled, i. the data will only be forwarded to the service if and as long as the sender of the record corresponds to the authorized user.

2a shows schematically and for better understanding an example of a possible content of a record 200 showing a permission to access at least one service. Presented is a content of a ticket granting ticket (TGT) that can be assigned to a user by a key distribution center of a Kerberos authentication system, and which subsequently can be used to request authorization tickets for further services at the key distribution center. As based on 2 shown includes the ticket granting ticket 210 at least the information about a session key 212 by means of which the user requesting the ticket can communicate encrypted with the Key Distribution Center (KDC). The TGT 210 also includes a user ID 214 , that is, a unique user ID, for the authorized user for whom the ticket was created. In the case of Kerberos, the information is further with the key 216 encrypted by the KDC. According to further embodiments, records can also be present and transmitted unencrypted, ie in plain text, and with other content. Based on the in 2a shown record 200 For example, while controlling access to a service, the user ID would be possible 214 to identify the authorized user for whom the record is 200 was created to extract directly from the record. As explained in detail above, however, there are any other ways to identify the authorized user, these may differ depending on the specific implementation.

2 B shows another example of a content of a record 220 that indicates a permission to access at least one service. The record 220 based on the NTLMSSP authentication protocol. The record contains the information about what kind of message it is in the field 232 , as information about the message type. Furthermore, in the data record shown by way of example, the user name 234 , the computer name 236 of the sending computer as well as the domain name 238 contain. In further data records, only an arbitrary part of this information may be included and the order of the information contained may be arbitrary. If the field 232 contains the value 3 as the message type encoding, is the message type "NTLMSSP_AUTH" used, among other things, to authenticate the sending user. Also at the in 2 B shown record 220 For example, if it were possible to control access to a service, it would be the username 234 to identify the authorized user for whom the record is 220 was created to extract directly from the record. As in the case of the example of 2a can contain messages according to the NTLMSSP protocol even more than the presented information.

For example, in other implementations, the record may include one or more hash values derived from a user password, for example, by known hashing algorithms, such as the MD4 or SHA-3 algorithm.

3 illustrates an embodiment of a method for obtaining access to a service 300 within a network for a user, that is, an embodiment performed on the user's side to gain access to the service.

The method comprises transmitting a data record 310 that indicates to an authorized user an authorization to access at least one service. Insofar as the embodiments of the invention are used to supplement existing solutions for access from services, it may also be the record used so far. This may allow embodiments of the invention to be used to cost-effectively and easily increase the security of existing networks in the form of a retrofit solution.

On submitting the record 310 out, will be in 320 receive a request to create a response indicating the identity of the user, ie the user or the sending user of the record is requested to verify his identity, for example by a signature.

Thereupon finds a transmission of the answer 330 instead, which indicates the identity of the user. That is, user-side, is about transmitting the record 310 in addition, receive a request to prove the identity and transmit a response that proves the identity. If the proof has indicated the identity of the authorized user, according to some embodiments, the further access to the service may be in accordance with already established mechanisms, which may efficiently enable the retrofitting of embodiments of the invention in existing large networks. 3 Figure 14 shows, assuming successful proof of the identity of the authorized user, the optional subsequent step of accessing the service 340 ,

1 schematically illustrates an embodiment of a method, how it could run on an authenticating entity, for example on a server, and 3 shows an embodiment of a method that could be user-side.

To better understand the interaction of the various components within of the network, shows 4 a flowchart of a method for accessing a service in a network from the beginning of the request by means of a record to the actual access to the service.

4 schematically illustrates also the respective executing entities or instances. A user 410 (Client) communicates with an authenticating entity or device to control access 412 (CAS) and this communicates with an authentication 414 (SRV AuthN) of a service 416 (Service). The CAS 412 performs the correlating, additional authentication (CAS AuthN) and is therefore the issuing authority, which performs the entire service authentication (SRV AuthN + CAS AuthN) and thus access to the service 416 controlled. A device for controlling access to a service is also referred to below as CAS.

The successful completion of the SAS AuthN, the result of which is the receipt of a record indicating an authorization to access at least one service, is assumed and is not shown in the following figure. In this case, the individual steps are assigned reference numerals.

420 : The client or the sending user 410 sends a request (AREQ) to access a service (this may be, for example, the initial message of SRV AuthN). That is, a record indicating a permission is sent to the service 416 access.

422 : As soon as the request 420 from the CAS 412 is received, the UID is determined, for example, from the SAT, extracted from the AREQ, looked up by the IP, or otherwise. That is, it identifies an authorized user for whom the record was created. The result is, for example, the UID.

424 : The CAS 412 generates a so-called challenge, eg a random number.

426 : The CAS 412 Represents the sending user 410 the task of proving possession of the additional authentication data and sends the challenge to the user.

428 : The user solves the task by proving the possession of the authentication data as well as the receipt of the current challenge (eg by signing the random number with the help of a smartcard). The result is the solved task.

430 : The user sends the solved task to the CAS 412 ,

432 : The CAS 412 verifies the answer using the correlated verification data associated with the UID. In this case, the verification data can also correspond to the authentication data that was used in the step 428 were used to solve the challenge. The CAS 412 has the user 410 thus successfully authenticated (CAS AuthN).

Through the steps 424 to 432 is checked ( 440 ), whether the record was received from the authorized user.

The CAS 412 allows access to the service via authentication 414 (SRV AuthN) only if the CAS AuthN has also been successfully completed, that is, if it has been verified that the data record was received from the authorized user.

Granting access to the service 450 or the first authentication at the service 450 includes in the embodiment of 4 a forwarding 452 the request to the authentication 414 the service 416 , This conventional SRV AuthN may be before, after or parallel to the steps 422 to 432 be dealt with unchanged.

454 : The (positive) result of the SRV AuthN can be retrieved at any time from the CAS 412 must be received and buffered and must be present positively before the user 410 actually in step 474 Access gained, so if this can communicate with the service or if its requests the service 416 reachable.

456 : The response of SRV AuthN will be forwarded to the user. This can be done at any time, but preferably after the result of the CAS AuthN is present, that is, if it was checked whether the record at 420 was received from the authorized user. If this fails, the access can already be denied here in the preferred case.

If successful, the service is accessed by the user 470 , The user 410 sends the actual service and data request (REQ) 472 , The CAS 412 leaves these requests only for service 474 , even if the CAS AuthN is completed positively. After the authentication process has been successfully completed by SRV and CAS AuthN, access to the service is thus possible.

The service 416 Edits the request 474 As usual, an appropriate response is generated. and to the CAS 412 forwarded. The CAS 412 Forwards the answer to the client and the service is established. The access 470 on the service 416 by the user can be done as in conventional implementations.

Although not described in the preceding embodiments, other embodiments may include additional safeguards to further enhance security.

According to some other embodiments, the server side CAS is also 412 the user 410 or the client verifiably identifiable, for example by means of a suitable certificate. This can already be done before step 420 be checked. In other words, further embodiments include confirming an identity of a recipient of the record, here the CAS 412 , to the sending user 412 ,

In order to ensure data integrity during and after the CAS AuthN, integrity protection of the transmitted data is implemented according to some embodiments, for example by means of the Keyed Hash Message Authentication Code (HMAC) or by means of the Cipher-based Message Authentication Code (CMAC). This prevents manipulation of data even after logging in through man-in-the-middle attacks. In other words, according to some embodiments, at least one integrity of the received data set is checked. It is thereby determined whether the received record is en route from the sending user 410 to the authenticating entity or to the CAS 412 was changed. According to further embodiments, the integrity of each exchanged message is checked.

In order to prevent reading of the messages, according to some embodiments, the entire data traffic of the access to the service is encrypted, for example by VPN, IPSEC or SSL / TLS.

If a session or access to a service takes longer, a new CAS AuthN can be requested periodically, for example to prevent a token, such as a smartcard, from being removed for authentication or removed after the last authentication , In other words, a continuous presence check is performed and the checking of whether the record has been received by the authorized user is repeated at predetermined time intervals.

According to some embodiments, instead of verifying a token by retesting, it is stored as a cryptographic secret on secure storage, such as a smart card. The check can then be carried out by an asymmetric method in which, for example, a signature proves possession of the token without an attacker being able to read it out.

For the functionality of the embodiments of the invention, the method of controlling access to the service on a particular or even dedicated network component is not required to occur. While there is a natural association on the part of the user, since its method steps are performed on the identity or on the user and his client who needs access to the service, the method for controlling the access results in a multitude of possibilities how and on which hardware components or entities in the network this can be done. For example, the method of controlling access as a security add-on may be implemented directly on the servers that also provide the service or service, for example, as an additional software or hardware module.

It is also possible to have a centralized solution, for example within a dedicated virtual machine, which could possibly simultaneously protect the providers of several services or multiple target servers. Alternatively, the method of controlling access could also be run as a suitable module or software component directly on a host of a virtualization solution.

As another possibility shows 5 by way of example, using a standalone network device or a stand-alone appliance that controls access to the services within the network. For example, multiple network segments can be physically separated and multiple servers can be protected simultaneously. Within the network, a print service is an example of different services 552 , a data service 554 and another service 556 represented, each of which different IP addresses are assigned. Embodiments of the invention include, as in 5 Also shown are devices for controlling access to a service 500 , The device 500 is used in the implementation in 5 also referred to as CAS. The device or CAS 500 can by the user 510 , which is exemplarily adopted as a network client or PC with the possibility of smart card authentication, can be uniquely identified. Furthermore, a secure communication channel or an encrypted connection 520 (for example, a VPN connection) between the user and the CAS gateway 500 established. At the in 5 shown embodiment is used for authentication in the construction of the secure channel or the encrypted connection 520 between the user 510 and the CAS 500 a user identifying identifying information, such as a unique key assigned to the user. This further information may be used in the method of controlling access to a service to compare it with an information extracted from the record identifying the authorized user as soon as the user 510 Access to a service within the network 550 wants to gain. In other words, at the in 5 shown embodiment, the authentication for the secure channel or the encrypted connection 520 used as authentication for the CAS gateway (CAS AuthN) and within the established secure channel or the encrypted connection 520 the SAS AuthN is executed, which is only successful if the authentication data of the SAS AuthN matches the authentication data for the secure channel (CAS AuthN).

An in 5 exemplified potential attacker 560 Can not fake messages and so-called man-in-the-middle attacks are excluded. In particular, according to the embodiments of the invention, it can not use stolen authentication data (records indicating an entitlement to access at least one service), since in this case it would not be in possession of the CAS AuthN data for the secure tunnel that is in it Case of further correspond to a user identifying information. Consequently, the potential attack can not be directly related to the services 552 . 554 and 556 within the CAS protected service network.

In other words, at the in 5 shown embodiment of the secure tunnel or the encrypted connection 520 first established before a request to access a service is sent. The subsequent correlation of the SRV AuthN can thus be realized on the basis of and within the safe tunnel. That is, the subsequent SRV AuthN using SAT is accepted only if the SAT or UID of the user also matches the identity used in establishing the secure channel. This is just one of a variety of possible implementation variants of embodiments of the present invention, in the present case one in which further user identifying information is determined in the form of CAS AuthN before the record indicating entitlement accesses at least one service , is received (SRV AuthN). As based on 5 As shown, an apparatus for controlling access to a service may be implemented within a network similar to a gateway.

The essential components for controlling access to a service within a network are 6 schematically illustrated by a block diagram again. A device for controlling access to a service 600 includes an input interface 610 adapted to receive a record indicating an authorization to access at least one service.

The record is from a sending user who sends it directly to the device either because of its internal configuration 600 or the data set is sent from an address assigned to a provider of a service to an address of the device on the basis of suitable routing mechanisms in the network 610 is redirected.

An information worker 620 is designed to identify an authorized user for whom the record was created. The information processor implements this 620 for example, one of the options described in the previous sections.

A verifier 640 is configured to check whether the record has been received by the authorized user and an output interface 650 is configured to grant access to the service when the record has been received by the authorized user. This can be done, for example, that in the device 600 during the check, cached requests to the service provider via the outbound interface 650 is not forwarded unless it is ensured that the record has been received by the authorized user.

A device for controlling access to a service 600 For example, it can be dedicated hardware or a computer equipped with the necessary interfaces. The device may also correspond to a single CPU within a multiprocessor system, or be implemented in the form of a system on a chip. Possible types of functionality providing devices, computers or hardware, which is used in whole or in part to provide the functionality.

In other words, embodiments of the invention may be summarized as follows. In order to close a weak point of the SSO procedures, namely the reuse of the (stolen) SAT on the network side (SAT Replay Protection), a further step will be integrated into the SSO procedure in order to be able to recheck the SAT of the user. To achieve that additional authentication method during the SRV AuthN can not be bypassed separately, this additional step is correlated with the identity of SRV AuthN. For this purpose, the identity and / or possibly other (additional) parameters, eg the available session identifier, can be extracted from an existing service or protocol or be looked up in a database (eg based on the IP). Based on such an assignment rule, the identity is selected and additional evidence is requested from the identified user. Only if this can answer the additional, correlated query, it is assumed that the SAT, which was used during the SRV AuthN, is trustworthy and not from an attacker who currently abuses it.

• • Vorkommen eines Einzigartigen Zuordnungsmerkmals (UID) gebunden an die SRV AuthN des Ursprungsdienstes (SAT oder Nutzername/ID)
• • Besitz von zusätzlichen Authentisierungsdaten neben dem SAT, unter anderem das einzigartige Zuordnungsmerkmal.

In order to make this possible, the following requirements arise on the user or client side, at least for some embodiments:

• • Occurrence of a Unique Assignment Characteristic (UID) linked to the SRV AuthN of the original service (SAT or username / ID)
• • Owning additional authentication data besides the SAT, including the unique mapping feature.

• • Möglichkeit die UID im Dienst oder in dessen SRV AuthN zu identifizieren.
• • Besitz von zusätzlichen Verifikationsdaten der Client-Seite.
• • Zusätzliche Authentisierungsverfahren und akkurate sowie eindeutige Zuordnung der zusätzlichen Verifikationsdaten zur UID und umgekehrt.

Basic server-side requirements for at least some embodiments are:

• • Possibility to identify the UID in the service or in its SRV AuthN.
• • Owning additional client-side verification data.
• • Additional authentication procedures and accurate and clear assignment of the additional verification data to the UID and vice versa.

This correlation or access-managing service is therefore referred to herein in part as Correlating Authentication Service (CAS). The CAS thus involves its additional authentication (CAS AuthN) based on the correlated UID of the service or the SRV AuthN. The CAS can also take over the control of service requests, e.g. block the service until all authentication is complete, which is similar to the way a firewall works.

An advantage of the embodiments of the invention with CAS access management and CAS AuthN is the ability to retrofit insecure authentication methods to the extent that an attacker who is not in possession of the CAS AuthN data is also unable to deal with stolen authentication data (SAT ) regarding the SRV AuthN. A particular advantage of this is that official users who are legally in possession of their CAS AuthN data, do not use any other stolen authentication data (SAT) for the SRV AuthN, and thus can not circumvent the SRV AuthN by pretending a different identity (Insider attacks). This is ensured by the embodiments of the invention and with the CAS access management and the correlation of the CAS AuthN to the SRV AuthN, so that these attacks can be prevented. It is advantageous here if the CAS AuthN can prove the presence of the user and thus the authenticity of the log-on data. Therefore, hardware tokens such as smart cards are particularly suitable. The loss of a hardware token is immediately noticeable, whereby a (further) password theft can happen unnoticed. Furthermore, hardware tokens such as smart cards are protected against copying.

Also, by correlating the CAS AuthN, the original SRV AuthN of the service need not be modified or exchanged, which brings a tremendous advantage over existing infrastructures since services can be maintained as usual.

An example of the use of the proposed solution would be single-sign-on methods in many operating system versions. A security gap of more than 15 years, called pass-the-hash, which remains open to attackers today, can be closed by the solution on the network side. In the case of the pass-the-hash attack, an attacker can re-import a stolen password hash (see SAT) into his client system, thus gaining unauthorized access to servers and services in the network (SRV AuthN). Hashes have the property that the original password can not be recalculated without great computational effort, but there is no problem in checking whether the input matches a known value. By conventional, additional authentication (eg password plus smart card), only a conditional security can be guaranteed here, since the additional methods, unlike the embodiments of the invention, do not correlate the identity of the SRV AuthN. The risk of internal attacks, eg by employees, is resolved by the presented solution, so that a false authentication through the pass-the-hash attack is no longer possible and this open security gap can be closed. Furthermore, the solution can also provide protection against so-called pass-the-ticket attacks, an advanced form of the Passthe hash attack, adapted to the Kerberos authentication process. Furthermore, embodiments of the invention also protect against theft of passwords. The embodiments of the invention have further diverse uses in the field of authentication to IT systems. The advantages in particular benefit network services which have gaps or even no authentication method (SRV AuthN) at all, but a UID. In other words, embodiments of the Invention also generally retrofit a missing SRV AuthN for services (CAS AuthN = SRV AuthN), provided that a valid UID is identifiable based on the service request.

The features disclosed in the foregoing description, the appended claims and the appended figures may be taken to be and effect both individually and in any combination for the realization of an embodiment in its various forms.

Although some aspects have been described in the context of a device, it will be understood that these aspects also constitute a description of the corresponding method, so that a block or a component of a device is also to be understood as a corresponding method step or as a feature of a method step. Similarly, aspects described in connection with or as a method step also represent a description of a corresponding block or detail or feature of a corresponding device. In particular, the device for controlling access to a service described herein may include all or any steps of the device method for controlling access to a service within a network as described herein.

Depending on particular implementation requirements, embodiments of the invention may be implemented in hardware or in software. The implementation may be performed using a digital storage medium, such as a floppy disk, a DVD, a Blu-Ray Disc, a CD, a ROM, a PROM, an EPROM, an EEPROM or FLASH memory, a hard disk, or other magnetic disk or optical memory are stored on the electronically readable control signals, which can cooperate with a programmable hardware component or cooperate such that the respective method is performed.

A programmable hardware component may be integrated by a processor, a central processing unit (CPU), a graphics processing unit (GPU), a computer, a computer system, an application-specific integrated circuit (ASIC) Circuit (IC = Integrated Circuit), a system on chip (SOC) system, a programmable logic element or a field programmable gate array with a microprocessor (FPGA = Field Programmable Gate Array) may be formed.

The digital storage medium may therefore be machine or computer readable. Thus, some embodiments include a data carrier having electronically readable control signals capable of interacting with a programmable computer system or programmable hardware component such that one of the methods described herein is performed. One embodiment is thus a data carrier (or a digital storage medium or a computer readable medium) on which the program is recorded for performing any of the methods described herein.

In general, embodiments of the present invention may be implemented as a program, firmware, computer program, or computer program product having program code or data, the program code or data operative to perform one of the methods when the program resides on a processor or a computer programmable hardware component expires. The program code or the data can also be stored, for example, on a machine-readable carrier or data carrier. The program code or the data may be present, inter alia, as source code, machine code or bytecode as well as other intermediate code.

Another embodiment is further a data stream, a signal sequence, or a sequence of signals that represents the program for performing any of the methods described herein. The data stream, the signal sequence or the sequence of signals can be configured, for example, to be transferred via a data communication connection, for example via the Internet or another network. Embodiments are also data representing signal sequences that are suitable for transmission over a network or a data communication connection, the data representing the program.

For example, a program according to one embodiment may implement one of the methods during its execution by, for example, reading or writing one or more data into memory locations, optionally switching operations or other operations in transistor structures, amplifier structures, or other electrical, optical, magnetic or caused by another operating principle working components. Accordingly, by reading a memory location, data, values, sensor values or other information can be detected, determined or measured by a program. A program can therefore acquire, determine or measure quantities, values, measured variables and other information by reading from one or more storage locations, as well as effect, initiate or execute an action by writing to one or more storage locations and control other devices, machines and components ,

The embodiments described above are merely illustrative of the principles of the present invention. It will be understood that modifications and variations of the arrangements and details described herein will be apparent to others of ordinary skill in the art. Therefore, it is intended that the invention be limited only by the scope of the appended claims and not by the specific details presented in the description and explanation of the embodiments herein.

Claims (21)

Method for controlling access to a service ( 100 ) within a network, comprising: receiving ( 110 ; 420 ) of a data record ( 200 ) indicating an authorization to access at least one service; Identify an authorized user ( 120 ; 422 ) for which the data record ( 200 ) was created; To verify ( 130 ; 440 ), whether the record ( 200 ) was received from the authorized user; and granting access to the service ( 140 ; 470 ) if the record was received from the authorized user. The method of claim 1, further comprising: preventing access ( 150 ) on the service when the record ( 200 ) was not received from the authorized user. Method according to one of claims 1 or 2, wherein the identifying ( 120 ; 422 ) extracting information identifying the authorized user ( 214 ) from the dataset ( 200 ). Method according to one of claims 1 or 2, wherein the identifying ( 120 ; 422 ) comparing the received data set ( 200 ) comprising a list of stored records to obtain information identifying the authorized user. Method according to one of claims 3 or 4, wherein the checking comprises: transmitting ( 426 ) a request to a sending user ( 410 ) from which the record was received to confirm its identity. The method of claim 5, wherein the checking comprises: transmitting a task to the sending user; Receiving a solution ( 430 ) the task of the sending user; Determining a control solution for the task using the information identifying the authorized user; Comparing the control solution with the received solution; and verify ( 432 ) that the record was received from the authorized user when the control solution corresponds to or matches the solution.  The method of claim 6, wherein the task comprises a request to sign a random number.  Method according to one of claims 3 or 4, wherein the checking comprises: Determining another information identifying a sending user; and Confirm that the record was received from the authorized user when the information and other information identifies the same user. The method of claim 8, wherein the checking comprises: creating an encrypted connection ( 520 ) with the sending user ( 510 ) from which the record was received, using the other, the sending user ( 510 ) identifying information.  Method according to one of the preceding claims, wherein the checking is repeated at predetermined time intervals. Method according to one of the preceding claims, in which granting access to the service ( 470 ) comprises the transmission of a further data record which is available to a service provider ( 416 ) indicates an authorization on the service ( 416 ). Method according to one of the preceding claims, in which granting access to the service ( 470 ) a forwarding ( 474 ) of a service request ( 472 ) to a service provider ( 416 ). The method of any one of the preceding claims, further comprising: providing a data set indicating an authorization to access at least one service to an authorized user.  The method of any one of the preceding claims, further comprising: Confirming an identity of a recipient of the record to the sending user. The method of any one of the preceding claims, further comprising: verifying an integrity of the received data set ( 200 ). Method for obtaining access to a service ( 300 ) within a network for a user, comprising: transmitting a data set ( 310 ; 420 ) indicating to an authorized user an authorization to access at least one service; Receive a request ( 320 ; 426 ) to create a response indicating the identity of the user; and transmitting the answer ( 330 ; 430 ) indicating the identity of the user. The method of claim 16, further comprising: accessing the service ( 340 ; 470 ). Method for accessing a service ( 416 ) in a network, comprising: transmitting ( 420 ) of a record indicating authorization for an authorized user to at least one service ( 416 ) access; Identify an authorized user ( 422 ) for which the record was created; To transfer ( 426 ) a request to a sending user ( 410 ) from which the record was received to confirm its identity; and grant access ( 470 ) on the service ( 416 ) if the record was received from the authorized user.  The method of claim 18, further comprising: Encrypt traffic to and from the sending user. Contraption ( 500 ; 600 ) to control access to a service ( 552 . 554 . 556 ) within a network ( 550 ), comprising: an input interface ( 610 ) configured to receive a record indicating an authorization to access at least one service; an information processor ( 620 ) configured to identify an authorized user for whom the record was created; a verifier ( 640 ) configured to check whether the record has been received from the authorized user; and an output interface ( 650 ), which is designed to provide access to the service ( 552 . 554 . 556 ) if the record was received from the authorized user.  A computer program comprising program code for effecting one of the methods of claims 1 to 19 when the program is executed on a processor or a programmable hardware component.

Images