WO2002067532A1 - Verfahren zur übertragung von daten, proxy-server und datenübertragungssystem - Google Patents

Verfahren zur übertragung von daten, proxy-server und datenübertragungssystem Download PDF

Info

Publication number
WO2002067532A1
WO2002067532A1 PCT/DE2002/000587 DE0200587W WO02067532A1 WO 2002067532 A1 WO2002067532 A1 WO 2002067532A1 DE 0200587 W DE0200587 W DE 0200587W WO 02067532 A1 WO02067532 A1 WO 02067532A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
proxy server
proxy
server
processing unit
Prior art date
Application number
PCT/DE2002/000587
Other languages
English (en)
French (fr)
Inventor
Hans Joachim Bickenbach
Marcus Belke
Original Assignee
Deutsche Post Signtrust Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Deutsche Post Signtrust Gmbh filed Critical Deutsche Post Signtrust Gmbh
Publication of WO2002067532A1 publication Critical patent/WO2002067532A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the invention relates to a method for transmitting data between a first data processing unit and a second data processing unit
  • the invention further relates to a proxy server suitable for use in the method.
  • the invention also relates to a data transmission system.
  • the exchange of data via proxy servers is technically important because it enables particularly simple and secure access to data networks.
  • German Offenlegungsschrift DE 197 40 547 AI An example of a generic method is shown in German Offenlegungsschrift DE 197 40 547 AI.
  • This known method includes secure communication between a requesting application unit and a serving application unit using a proxy server. This method monitors whether the communication of the requesting unit matches a selected communication protocol.
  • the invention has for its object a generic Develop processes in such a way that secure communication between different
  • this object is achieved in that a generic method is carried out in such a way that the transmission takes place via at least one intermediate proxy server, the proxy server acquiring signature information, linking the signature information to at least some of the data and thereby authenticating the data and / or encrypted.
  • Signature information corresponds to a digital signature key.
  • the proxy server which authenticates and / or encrypts the data by linking to the signature information, transmits the encrypted data to an authentication server.
  • authentication server is widely used.
  • the authentication server contains validity information about all certificates.
  • a further proxy server which receives authenticated and / or encrypted data with the signature information, is received with the
  • the invention provides that the authentication server sends authentication information to the proxy server, which encrypts and / or authenticates the data using the signature information.
  • the authentication server sends the authentication information to the further server, which receives the data encrypted and / or authenticated with the signature information.
  • a further increase in data security can advantageously be achieved in that the signature is created using at least one digital key stored on a smart card.
  • a smart card is a microprocessor with memory that is attached to a plastic card.
  • the smart card is connected to the computer via the serial interface and a card reader.
  • An external operating system (similar to that of a computer) is started on the smart card by external application of a voltage, which the sequence of applications on the smart card and / or the inaccessible Allows private data to be saved on the smart card.
  • the SSL handshake protocol is at the beginning of an SSL connection. It has the following two tasks: on the one hand, the two communication partners are mutually authenticated; on the other hand, it enables the secure negotiation of a (symmetrical) key to encrypt the user data exchanged between the two communication partners.
  • the method is carried out in such a way that the proxy server is simulated by the first data processing unit as a virtual computer.
  • the proxy server prefferably be simulated as a virtual computer by the second data processing unit.
  • the proxy server is in a protected area of the data processing unit is operated.
  • a suitable security environment can be designed, for example, by means of a suitable software routine, operation and / or activation of the proxy server in a personal security environment being preferred.
  • Another object of the invention is to design a proxy server with an input for receiving data from a first data processing unit and for transmitting the data to a second data processing unit in such a way that the proxy server reads in signature information with which the signature information encrypts the data and / or authenticated and the encrypted and / or authenticated data transmitted to the second data processing unit.
  • the invention further provides a data transmission system for transmitting data between a first data processing unit and a second
  • the data processing unit such that the first data processing unit is connected to a first proxy server, that the second data processing unit is connected to a further proxy server, that the first proxy server has means for encryption and / or
  • Authenticating data is provided that the further proxy server is provided with means for encrypting and / or authenticating data, and that encrypted and / or authenticated data is transmitted between the first proxy server and the further proxy server.
  • FIG. 1 shows in FIG. 1 an overall system for the transmission of data between a first data processing unit and a second data processing unit.
  • the first data processing unit is a client C.
  • the client C can use any one to perform a
  • the client C is preferably a computer.
  • the term "computer” is to be understood in its broadest manner. It can be any suitable one for carrying out data processing functions and calculations
  • Act unit for example a workstation, a personal computer, a microcomputer, a circuit suitable for performing calculations or a virtual calculation unit.
  • Client C which acts as the first data processing unit, is connected to a second data processing unit.
  • the second data processing unit can also be designed in different ways. It is preferably also a computer in the broadest sense.
  • the data transmission preferably takes place between the first data processing unit and the second Data processing unit via a server.
  • server is to be understood just as little as the term computer.
  • server in its most general form, means any computer, including the simulation of a separate computer on one
  • the server is a real or virtual computer that contains data inputs and / or outputs that serve as a means of exchanging data with one or more other computers or other data processing units.
  • proxy servers SPC and SPS between the first data processing unit C and the second data processing unit S.
  • At least one of the two servers is equipped with means for authentication and / or encryption of data which are sent to it by the data processing unit directly connected to it.
  • the two secure proxies SPC and SPS are over any
  • connection can be line-related or at least partially via a radio connection.
  • the communication protocols can also be freely selected to facilitate adaptation to services available for data communication.
  • the proxy server designated SPC encrypts data sent by the first data processing unit C.
  • the encryption takes place with the help of a
  • the signature information is at least partially stored on a smart card SCI to increase data security. To further increase the It is appropriate for data security that the
  • Signature information is supplemented by the input of further data, for example by entering a special access code, in the simplest case a PIN code, on the first data processing unit. This unlocks signature information so that the associated digital key can be used.
  • a special access code in the simplest case a PIN code
  • the secure proxy SPC authenticates and / or encrypts those from the first
  • Data processing unit C transmits data and sends this to the further secure proxy PLC.
  • the further proxy PLC can in principle have a similar structure to the first proxy server SPC. It can also give one or more computers access to data. It is expedient to use a secure proxy that enables access to certain areas of web pages.
  • the further secure proxy PLC preferably controls data transmission from or to a special server, for example a server for data use in the World Wide Web (WWW).
  • a special server for example a server for data use in the World Wide Web (WWW).
  • the further proxy server SPS is also provided with means for authenticating and / or encrypting data.
  • the further server also encrypts and / or authenticates the data using signature information.
  • this signature information is stored on another smart card SC2.
  • the signature information is also possible for the signature information to be supplemented to form a signature key, for example by adding suitable secret code data.
  • the code data is a PIN number.
  • At least one of the proxy servers SPC or PLC is preferably connected to a configuration proxy KP1 or KP2.
  • the configuration proxy enables configuration data to be set in the first proxy server SPC and / or in the further proxy server SPS.
  • a preferred authentication of the information includes a check as to whether the information is provided with a valid certificate, the validity of the certificates being verified by checking status information in the authentication server.
  • the authentication server transmits one
  • Data information which certifies status information, for example on the validity of the certificate, to the first proxy server SPC and / or to the second proxy server SPS.
  • Proof of eligibility can be provided in various ways. For example, proof of authorization is provided by the certificates providing authorization information contain. Alternatively, however, it is also possible that the authorization is already determined via the identity of the respective user.
  • the authentication is also transmitted in encrypted form so that third parties are not able to misuse authentication information.
  • the further proxy server SPS also transmits digitally signed data to the authentication server.
  • the authentication server checks the authorization and / or identity of the operator of the further proxy server PLC.
  • An application of the security mechanism described above is particularly expedient if access to web pages requiring special security is to be guaranteed. This can, for example, prevent misused confidential and / or encrypted web pages from being made available on the Internet and from pretending to users of these pages that they have authorization and / or identity.
  • the user can ensure that confidential information is not transmitted to unauthorized persons.
  • the user of the first data processing unit C must check the security settings of the proxy connected to him. Carry out servers SPC in such a way that certain data transmission processes only take place to specially secured and / or certified further data processing units.
  • This security configuration can be set, for example, by the configuration proxy server KPl.
  • each of the security mechanisms shown can in principle be carried out individually, an overall combination of the security mechanisms is particularly expedient since this enables data communication that is secured on all sides.
  • a data communication network is particularly advantageous in which both the transmission of the data from the first data processing unit to the second
  • Data processing unit as well as the data transmission from the second data processing unit S to the first data processing unit C by exchanging certified and / or encrypted data.
  • UNIX denotes various platforms, such as Linux, HP-UX 11 or SUN-Solaris.
  • other computer programs can also be used, such as the programs of the Windows family from Microsoft, for example "Windows NT”, “Windows 95”, “Windows 98” or "Windows 2000”.
  • clients and servers are also known as Secure Proxy.
  • the invention includes implementations with which any protocol between two computers can be secured. These are preferably TCP / IP-based protocols.
  • TCP / IP-based protocols are preferably TCP / IP-based protocols.
  • the secure transmission of the data is preferably guaranteed by SSL.
  • SSL supports client and server authentication, encryption and integrity checking.
  • TCP / IP The Transmission Control Protocol / Internet Protocol, TCP / IP, is a standard that describes the exchange of data over a network and is used on the Internet. He forms the foundation for higher, specialized protocols such as HTTP.
  • Preferred proxy client and server software include one or more of the software modules listed below. There are also suitable configuration files. These are preferably only read in by the Secure Proxy. These files are created and maintained using the relevant configuration tool.
  • SQRP. exe is the name of a preferred executable program that is started on a server or on the client side as a background process.
  • the ".exe" suffixes are not applicable under Unix.
  • a preferred command file hereinafter referred to as CT32.DLL, contains preferred calls for the chip card reader under a suitable program such as Windows, For parsing the contents of the configuration files, the functions from another command file are required under Windows, of which a preferred embodiment is referred to below as GNU REGEX.DLL.
  • a proxy server preferably operates on behalf of a client a setup and clearing of TCP / IP connections through.
  • the proxy server waits for requests from clients (for example from WWW browsers) within a network protected by a firewall and forwards the requests to remote servers outside the firewall.
  • the responses from the spatially separated servers are also read by the proxy server and sent back to the client.
  • a firewall is preferably a software and / or hardware that only has limited public computers and / or
  • Network areas / e.g. local company networks) against attacks from "outside”.
  • the secure proxy server preferably also takes on additional tasks in order to protect the data traffic between the entities involved against external access.
  • proxy servers SPC and SPS shown are particularly secure, they are referred to as Secure Proxy. All statements regarding the secure proxy refer to at least one of the proxy servers mentioned. It is particularly advantageous that several - both in the case shown - proxy servers SPC and SPS have the properties shown. In simple embodiments, at least one proxy server has the properties shown.
  • This secure proxy can be one or more of the proxy servers used. At least one of the proxy servers preferably has the features of the secure proxy mentioned below, still However, it is more advantageous that several or all proxy servers have the features of the Secure Proxy SP.
  • SSL means Secure Sockets Layer. This is, in particular, a layer based on TCP / IP, which guarantees the encryption and integrity of data and the mutual authentication of the communication partners.
  • the SP is preferably implemented as a background process, which is expediently active even when no user is actively working in the system.
  • a background process can have different functions perceive and corresponds to a particularly advantageous implementation of the so-called "daemon" in the Cömputersystem UNIX.
  • the smart cards are preferably equipped with security features. A variety of such security features are known and can be used here. In order to ensure a particularly high level of data security, it is expedient that the smart cards are designed in accordance with the requirements of the Signature Act and therefore also serve as signature cards.
  • the SSL handshake protocol is used for the authentication mechanism, in which a symmetrical key for encrypting and decrypting the user data to be exchanged between the two communication partners is also negotiated.
  • the smart cards can perform various functions, and in order to implement different functionalities, it is possible to exchange the smart cards that are easy to produce compared to the computer hardware.
  • the smart cards advantageously perform functions in accordance with the SSL handshake protocol. It is advantageous here that the SSL handshake protocol uses one or more asymmetrical keys when calculating a symmetrical key, which keys are advantageously stored on the smart cards of the communication partners.
  • the SP client is started under Windows as a background process via the autostart mechanism during the logon process and under UNIX as a daemon process.
  • the PSE to be monitored is read by the SP from the "comport .cfg" file, which is located in the program's installation directory on all platforms.
  • "comport .cfg” can also contain so-called "user-friendly names”.
  • the user-friendly names are preferably system-specific character strings that reference a Personal Security Environment (PSE).
  • PSE Personal Security Environment
  • the user is prompted for input the PIN belonging to the PSE specified in "comport .cfg" is requested; under Windows this is preferably done only when an SSL connection is established.
  • the PSE provides a digital container for personal
  • a personal identification number is preferred
  • the PIN remains valid for a short, preferably predetermined period of time, for example five minutes after the last data transfer. After five minutes without data transfer, the SP client deletes the PIN from the memory for security reasons, so that the PIN should be re-entered when an SSL handshake protocol process is reinitialized.
  • the SP client reads the file “serves .cfg”, which is in the same directory as the file “comport .cfg”, and accepts its current settings.
  • the SP client receives also a certificate from the server, which he has checked with a directory service (DIR).
  • DIR directory service
  • the certificate includes an assignment of a natural person to an asymmetrical key.
  • the certificate of the owner of the smart card is stored as a file on the smart card.
  • the Directory Service is preferably a directory service that provides information about the validity of certificates.
  • the configuration files can contain different entries depending on the authorization of a user. They largely determine the behavior of the SP Client.
  • the installation directory of the service is the file, which is shown below as an example as "comport .cfg", in which the PSE selected during installation is entered.
  • the system administrator can use the
  • Configuration tool of the SP client can be edited.
  • the system administrator preferably has read and write access to this file.
  • Both the client and the Secure Proxy SP expediently have the file “comport. cfg ", which (at least under UNIX - see below) is created during the installation process.
  • Both the client proxy and the server proxy contain the COM port to be used. It preferably contains the data fields shown below. # COM port for card terminal:
  • An integer is specified as the COM port, which specifies the serial interface to be used, via which a connected card terminal is to be addressed.
  • CT-API card terminal application programming interface
  • another programming interface via which the card reader, which contains a smart card, can be addressed by programs.
  • the “comport. cfg "file contain several entries.
  • the PSE to be used by the SP is therefore identified by the key word" USE ". If “comport .cfg” was generated by the SP under Windows, the SP itself selects a PSE, provided this choice is clear. It uses the following rule when selecting the PSE: If “comport .cfg” contains only one entry, so this is selected. If “comport .cfg” contains two entries, but one of the two references the soft PSE, the other entry is selected. All other possible cases result in an undefined configuration of the SP without manual reconfiguration with the config tool, and a start of the SP with the "comport .cfg" configured only to a limited extent, generates an error message.
  • the illustration shows examples of the program functions used in script language.
  • the file "serves. cfg” is preferably written in such a script language.
  • This file preferably contains at least one of the following elements, with the use of all of the elements shown below being particularly preferred.
  • Such an element enables the selection of a secure proxy mode.
  • variable "Mode” is set here. This can contain one of the two values "KR” or "NORMAL".
  • the communication computer exchanges data between internal and external networks of the certification body.
  • the Secure Proxy in KR mode offers additional functions on the server side, such as adding the serial number of the client certificate as a URL parameter.
  • the service port is preferably specified so that it designates the port on which the secure proxy receives data from a configuration tool, for example a configuration proxy. This is preferred the transmission path via which the configuration tool sends data to the Secure Proxy is also specified.
  • the configuration tool is preferably the configuration proxy server KP1 shown in FIG. 1.
  • the configuration information is stored locally, the local hoast in the example shown having the IP address IP address 127.0.0.1.
  • Another file contains access information.
  • This file is also called a log file. Of course, this can be both an independent file and a subfile of the configuration file.
  • Another data element of the configuration file is an inactivity time.
  • Each online connection is assigned a timer thread, which measures the time that has elapsed since the last data traffic. If this time exceeds the inactivity time, the client proxy terminates the connection. If the proxy works in KR ⁇ mode, this value is ignored. The value "0" means "no inactivity time”.
  • the configuration file has a Contains directory structure, also known as a directory service.
  • a directory service instead of an internally contained directory service, however, access to an external directory service is equally possible.
  • the directory service from Signtrust is preferably used to verify certificates.
  • the embodiment of this storage unit is referred to below as the caching proxy.
  • No information is used to secure a connection in the file. cfg specified, the client SP forwards the information transparently. In this case, specifying a caching proxy can cause the client SP to forward this information to it.
  • the specification of this information is optional, since there may also be no such proxy.
  • the character string is preferably a Uniform Resource Locator (URL), which uniquely describes a resource to be searched in a data network, preferably on the Internet.
  • the string is sent from the browser to the server embedded in an HTTP request (HTTP reguest). Additional information can be inserted in the HTTP Reguest on the client as well as on the server side as so-called URL parameters.
  • URL Uniform Resource Locator
  • a preferred protocol is the HyperText Transfer Protocol (HTTP).
  • HTTP HyperText Transfer Protocol
  • data is transferred on the Internet, which is preferably visualized in a browser.
  • Port be mapped.
  • This feature is interesting, for example, for the telnet service, where no proxy can be specified. Instead you should telnet one Establish a connection to the client proxy, which maps the telnet port to the server proxy of the remote machine, on which the port is remapped to the originally intended telnet peer. Or, in general terms: the SP has a port remapping, which enables a port X on the client side to be redirected to a port Y (and IP address Z) on the server side.
  • cfg "contains a list of all ports on which a client proxy waits for incoming requests. First, this list is used to open a TCP / IP socket (with local IP address and specified port) for each specified port If the file has an assignment of the respective port to a destination address (IP address and port), this is used for port remapping, so the client proxy is able to send requests to one and the same local IP address with different ports Map requests to various IP addresses (remapping).
  • the client proxy receives the destination address of the server proxy from the specification of the caching proxy.
  • the address of the client proxy should be entered as a proxy in the client application used (e.g. browser, Telnet terminal). It goes without saying for the person skilled in the art that both URLs and complete ports can be remapped, in particular to a remote one
  • Proxy server which should be specified in the usual format " ⁇ IP address>: ⁇ port>".
  • mapping URLs wildcards are possible, just as they are when securing certain URLs can be used.
  • mapping a port When mapping a port, whether encryption should take place for a mapped connection depends, for example, on the keywords "SECURE” or "INSECURE". If “SECURE” is specified, the connection is encrypted in any case. If “INSECURE” is specified, the connection is normally only encrypted to a limited extent. However, if the keyword “HTTP” is still specified, an attempt is made to interpret the data sent by the user application as HTTP requests. The URL is extracted from the request; then a comparison is made with the "SECURE_URL” list. If the URL of the request is found in this list, the communication is encrypted despite the "INSECURE” specification regarding the port.
  • the keyword “REQUESTED_URL” is specified instead of a host name and a port, the keyword “HTTP” should also be available and the port defined as "INSECURE". In this case, the data that is sent to this port is Request interpreted, the URL extracted from this reguest and forwarded transparently to the target computer.
  • connection can be defined in different ways.
  • the inactivity time is in the SP Client proxy measured by a timer and defined as the time that has passed per online connection since the last data transfer between the SP client and the secure proxy. If this time threshold is reached, the online connection concerned is terminated.
  • a special server is simulated in a computer by a special software routine, so that the first data processing unit also fulfills the functions of the proxy server.
  • the Secure Proxy is started, for example, under Windows as a background process for the logon process (through the autostart mechanism) and under UNIX as a daemon process in the background.
  • the PSE to be used by the Secure Proxy is read by the service from the "comport .cfg" file, which is located in the installation directory of the Secure Proxy.
  • the Secure Proxy then preferably prompts the user to enter the PIN, with which the protected resources of the PSE specified in the “comport .cfg” file can be activated.
  • the PIN is used during the entire runtime of the Secure Proxy Secure proxy kept in memory.
  • the secure proxy receives the certificate from the client, which it has checked at DIR.
  • the smart card should remain in the card reader permanently, otherwise the secure proxy will only function to a limited extent.
  • the Secure Proxy automatically ends all actions performed on it. In particular, all online connections are terminated.
  • the Secure Proxy should then be started again: A start phase starts again with PIN entry and verification, certificate test and reading in the configuration file "server.cfg".
  • Proxy process can be started in the background.
  • the structure of such a secure proxy is similar to that of the SP client. It expects connection requests from SP clients, carries out authentication, receives the encrypted data packets, unpacks them and forwards them to the "regular" web servers. The responses from the servers are also forwarded to the corresponding SP clients.
  • the web server used in connection with the Secure Proxy should be configured so that only access from the
  • “Localhost” IP address: 127.0.0.1
  • a client Application e.g. a browser
  • a “firewall” can prevent remote access to certain ports on the web server.
  • the secure proxy In addition to forwarding requests to the web server and forwarding the responses to the SP client, the secure proxy must also check the access rights of the user.
  • the Secure Proxy When establishing a secure connection, the Secure Proxy receives information about the user of the SP client. The client's certificate transmitted during authentication is used to check the access rights to certain URLs. The certificate number and the publisher of the
  • the Secure Proxy compares the certificate with the data stored in the "access.cfg" file.
  • the secure proxy forwards the HTTP request to the web server. Otherwise, a corresponding error message is issued generated and sent to the SP client in the form of an HTTP document.
  • Server. cfg file may look like. Depending on the system configuration, the individual file contents differ.
  • Each server proxy has a file “server.cfg”, which contains its basic configuration.
  • the individual parameters are explained in more detail below:
  • the file “server.cfg” can be edited using the configuration tools.
  • the variable "MODE” is set in the Secure Proxy mode. This can be one of the three values "KR", “WITHSOFTPSE” or “Normal”” contain.
  • the "KR" mode only if the string "raclient" can be found in the HTTP reguest, the "WITHSOFTPSE” mode, however, generally modifies the HTTP_Reguest.
  • a service port defines the way in which messages from the configuration tool send messages to the proxy. These messages preferably originate from the local host.
  • the "LOG_FILE" variable can be used to specify a log file in which error messages can be written.
  • Valid values for the inactivity time can be are between one minute (0:01) and one day (24:00).
  • a timer is started per secured connection to a client proxy, which measures the inactivity time for a connection.
  • the inactivity time is defined as the time that has elapsed since the last client proxy was registered. After the specified value for the inactivity time has expired, any connection over which no data transmission has taken place is terminated.
  • the directory service from Signtrust is used to verify certificates.
  • the server proxy can thus use the certificate of the client proxy, which this is used as part of the Send SSL handshake protocol process to the server proxy, check with DIR.
  • the proxy servers preferably have a file "access.cfg" which manages the access rights to web server content.
  • the access authorization is checked on the basis of the certificates transmitted by the clients during authentication.
  • the file contains a grouping of all valid and access-authorized pairs from publishers and certificate numbers New certificates and groups can be added using the configuration tools and then assigned to the web content to be secured.
  • CA_1 "CA-1”
  • CA_2 "CA-2”
  • CA_3 "CA-3”
  • # in group PUBLIC are all users who have signed up with a
  • URL http: // www. Server. de / encrypted / users / chef / ALLOWED_TO
  • URL http: // www. Server. com / encrypted / mini / ALLOWED_TO MINIJ3ROUP
  • URL http: // www. Server. com / encrypted / mini / ALLOWED_TO MAXI_GROUP
  • URL http: // www. from_file. com / * ALLOWED_TO FROM_FILE
  • a group contains a number of pairs, consisting of a certificate number and issuer (CA), whereby subgroups are also allowed. The individual pairs are separated from each other by the separator "/". Group names must be contiguous (no spaces, tabs) and may only contain the separator character to a limited extent. New groups are added under [ACCESS_GROUPS]. As shown, wildcards ("*" for any number of characters and "?” For any character) can also be used when specifying the certificate numbers. When specifying the publisher, one of the symbolic names from ACCESS_CAS can be used as well as a normal name of the CA in quotes.
  • CA A preferred directory service is shown below as CA.
  • ALL_OF_HERBERT AL: Herbert
  • ALL_OF_HERBERT AL: Herbert
  • a group can also be specified by the content of a file.
  • This file should then contain the pairs consisting of certificate number and CA name (in quotation marks), separated by a colon as above. This procedure makes it easier to include automatically generated lists in the review.
  • the keyword "include” is used for this.
  • the unclosed file consists of individual lines of the form
  • a hash value is formed.
  • the hash value is formed by a mathematical method in which a character string that is uniquely assigned to a data stream is calculated.
  • An example of a hash method is SHA1.
  • ⁇ CertNr> and ⁇ Issuer Dname> indicate the serial number and the issuer of the certificate.
  • ⁇ Flag> stands for a number, which can be "0" or "1".
  • "0” stands for the information that the specified certificate is a SigG certificate of a smart card.
  • the field ⁇ hash value> including the separating colon is then omitted. If the value "1" is specified for ⁇ Flas>, then the entry is the identifier of a soft PSE, and the field ⁇ hash value> is required and specifies the hash value via the public key of the soft PSE certificate.
  • the hash value must be generated using SHA1 and entered here in the Base-64 coded representation. Examples:
  • This example specifies a participant in soft PSE mode who has a SigG certificate.
  • ALL was introduced especially for setting up VIP areas - resources that should only be accessible to customers of a certain CA.
  • the user can use the configuration tool
  • server administrator specify an inactivity time in the file "server.cfg”.
  • server administrator specifies an inactivity time in the file "server.cfg”.
  • a timer is started for each secure connection to an SP client, which measures the inactivity time in relation to the defined period of validity.
  • the inactivity time is the time defined that has passed since the last data transfer to the associated SP client.
  • the secure connection to the corresponding SP client is interrupted. However, if a new request is made to the server proxy within the period of inactivity, the timer is reset and this starts again with its time measurement.
  • the SP server can be adapted to special system conditions.
  • environment variables system variables under Windows NT
  • the installation of the software modules is under Windows by the setup program "InstallShield” and under UNIX by the Operating system-specific package handlers are implemented and run largely automatically.
  • the user has the option of deciding whether to restart after this installation or not. If a restart is triggered, the SP is automatically started as a background process.
  • HP-UX the installation is carried out using HP-UX's own software depot installer swinstall.
  • Configuration files are configured in a table of contents and an SQRP is installed.
  • the specialist knows how to carry out the necessary steps, for example by logging in as root user.
  • installation with InstallShield sets up the Secure Proxy under • Windows as a background process that starts automatically when the system is started.
  • the SP can be started manually at any time using the Windows Start button (Start - Programs).
  • the SP client can first be started under Windows without the "comport .cfg" file. He then writes this file, which now contains all the user-friendly names that the system provides, into his installation directory and ends.
  • the Secure Proxy can start via a suitable menu, in particular a context-sensitive menu.
  • the executable program "SQRP" is stored in the installation directory of the Secure Proxy.
  • the Secure Proxy can be restarted at any time possible.
  • the creation and editing of the configuration files of the user interfaces is not a necessary part of the actual SP application, but is carried out, for example, with the configuration tool documented in [SP_CfgDoc].
  • the proxy server contains as few direct user interfaces as possible.
  • a possible user interface is an input dialog for a suitable code, in particular a PIN.
  • Interface is used to enter the PIN for the chip card used, with which the user identifies. If the PIN is not entered successfully, the Secure Proxy is ended or started only to a limited extent.
  • the Secure Proxy is reconfigured by restarting. This is particularly useful, but not necessary.
  • This configuration information is read in by the Secure Proxy itself. This either occurs when the SP is started or can be forced by selecting the "Reconfigure proxy" button in the main menu of the configuration tool. The SP then carries out a complete restart, that is, all connections are closed first ended, then the SP behaves as when the program was started: the PIN entry dialog is displayed and after entering the correct PIN, the Secure Proxy is started with the current configuration information.
  • the SP After successful installation and successful start of the SP, it will go into live operation.
  • the SP runs autonomously in its live mode.
  • the messages of the SP are recorded in the so-called event log.
  • the event log is displayed using the following menu items on the Windows NT taskbar: Start - Programs - Management (General) - Event Viewer
  • the SP entries are entered in the Application Protocol category.
  • the entries in turn can represent error messages, warnings and information messages.
  • command "tail” is in a shell used.
  • the required command parameters are listed in the table below:

Abstract

Die Erfindung betrifft ein Verfahren zur Übertragung von Daten zwischen einer ersten Datenverarbeitungseinheit und einer zweiten Datenverarbeitungseinheit. Erfindungsgemäss wird dieses Verfahren so durchgeführt, dass die Übertragung über mindestens einen zwischengeschalteten Proxy-Server erfolgt, wobei der Proxy-Server Signaturinformationen erfasst, die Signaturinformationen mit wenigstens einem Teil der Daten verknüpft und hierdurch die Daten beglaubigt und/oder verschlüsselt. Die Erfindung betrifft ferner einen für die Durchführung des Verfahrens geeigneten Proxy-Server und ein Datenübertragungssystem.

Description

Verfahren zur Übertragung von Daten, Proxy-Server und
Datenubertragungssystem
Beschreibung:
Die Erfindung betrifft ein Verfahren zur Übertragung von Daten zwischen einer ersten Datenverarbeitungseinheit und einer zweiten Datenverarbeitungseinheit
Die Erfindung betrifft ferner einen für den Einsatz in dem Verfahren geeigneten Proxy-Server .
Die Erfindung betrifft außerdem ein Datenübertragungssystem.
Der Austausch von Daten über Proxy-Server ist technisch bedeutend, weil hierdurch ein besonders einfacher und sicherer Zugang zu Datennetzwerken ermöglicht wird.
Ein Beispiel eines gattungsgemäßen Verfahrens ist in der Deutschen Offenlegungsschrift DE 197 40 547 AI dargestellt. Dieses bekannte Verfahren beinhaltet eine sichere Kommunikation zwischen einer anfordernden Anwendungs-Einheit und einer bedienenden Anwendungs-Einheit unter Verwendung eines Proxy-Servers . Bei diesem Verfahren wird überwacht, ob die Kommunikation der anfordernden Einheit mit einem selektierten Kommunikationsprotokoll übereinstimmt.
Dieses bekannte Verfahren ist jedoch auf einen Einsatz mit vorher vorgegebenen Kommunikationsprotokollen beschränkt.
Der Erfindung liegt die Aufgabe zugrunde, ein gattungsgemäßes Verfahren so weiterzuentwickeln, dass eine sichere Kommunikation zwischen verschiedenen
Datenverarbeitungseinheiten ermöglicht wird. Vorzugsweise soll dieses Verfahren unabhängig von den jeweils ' eingesetzten Kommunikationsprotokollen sein.
Erfindungsgemäß wird diese Aufgabe dadurch gelöst, dass ein gattungsgemäßes Verfahren so durchgeführt wird, dass die Übertragung über mindestens einen zwischengeschalteten Proxy- Server erfolgt, wobei der Proxy-Server Signaturinformationen erfasst, die SignaturInformationen mit wenigstens einem Teil der Daten verknüpft und hierdurch die Daten beglaubigt und/oder verschlüsselt.
Hierbei ist es besonders zweckmäßig, dass die
Signaturinformationen einem digitalen Signaturschlüssel entsprechen.
Zur weiteren Erhöhung der Datensicherheit ist es vorteilhaft, dass der Proxy-Server, der die Daten durch Verknüpfung mit der Signaturinformation authentisiert und/oder verschlüsselt, die verschlüsselten Daten an einen Authentisierungsserver übermittelt .
Der Begriff Authentisierungsserver ist in einer weiten
Bedeutung zu verstehen. Er beinhaltet insbesondere einen Verzeichnisserver, der ein Verzeichnis aller Zertifikate mit • der dazugehörigen Statusinformation enthält. Es ist bevorzugt, dass der Authentisierungsserver Gültigkeitsinformationen über sämtliche Zertifikate enthält.
Es ist jedoch gleichfalls möglich, beispielsweise nur die gültigen Zertifikate oder nur die gesperrten Zertifikate zu speichern und durch eine Anfrage bei dem Authentisierungsserver die Gültigkeit beziehungsweise die Ungültigkeit des Zertifikats zu überprüfen.
Ferner ist es zweckmäßig, dass ein weiterer Proxy-Server, der mit der Signaturinformation authentisierte und/oder verschlüsselte Daten empfängt, die mit der
Signaturinformation verschlüsselten und/oder authentisierten Daten an den Authentisierungs-Server überträgt.
Eine vorteilhafte Weiterführung dieser Varianten der
Erfindung sieht vor, dass der Authentisierungs-Server eine Authentisierungsinformation an den Proxy-Server sendet, der unter Einsatz der SignaturInformation die Daten verschlüsselt und/oder authentisiert .
Eine weitere, gleichfalls bevorzugte Methode zur Erhöhung der Datensicherheit ist, dass der Authentisierungs-Server die Authentisierungsinformation an den weiteren Server sendet, der die mit der SignaturInformation verschlüsselten und/oder authentisierten Daten empfängt.
Eine weitere Erhöhung der Datensicherheit lässt sich vorteilhafterweise dadurch erzielen, dass die Signatur mittels wenigstens eines auf einer Smart-Card gespeicherten, digitalen Schlüssels erstellt wird.
Eine Smart Card ist ein Mikro-Prozessor mit Speicher, der auf eine Kunststoff-Karte aufgebracht wird. Die Smart Card steht mit dem Computer über die serielle Schnittstelle und einen Kartenleser in Verbindung. Auf der Smart Card wird durch externes Anlegen einer Spannung ein Betriebssystem (ähnlich dem eines Computers) gestartet, welches den Ablauf von Applikationen auf der Smart Card und/oder das unzugängliche Speichern von privaten Daten auf der Smart Card ermöglicht.
Ferner ist es vorteilhaft, das Verfahren so durchzuführen, dass ein Aufbau einer sicheren Datenverbindung mittels eines Authentisierungsmechanismus eingeleitet wird.
Es ist besonders zweckmäßig, ein IPSEC-Protokoll als Authentisierungsmechanismus einzusetze .
Eine andere vorteilhafte Ausführungsform dieser
Implementation zeichnet sich dadurch aus, dass ein Secure Sockets Layer - Handshake-Protokoll als Authentisierungsmechanismus dient .
Das SSL-Handshake-Protokoll steht am Anfang einer SSL- Verbindung. Es hat die folgenden zwei Aufgaben: zum Einen werden die beiden Kommunikationspartner gegenseitig authentisiert; zum Anderen ermöglicht es die sichere Aushandlung eines (symmetrischen) Schlüssels zum Verschlüsseln der zwischen den beiden Kommunikationspartnern ausgetauschten Nutzdaten.
Ferner ist es zweckmäßig, dass das Verfahren so durchgeführt wird, dass der Proxy-Server von der ersten Datenverarbeitungseinheit als ein virtueller Rechner simuliert wird.
Es ist ferner zweckmäßig, dass der Proxy-Server durch die zweite Datenverarbeitungseinheit als ein virtueller Rechner simuliert wird.
Hierbei ist es besonders vorteilhaft, dass der Proxy-Server in einem geschützten Bereich der Datenverarbeitungseinheit betrieben wird.
Eine geeignete Sicherheitsumgebung kann beispielsweise durch eine geeignete Softwareroutine gestaltet werden, wobei ein Betrieb und/oder eine Freischaltung des Proxy-Servers in einem Personal Security Environment bevorzugt ist.
Ein weiterer Gegenstand der Erfindung ist, einen Proxy-Server mit einem Eingang zum Empfang von Daten von einer ersten Datenverarbeitungseinheit und zur Übertragung der Daten an eine zweite Datenverarbeitungseinheit so zu gestalten, dass der Proxy-Server eine Signaturinformation einliest, mit der Signaturinformation die Daten verschlüsselt und/oder authentisiert und die verschlüsselten und/oder authentisierten Daten an die zweite Datenverarbeitungseinheit übermittelt .
Die Erfindung sieht ferner vor, ein Datenübertragungssystem zur Übertragung von Daten zwischen einer ersten Datenverarbeitungseinheit und einer zweiten
Datenverarbeitungseinheit so zu gestalten, dass die erste Datenverarbeitungseinheit mit einem ersten Proxy-Server verbunden ist, dass die zweite Datenverarbeitungseinheit mit einem weiteren Proxy-Server verbunden ist, dass der erste Proxy-Server mit Mitteln zum Verschlüsseln und/oder
Authentisieren von Daten versehen ist, dass der weitere Proxy-Server mit Mitteln zum Verschlüsseln und/oder Authentisieren von Daten versehen ist, und dass zwischen dem ersten Proxy-Server und dem weiteren Proxy-Server verschlüsselte und/oder authentisierte Daten übertragen werden. •
Weitere Vorteile, Besonderheiten und zweckmäßige Weiterbildungen der Erfindung ergeben sich aus den Unteransprüchen und der nachfolgenden Darstellung bevorzugter Ausführungsbeispiele anhand der Zeichnung.
Die Zeichnung zeigt in Fig. 1 ein Gesamtsystem zur Übertragung von Daten zwischen einer ersten Datenverarbeitungseinheit und einer zweiten Datenverarbeitungseinheit .
Vorzugsweise handelt es sich bei der ersten
Datenverarbeitungseinheit um eine zur Ausführung von Anwendungen geeignete Datenverarbeitungseinheit. Insbesondere ist die erste Datenverarbeitungseinheit ein Client C.
Der Client C kann eine beliebige zur Durchführung eines
Datenaustauschs geeignete Einheit sein. Vorzugsweise ist der Client C ein Computer. Der Begriff „Computer" ist in seiner umfassendsten Weise zu verstehen. Es kann sich hierbei um eine beliebige, zur Durchführung von Datenverarbeitungsfunktionen und Berechnungen geeignete
Einheit handeln, beispielsweise eine Workstation, einen Personalcomputer, einen Mikrocomputer, eine zur Durchführung von Berechnungen geeignete Schaltung oder eine virtuelle Berechnungseinheit .
Der als erste Datenverarbeitungseinheit wirkende Client C ist mit einer zweiten Datenverarbeitungseinheit verbunden. Die zweite Datenverarbeitungseinheit kann gleichfalls auf verschiedene Weisen gestaltet sein. Vorzugsweise handelt es sich hierbei auch um einen Computer im weitesten Sinne.
Vorzugsweise erfolgt die Datenübertragung zwischen der ersten Datenverarbeitungseinheit und der zweiten Datenverarbeitungseinheit über einen Server. Der Begriff Server ist ebensowenig wie der Begriff Computer einschränkend zu verstehen. Der Begriff Server bedeutet in seiner allgemeinsten Form einen beliebigen Computer einschließlich der Simulation eines separaten Computers auf einem
Simulationsrechner. Insbesondere handelt es sich bei dem Server um einen realen oder virtuellen Computer, der Dateneingänge und/oder -ausgänge enthält, die als Mittel dienen, einen Datenaustausch mit einem oder mehreren anderen Computern oder sonstigen Datenverarbeitungseinheiten durchzuführen.
Im dargestellten Fall befinden sich zwischen der ersten Datenverarbeitungseinheit C und der zweiten Datenverarbeitungseinheit S zwei Proxy-Server SPC und SPS. Wenigstens einer der beiden Server ist mit Mitteln zur Authentisierung und/oder Verschlüsselung von Daten ausgestattet, die von der unmittelbar mit ihm verbundenen Datenverarbeitungseinheit an ihn gesendet werden. Die beiden Secure-Proxys SPC und SPS sind über eine beliebige
Datenleitung miteinander verbunden, wobei es nicht auf die Art der Verbindung ankommt. Beispielsweise kann diese Verbindung leitungsbezogen oder zumindest teilweise über eine Funkverbindung erfolgen. Die Kommunikationsprotokolle können gleichfalls frei gewählt werden, um eine Anpassung an jeweils für die Datenkommunikation verfügbare Dienste zu erleichtern.
Im dargestellten Fall verschlüsselt der mit SPC bezeichnete Proxy-Server von der ersten Datenverarbeitungseinheit C gesendete Daten. Die Verschlüsselung erfolgt mit Hilfe einer
Signaturinformation. Die Signaturinformation ist zur Erhöhung der Datensicherheit wenigstens teilweise auf einer Smart-Card SCI gespeichert. Zu einer weiteren Erhöhung der Datensicherheit ist es zweckmäßig, dass die
Signaturinformation durch die Eingabe weiterer Daten ergänzt wird, beispielsweise indem auf der ersten Datenverarbeitungseinheit ein spezieller Zugriffscode, im einfachsten Fall ein PIN-Code, eingegeben wird. Hierdurch wird eine Signaturinformation freigeschaltet, so dass der zugehörige digitale Schlüssel eingesetzt werden kann.
Unter Einsatz des digitalen Schlüssels authentisiert und/oder verschlüsselt der Secure-Proxy SPC die von der ersten
Datenverarbeitungseinheit C übermittelten Daten und sendet diese an den weiteren Secure-Proxy SPS.
Der weitere Proxy SPS kann prinzipiell einen ähnlichen Aufbau aufweisen wie der erste Proxy-Server SPC. Er kann gleichfalls einem oder mehreren Computern den Zugang zu Daten ermöglichen. Zweckmäßigerweise handelt es sich dabei um einen Secure-Proxy, der einen Zugang zu bestimmten Bereichen von Web-Seiten ermöglicht.
Vorzugsweise steuert der weitere Secure-Proxy SPS eine Datenübertragung von beziehungsweise zu einem speziellen Server, beispielsweise einem Server für einen Dateneinsatz im World Wide Web (WWW) .
Zur Erhöhung der Datensicherheit ist es zweckmäßig, dass der weitere Proxy-Server SPS gleichfalls mit Mitteln zu einer Authentisierung und/oder Verschlüsselung von Daten versehen ist.
Zu diesem Zweck ist es vorteilhaft, dass auch der weitere Server unter einem Einsatz von Signaturinformationen die Daten verschlüsselt und/oder authentisiert. Vorzugsweise sind diese Signaturinformationen auf einer weiteren Smart-Card SC2 gespeichert. Hierbei ist es gleichfalls möglich, dass die SignaturInformationen - beispielsweise durch Hinzugabe von geeigneten geheimen Code-Daten - zu einem Signaturschlüssel ergänzt werden. Bei den Code-Daten handelt es sich in einem besonders einfachen und zweckmäßigen Fall um eine PIN-Nummer.
Vorzugsweise ist wenigstens einer der Proxy-Server SPC, beziehungsweise SPS mit einem Konfigurationsproxy KP1, beziehungsweise KP2, verbunden. Der Konfigurationsproxy ermöglicht eine Einstellung von Konfigurationsdaten in dem ersten Proxy-Server SPC und/oder in dem weiteren Proxy-Server SPS.
Zur weiteren Erhöhung der Datensicherheit ist es zweckmäßig, dass eine Authentisierung von Informationen durch einen separaten Authentisierungsserver erfolgt.
Eine bevorzugte Authentisierung der Information beinhaltet eine Überprüfung, ob die Informationen mit einem gültigen Zertifikat versehen sind, wobei die Gültigkeit der Zertifikate durch eine Überprüfung von Statusinformationen in dem Authentisierungsserver nachgewiesen wird.
Der Authentisierungs-Server übermittelt eine
Dateninformation, die eine Statusinformation , zum Beispiel über die Gültigkeit des Zertifikats bescheinigt, an den ersten Proxy-Server SPC und/oder an den zweiten Proxy-Server SPS.
Ein Berechtigungsnachweis kann auf verschiedene Weise erfolgen. Beispielsweise erfolgt ein Berechtigungsnachweis dadurch, dass die Zertifikate eine Berechtigungsinformation enthalten. Alternativ ist es jedoch gleichfalls möglich, dass bereits über die Identität des jeweiligen Benutzers die Berechtigung ermittelt wird.
Hierbei ist es zweckmäßig, dass die Authentisierung gleichfalls verschlüsselt übertragen wird, damit Dritte nicht in die Lage versetzt werden, missbräuchlich AuthentisierungsInformationen zu erzeugen.
Ferner ist es zweckmäßig, dass auch der weitere Proxy-Server SPS digital signierte Daten an den Authentisierungs-Server übermittelt. In diesem Fall überprüft der Authentisierungs- Server die Berechtigung und/oder Identität des Betreibers des weiteren Proxy-Servers SPS.
Eine Anwendung des zuvor beschriebenen Sicherungsmechanismus ist besonders zweckmäßig, wenn ein Zugang zu besonders sicherungsbedürftigen Web-Seiten gewährleistet sein soll. Hierdurch kann beispielsweise verhindert werden, dass missbräuchlich vertrauliche und/oder verschlüsselte Web- Seiten im Internet zur Verfügung gestellt werden und Benutzern dieser Seiten eine Berechtigung und/oder Identität vortäuschen.
Durch eine Prüfung der Berechtigung und/oder Identität des Betreibers des weiteren Proxy-Servers SPS, beziehungsweise der mit dem weiteren Proxy-Server SPS verbundenen weiteren Datenverarbeitungseinheit S, kann der Anwender sicherstellen, dass vertrauliche Informationen nicht an unberechtigte Personen übermittelt werden.
Der Benutzer der ersten Datenverarbeitungseinheit C muss die Sicherheitseinstellungen des mit ihm verbundenen Proxy- Servers SPC so vornehmen, dass bestimmte Datenübertragungsvorgänge nur zu besonders gesicherten und/oder beglaubigten weiteren Datenverarbeitungseinheiten erfolgen. Eine Einstellung dieser Sicherheitskonfiguration ist beispielsweise durch den Konfigurationsproxy-Server KPl möglich.
Hierdurch wird gewährleistet, dass bestimmte vertrauliche Informationen, wie beispielsweise Kreditkartennummern nicht an beliebige, sondern nur an besonders authentisierte Web- Seiten übertragen werden. Durch eine Übermittlung von Informationen, insbesondere von ausgewählten, geheimzuhaltenden Informationen, ausschließlich an zuvor legitimierte Stellen, wird eine missbräuchliche Abfrage der vertraulichen Daten vermieden.
Obwohl jeder der dargestellten Sicherungsmechanismen grundsätzlich einzeln erfolgen kann, ist eine Gesamtkombination der Sicherheitsmechanismen besonders zweckmäßig, da so eine allseitig gesicherte Datenkommunikation ermöglicht wird.
Wegen der vollständigen Sicherheit ist ein Datenkommunikationsnetz besonders vorteilhaft, bei dem sowohl die Übertragung der Daten von der ersten Datenverarbeitungseinheit zu der zweiten
Datenverarbeitungseinheit als auch die Datenübertragung von der zweiten Datenverarbeitungseinheit S zu der ersten Datenverarbeitungseinheit C durch einen Austausch von beglaubigten und/oder verschlüsselten Daten erfolgen.
Nachfolgend werden bevorzugte Ausfuhrungsformen der Erfindung dargestellt, wobei besonders vorteilhafte Kommunikationsprotokolle und Computerprogramme eingesetzt werde .
Auch dort, wo die Protokolle und die Programme mit konkreten, bekannten Begriffen bezeichnet werden, ist es klar, dass sie durch andere, gleichwirkende Funktionen aufweisende Protokolle und Computerprogramme ersetzt werden können.
So bezeichnet beispielsweise die Bezeichnung „UNIX" verschiedene Plattformen, wie beispielsweise Linux, HP-UX 11 oder SUN-Solaris. An Stelle von UNIX-basierten Programmen können jedoch auch andere Computerprogramme eingesetzt werden, wie die Programme der Windows-Familie von Microsoft, beispielsweise „Windows NT", „Windows 95", „Windows 98" oder „Windows 2000".
Soweit es nur eingeschränkt dargestellt ist, gilt die Darstellung sowohl für Clients als auch für Server. Zusammenfassend werden Clients und Server auch als Secure Proxy bezeichnet.
Die Erfindung beinhaltet Implementationen, mit denen beliebige Protokolle zwischen zwei Rechnern abgesichert werden können. Vorzugsweise handelt es sich dabei um TCP/IP- basierte Protokolle. Die sichere Übertragung der Daten wird dabei vorzugsweise durch SSL gewährleistet. Im Einzelnen unterstützt SSL Authentisierung von Client und Server, Verschlüsselung und Integritätsprüfung.
Das Transmission Control Protocol/Internet Protocol, TCP/IP, ist ein Standard, der den Austausch von Daten über ein Netzwerk beschreibt und im Internet zur Anwendung kommt. Er bildet das Fundament für höhere, spezialisierte Protokolle wie HTTP.
Bevorzugte Proxy Client- und Server-Software umfasst eine oder mehrere der nachfolgend aufgelisteten Software-Module. Hinzu kommen geeignete Konfigurationsdateien. Diese werden vom Secure Proxy vorzugsweise nur eingelesen. Die Erstellung und Wartung dieser Dateien erfolgt mit dem jeweiligen Konfigurationswerkzeug.
Figure imgf000015_0001
SQRP. exe ist der Name eines bevorzugten ausführbaren Programmes, das auf einem Server, beziehungsweise auf Client Seite als Hintergrund-Prozess gestartet wird. Unter Unix entfallen die „ .exe"-Endungen.
Eine bevorzugte Befehlsdatei, die nachfolgend als CT32.DLL bezeichnet wird, beinhaltet bevorzugte Aufrufe für den Chipkartenleser unter einem geeigneten Programm wie Windows, Für das Parsen der Inhalte der Konfigurationsdateien werden unter Windows die Funktionen aus einer weiteren Befehlsdatei benötigt, von der eine bevorzugte Ausfuhrungsform nachfolgend als GNU REGEX.DLL bezeichnet wird.
Figure imgf000016_0001
Nachfolgend werden bevorzugte Funktionen des Datenübertragungssystems und der Vorrichtung zur Durchführung des Verfahrens beispielhaft erläutert .
Vorzugsweise führt ein Proxy Server im Auftrag eines Clients einen Auf- und Abbau von TCP/IP-Verbindungen durch. Der Proxy Server wartet auf Anfragen von Clients (zum Beispiel von WWW- Browsern) innerhalb eines durch eine Firewall geschützten Netzwerks und leitet die Anfragen zu entfernten Servern außerhalb der Firewall weiter. Die Antworten der räumlich getrennten Server werden ebenfalls vom Proxy Server gelesen und zum Client zurückgeschickt.
Eine Firewall ist vorzugsweise eine Soft- und/oder Hardware, die nur eingeschränkt öffentliche Computer und/oder
Netzwerkbereiche /z.B. lokale Firmennetze) vor Angriffen „von außen" schützt .
Vorzugsweise übernimmt der Secure Proxy-Server zusätzlich weitere Aufgaben, um den Datenverkehr zwischen den beteiligten Instanzen gegen äußere Zugriffe zu schützen.
Da die dargestellten Proxy-Server SPC und SPS besonders gesichert sind, werden sie als Secure Proxy bezeichnet. Sämtliche Ausführungen zu dem Secure Proxy beziehen sich auf wenigstens einen der genannten Proxy-Server. Es ist besonders vorteilhaft, dass mehrere - im dargestellten Fall beide - Proxy-Server SPC und SPS die dargestellten Eigenschaften aufweisen. In einfachen Ausfuhrungsformen weist wenigstens ein Proxy-Server die dargestellten Eigenschaften auf.
Da nicht alle Ausfuhrungsformen der Erfindung es erfordern, dass beide Proxy-Server SPC und SPS die dargestellten Sicherheitsmerkmale aufweisen, wird nachfolgend ein einzelner Secure Proxy SP dargestellt. Bei diesem Secure Proxy kann es sich um einen oder mehrere der eingesetzten Proxy-Server handeln. Vorzugsweise weist wenigstens einer der Proxy-Server die nachfolgend genannten Merkmale des Secure Proxy auf, noch vorteilhafter ist es jedoch, dass mehrere, beziehungsweise alle Proxy-Server die Merkmale des Secure Proxy SP aufweisen.
Als Sicherheitsdienste werden im bevorzugten Fall von SSL- Verbindungen Authentisierung, Verschlüsselung und Integritätsprüfung zur Verfügung gestellt .
SSL bezeichnet Secure Sockets Layer. Hierbei handelt es sich insbesondere um eine auf TCP/IP basierende Schicht, über die die Verschlüsselung und Integrität von Daten und die gegenseitige Authentisierung der Kommunikationspartner gewährleistet wird.
Der SP wird vorzugsweise als ein Hintergrundprozess implementiert, der zweckmäßigerweise auch dann aktiv ist, wenn kein Anwender aktiv im System arbeitet. Ein solcher Hintergrundprozess kann verschiedene Funktionen wahrnehmen und entspricht in einer besonders zweckmäßigen Implementation dem sogenannten „Daemon" in dem Cömputersystem UNIX. ~~
Es ist möglich, den Aufbau der sicheren Verbindungen durch Softwareroutinen, die vorzugsweise in PSE realisiert sind, umzusetzen.
Ein Aufbau der sicheren Verbindungen über Smart Cards ist jedoch mit dem besonderen Vorteil einer noch höheren Sicherheit verbunden. Vorzugsweise sind die Smart Cards mit Sicherheitsmerkmalen ausgestattet. Eine Vielzahl derartiger Sicherheitsmerkmale ist bekannt und kann hier eingesetzt werden. Um eine besonders hohe Datensicherheit zu gewährleisten, ist es zweckmäßig, dass die Smart Cards entsprechend den Anforderungen des Signaturgesetzes gestaltet sind und daher auch als Signaturkarten dienen. Als Authentisierungsmechanismus dient das SSL-Handshake- Protokoll, bei dem auch ein Symmetrischer Schlüssel zum Ver- und Entschlüsseln der im Folgenden zwischen den beiden Kommunikationspartnern auszutauschenden Nutzdaten ausgehandelt wird.
Die Smart Cards können verschiedene Funktionen erfüllen, wobei zur Realisierung von unterschiedlichen Funktionalitäten ein Austausch der im Vergleich zu der Rechnerhardware einfach herzustellenden Smart Cards möglich sind. Vorteilhafterweise führen die Smart Cards Funktionen entsprechend dem SSL- Handshake-Protokoll durch. Hierbei ist es vorteilhaft, dass das SSL-Handshake-Protokoll beim Berechnen eines symmetrischen Schlüssels auf einen oder mehrere asymmetrische Schlüssel zurückgreift, die vorteilhafterweise auf den Smart Cards der Kommunikationspartner gespeichert sind.
Nachfolgend sind bevorzugte Eigenschaften des Client-Proxy dargestellt .
Der SP-Client wird unter Windows als Hintergrund-Prozess über den Autostart-Mechanismus beim Logon-Prozess und unter UNIX als Daemon-Prozess gestartet. Die zu überwachende PSE wird vom SP aus der Datei „comport .cfg" gelesen, die sich auf allen Plattformen im Installationsverzeichnis des Programms befindet. Im Falle der Windows-Versionen kann „comport .cfg" auch sogenannte „User-friendly names" enthalten.
Bei den User-friendly-names handelt es sich vorzugsweise um systemspezifische Zeichenketten, die eine Personal Security Environment (PSE) referenzieren.
Auf den UNIX-Pattformen wird der Benutzer sofort zur Eingabe der zur in „comport .cfg" spezifizierten PSE gehörenden PIN aufgefordert, unter Windows geschieht dies vorzugsweise erst beim Aufbau einer SSL-Verbindung.
Die PSE stellt einen digitalen Container für persönliche
Daten /z.B. Zertifikate, private Schlüssel) dar, der in Form von Software (sog. Soft-PSE) oder Hardware (Smart Card) realisiert ist.
Vorzugsweise wird eine Personal Identification Number
(PIN) eingesetzt . Diese Nummer sollte der Benutzer einer Smart Card eingeben, bevor er mit den auf der Smart Card gesichert gespeicherten Informationen arbeiten kann.
Die PIN behält ihre Gültigkeit für einen kurzen, vorzugsweise vorgegebenen Zeitraum von beispielsweise fünf Minuten nach dem letzten Datentransfer. Nach Verstreichen von fünf Minuten ohne Datentransfer löscht der SP Client die PIN aus Sicherheitsgründen aus dem Speicher, so dass bei erneutem Initialisieren eines SSL-Handshake-Protokoll-Prozesses die PIN neu eingegeben werden soll .
Nun liest der SP-Client die Datei „dient .cfg", die sich im selben Verzeichnis wie die Datei „comport .cfg" befindet und übernimmt deren aktuelle Einstellungen.
Beim Entfernen der Smart Card aus dem Terminal laufen alle über den SP-Client laufenden SSL-Verbindungen aus. Insbesondere werden keine neuen SSL-Verbindungen mehr vom SP angenommen. Unter UNIX beendet sich der SP-Client anschließend.
Im Rahmen des SSL-Handshake-Protokolls erhält der SP-Client auch ein Zertifikat vom Server, welches er bei einem Directory Service (DIR) prüfen lässt.
Das Zertifikat beinhaltet eine Zuordnung einer natürlichen Person zu einem Asymmetrischen Schlüssel . Auf der Smart Card ist das Zertifikat des Inhabers der Smart Card als Datei abgelegt .
Der Directory Service (DIR) ist vorzugsweise ein Verzeichnis- Dienst, der Auskunft gibt über die Gültigkeit von Zertifikaten.
Die Konfigurationsdateien können abhängig von den Befugnissen eines Benutzers verschiedene Einträge enthalten. Sie bestimmen maßgeblich das Verhalten des SP Client.
Im Installationsverzeichnis des Dienstes befindet sich die Datei, die nachfolgend beispielhaft als „comport .cfg", in der der bei der Installation ausgewählte PSE eingetragen ist; sie kann vom Systemadministrator mit Hilfe des
Konfigurationswerkzeuges des SP-Client bearbeitet werden. Vorzugsweise hat der Systemadministrator auf diese Datei Lese- und Schreibrechte.
Zweckmäßigerweise verfügen sowohl der Client als auch der Secure Proxy SP über die Datei „comport . cfg", welche (zumindest unter UNIX - siehe unten) während des Installationsvorgangs erstellt wird. Sowohl beim Client Proxy als auch beim Server Proxy enthält die Datei den zu verwendenden COM-Port. Sie beinhaltet vorzugsweise die nachfolgend wiedergegebenen Datenfelder. # COM Port für Karten-Terminal:
COM_PORT=l
USER_FRIENDLY_NAME="Ultimaco Cardman 0" USE
USER_FRIENDLY_NAME="XYZ"
USER_FRIENDLY_NAME="ABC"
Als COM-Port wird ein Integer angegeben, der die zu benutzende serielle Schnittstelle spezifiziert, über die ein angeschlossenes Karten-Terminal angesprochen werden soll.
Für viele UNIX-Betriebssysteme ist die Angabe von „COM_PORT" obligatorisch, da alle mit „COM_PORT" spezifizierten Slots direkt über ein Application Programming Interface (API) angesprochen (und deswegen auch exklusiv für den SP gelockt) werden.
Hierbei handelt es sich insbesondere um ein Card Terminal Application Programming Interface (CT-API) oder eine andere Programmier-Schnittstelle, über die der Karten-Leser, der eine Smart Card enthält, von Programmen aus angesprochen werden kann.
Andere Programme, beispielsweise der Windows-Programmfamilie, eröffnen die zusätzliche Möglichkeit der User-friendly names . Solchermaßen referenzierte PSEs werden vom Smart Card Resource Manager verwaltet, bei dessen Verwendung auch mehrere Applikationen mit der PSE arbeiten können. Mehrfach genutzte Karten-Leser sollten deswegen immer vom Secure Proxy über User-friendly names angesprochen werden. Unter den verschiedenen UNIX-Betriebssystemen gibt es keinen Smart Card Resource Manager, hier sollte das Card Terminal über „COM_Port" ausgewählt und über CT-API angesprochen werden.
Wegen der Verwendung von User-friendly names unter Windows wird die Datei „comport .cfg" hier nur eingeschränkt beim Installations-Vorgang erzeugt, da das Installationsprogramm die User-friendly names nur eingeschränkt kennen kann. Vielmehr erzeugt unter Windows der SP beim ersten Start die „comport . cfg" selbst.
Wie das obige Beispiel zeigt, kann die unter Windows durch den SP selbst generierte „comport . cfg"-Datei mehrere Einträge enthalten. Die vom SP zu verwendende PSE wird deswegen durch das Key Word „USE" gekennzeichnet. Wurde „comport .cfg" dabei unter Windows vom SP generiert, wählt der SP selbst eine PSE aus, sofern diese Wahl eindeutig ist. Er geht bei der Auswahl der PSE nach der folgenden Regel vor: Enthält „comport .cfg" nur einen Eintrag, so wird dieser ausgewählt. Enthält „comport .cfg" zwei Einträge, einer von beiden referenziert jedoch die Soft-PSE, so wird der andere Eintrag ausgewählt. Alle anderen möglichen Fälle ergeben ohne manuelle Nachkonfiguration mit dem Konfig-Tool eine unbestimmte Konfiguration des SP, und ein Start des SP mit der nur eingeschränkt-konfigurierten „comport .cfg" erzeugt eine Fehler-Meldung.
Im selben Verzeichnis wie „comport .cfg" befindet sich auch die Datei „dient .cfg", die vom Systemadministrator ebenfalls mit Hilfe des Konfigurationswerkzeuges des SP-Client bearbeitet werden kann. Die Datei „dient. cfg" beinhaltet die aktuellen Einstellungen für den SP-Client. Der Systemadministrator hat auf diese Datei Lese- und Schreibrechte . Ein Beispiel für die Datei „dient. cfg" ist nachfolgend wiedergegeben .
Figure imgf000024_0001
MAP URL=http: //www. alles . * TO 14.15.16.17:5678 MAP PORT=6666 INSECURE TO 18.19.20.21:6667 MAP PORT=80 SECURE TO server_sp .httpserver. com: 5080 MAP PORT=21 SECURE TO server_sp. ftpserver. com: 5021 MAP PORT=81 INSECURE TO REQUESTED URL HTTP
Die Darstellung zeigt Beispiele der eingesetzten Programmfunktionen in Scriptsprache. Die Datei „dient. cfg" ist vorzugsweise in einer derartigen Scriptsprache geschrieben. Diese Datei enthält vorzugsweise wenigstens eines der nachfolgenden Elemente, wobei ein Einsatz sämtlicher der nachfolgend dargestellten Elemente besonders bevorzugt ist.
Ein derartiges Element ermöglicht die Auswahl eines Secure Proxy Modus .
Um festzulegen, ob der Proxy im Rahmen eines Kommunikations- Rechners (KR) eingesetzt wird oder für andere Zwecke, wird hier die Variable „Mode" gesetzt. Diese kann einen der beiden Werte „KR" oder „NORMAL" enthalten.
Über den Kommunikations-Rechner (KR) werden Daten zwischen internen und externen Netzen der Zertifizierungsstelle ausgetauscht. Der Secure Proxy im KR-Modus bietet auf der Server-Seite Zusatzfunktionen wie zum Beispiel das Anfügen der Seriennummer des Client-Zertifikate als URL-parameter.
Ein weiteres Modul ist ein Service Port. Das Service Port wird vorzugsweise so spezifiziert, dass er den Port bezeichnet, auf dem der Secure Proxy Daten eines Konfigurationswerkzeuges, beispielsweise eines Konfigurationsproxys, empfängt. Vorzugsweise wird hierdurch auch der Übermittlungsweg festgelegt, auf dem das Konfigurationswerkzeug Daten an den Secure Proxy schickt. Vorzugsweise ist das Konfigurationswerkzeug der in Fig. 1 dargestellte Konfigurations-Proxy-Server KPl. Beispielsweise werden die Konfigurationsinformationen lokal gespeichert, wobei der Local Hoast in dem dargestellten Beispiel die IP- Adresse IP-Adresse 127.0.0.1 aufweist.
Eine weitere Datei enthält Zugriffsinformationen. Diese Datei wird auch als Log-Datei bezeichnet. Hierbei kann es sich selbstverständlich sowohl um eine selbständige Datei als auch um eine Unterdatei der Konfigurationsdatei handeln. Um auch außerhalb des EventLog Mechanismus bei Windows beziehungsweise des Syslog Mechanismus bei UNIX weitere Fehlermeldungen nach außen geben zu können, besteht hier mittels der Variablen „L0G_FILE" die Möglichkeit, eine Log- Datei anzugeben, in die Fehlermeldungen geschrieben werden können. Diese Datei dient zur Konfiguration des Gesamtsystems und zur Fehlersuche, zum Beispiel auf einer anvisierten Netzwerk-Route, und kann im normalen Betrieb ausgeschaltet werden durch „LOG_FILE=".
Ein weiteres Datenelement der Konfigurationsdatei ist eine Inaktivitätszeit . Der Variablen „INACT VITY TIME" wird mit dem Gleichheitsoperator „=" ein Wert in Sekunden zugeordnet. Jeder Online-Verbindung ist ein Timer Thread zugeordnet, der die Zeit misst, die seit dem letzten Datenverkehr verstrichen ist. Überschreitet diese Zeit die Inaktivitätszeit, so bricht der Client Proxy die Verbindung ab. Falls der Proxy im KR~ Modus arbeitet, wird dieser Wert ignoriert. Der Wert „0" bedeutet „keine Inaktivitätszeit".
Ferner ist es vorteilhaft, dass die Konfigurationsdatei eine Verzeichnisstruktur enthält, die auch als ein Verzeichnisdienst bezeichnet wird. Statt eines intern enthaltenen Verzeichnisdienstes ist jedoch ein Zugriff auf einen externen Verzeichnisdienst gleichermaßen möglich. Zur Verifikation von Zertifikaten wird vorzugsweise der Verzeichnisdienst von Signtrust genutzt. Dazu sollte vorzugsweise der Verzeichnis-Dienst von Signtrust im Format „<IP-Adresse> : <Port>" per Gleichheitsoperator „=" der Variablen „DIR" zugewiesen werden. "Der Client Proxy kann so das Zertifikat des Server Proxys, welches dieser im Rahmen des SSL-Handshake-Protokoll-Prozesses an den Client Proxy schickt, bei DIR prüfen.
Ferner ist es zweckmäßig, einen Zugriff auf eine weitere Speichereinheit zu ermöglichen. Eine bevorzugte
Ausfuhrungsform dieser Speichereinheit wird nachfolgend als Caching Proxy bezeichnet. Sind keine Informationen zur Absicherung einer Verbindung in der Datei dient. cfg spezifiziert, so leitet der Client SP die Informationen transparent weiter. In diesem Fall kann durch die Angabe eines Caching Proxies der Client SP veranlasst werden, diese Informationen an diesen weiterzuleiten. Hierzu sollte der Caching Proxy im Format „<IP-Adresse> :<Port>" per Gleichheitsoperator „=" der Veriablen „CACHING_PROXY" zugewiesen werden. Die Angabe dieser Information ist optional, da eventuell auch kein solcher Proxy vorhanden ist.
Es ist zweckmäßig, zwischen Zugriffsquellen zu unterscheiden, die abzusichern sind und solchen, bei denen eine Absicherung nur eingeschränkt erforderlich ist. Nachfolgend wird der
Verfahrensablauf für abzusichernde Resourcen dargestellt. Alle Zeichenketten, deren Anforderung zu einer gesicherten Übertragung führen sollen, werden per Zuweisungsoperator „=" einer Listenvariablen „SECURE_URL" hinzugefügt. Auch die Angabe von Wildcards (Verwendung von „*" für beliebige Ausdrücke beliebiger Länge und von „?" für beliebige einzelne Zeichen) ist möglich.
Bei der Zeichenkette handelt es sich vorzugsweise um einen Uniform Resource Locator (URL) , der eine in einem Datennetz, vorzugsweise im Internet zu suchende Resource in eindeutiger Weise beschreibt. Die Zeichenkette wird vom Browser in eine HTTP-Anfrage (HTTP-Reguest) eingebettet zum Server gesendet. In den HTTP-Reguest können sowohl auf Client- als auch auf Server-Seite Zusatzinformationen als sog. URL-Parameter eingefügt werden.
Der Ausdruck „SECURE_URL=http: //www. secure. com/" steht dabei für die Absicherung der Daten, die auf diesen Request zurückkommen, nur eingeschränkt jedoch für die Verschlüsselung aller auf diesem Web Server liegenden Seiten; dafür ist es notwendig, das Wildcard Zeichen „*" an die Zeile anzuhängen: „SECURE__URL=http : //www. secure . com/*" .
Ein bevorzugtes Protokoll ist das HyperText Transfer Protocol (HTTP) . Auf der Basis dieses Protokolls werden im Internet Daten transferiert, die vorzugsweise in einem Browser visualisiert werden.
Es ist zweckmäßig, verschiedene Daten- und
Dateiformatskonvertierungsroutinen einzusetzen, insbesondere Port- und URL-Mapping. Spezielle Ports und URLs können hierdurch komplett auf eine neue IP-Adresse und einen neuen
Port umgemappt werden. Dieses Feature ist beispielsweise für den telnet-Service interessant, bei dem kein Proxy angegeben werden kann. Stattdessen sollte man per telnet eine Verbindung zum Client Proxy aufnehmen, der den telnet-Port ummappt auf den Server Proxy der Remote Machine, auf der seinerseits ein Remapping des Ports vorgenommen wird auf den ursprünglich gewollten telnet-Peer. Oder, allgemein ausgedrückt: der SP verfügt über ein Port-Remapping, welches eine Umleitung eines Ports X der Client-Seite auf einen Port Y (und IP-Adresse Z) auf der Server-Seite ermöglicht. Hierzu existieren sowohl für den Client Proxy als auch für den Server Proxy je eine Datei, in der festgelegt ist, an welchen Ports der jeweilige Proxy auf eingehende Anfragen wartet. Die Datei „dient. cfg" enthält eine Liste aller Ports, an denen ein Client Proxy auf eingehende Anfragen wartet. Zunächst wird diese Liste verwendet, um für jeden angegebenen Port einen TCP/IP-Socket (mit lokaler IP-Adresse und angegebenem Port) zu eröffnen. Sofern in der Datei eine Zuordnung des jeweiligen Ports zu einer Zieladresse (IP-Adresse und Port) existiert, wird diese für das Port-Remapping verwendet. Der Client Proxy ist somit in der Lage, Anfragen an ein und dieselbe lokale IP-Adresse mit verschiedenen Ports auf Anfragen an verschiedene IP-Adressen abzubilden (Remapping) .
Ist keine Zuordnung vorhanden, erhält der Client Proxy die Zieladresse des Server Proxies aus der Angabe des Caching Proxy.
Für alle erwähnten Features sollte jedoch bei der jeweils verwendeten Client-Applikation (z.B. Browser, Telnet- Terminal) die Adresse des Client Proxies als Proxy eingetragen werden. Für den Fachmann ist es selbstverständlich, dass sowohl URLs als auch komplette Ports umgemapt werden können, insbesondere auf einen entfernten
Proxy Server, der im gewohnten Format „<IP-Adresse>:<Port>" angegeben werden sollte. Beim Mapping von URLs sind Wildcards möglich, wie sie auch bei der Absicherung bestimmter URLs verwendet werden können.
Ob für eine gemappte Verbindung eine Verschlüsselung stattfinden soll, hängt beim Mappen eines Ports beispielsweise vom Schlüsselwort „SECURE" oder „INSECURE" ab. Ist „SECURE" angegeben, so wird die Verbindung auf jeden Fall verschlüsselt. Ist „INSECURE" angegeben, so wird die Verbindung normalerweise nur eingeschränkt verschlüsselt. Ist jedoch weiterhin das Schlüsselwort „HTTP" angegeben, so wird versucht, die von der Benutzerapplikation geschickten Daten als HTTP-Anfragen zu deuten. Es wird die URL aus der Anfrage extrahiert; dann erfolgt ein Vergleich mit der „SECURE_URL" Liste. Findet sich die URL der Anfrage in dieser Liste, wird trotz der „INSECURE" Angabe bezüglich des Ports die Kommunikation verschlüsselt durchgeführt .
Ist statt eines Hostnamens und eines Ports das Schlüsselwort „REQUESTED_URL" angegeben, so sollte auch das Schlüsselwort „HTTP" vorhanden sowie der Port als „INSECURE" definiert sein. In diesem Fall werden die Daten, die an diesen Port gesendet werden, als HTTP-Request interpretiert, die URL aus diesem Reguest extrahiert und transparent an den Zielrechner weitergeleitet .
Falls eine sichere Verbindung zu einem Server bereits vorhanden ist, wird diese für den Datenaustausch vorzugsweise mehrfach verwendet .
Die Art der Verbindung kann dabei auf verschiedene Weise festgelegt werden.
Mit Hilfe des Konfigurationswerkzeuges kann der Benutzer eine Inaktivitätszeit angeben. Die Inaktivitätszeit wird im SP- Client Proxy durch einen Timer gemessen und als die Zeit definiert, die pro Online-Verbindung seit dem letzten Daten- Transfer zwischen SP-Client und Secure Proxy vergangen ist. Wird diese Zeitschwelle erreicht, wird die betreffende Online-Verbindung abgebrochen.
Im Falle des HTTP-Protokolls ist diese Inaktivitätszeit freilich von keinem besonderen Interesse, da beim HTTP- Datentransfer nur kurzfristig andauernde Verbindungen zustande kommen.
Beim Einsatz für den KR oder im KR-Modus wird diese Inaktivitätszeit nur eingeschränkt beachtet, da hier zum Einen ein einseitiger Verbindungsabbau durch den Secure Proxy ausreicht, um keine Verbindung zustande kommen zu lassen, und zum Anderen die Datei „dient, cfg" auf Client Seite nur eingeschränkt vor Manipulationen geschützt ist.
Mittels eines Satzes von Umgebungsvariablen (unter Windows von System-Variablen) kann der SP Client auf spezielle System-Gegebenheiten abgestimmt werden. Die folgende Übersicht zeigt die Möglichkeiten des Umgebungs-Tunings auf,
Figure imgf000031_0001
Figure imgf000032_0001
Nachfolgend wird eine bevorzugte Ausführungsform des Secure Proxies erläutert. In diesem besonders bevorzugten Fall wird ein spezieller Server in einem Rechner durch eine besondere Softwareroutine simuliert, so dass die erste Datenverarbeitungseinheit auch die Funktionen des Proxy- Servers erfüllt.
Der Secure Proxy wird beispielsweise unter Windows als Hintergrund-Prozess beim Logon-Prozess (durch den Autostart- Mechanismus) und unter UNIX als Daemon-Prozess im Hintergrund gestartet. Die vom Secure Proxy zu benutzende PSE wird vom Service aus der Datei „comport .cfg" gelesen, die sich im Installationsverzeichnis des Secure Proxys befindet.
Vorzugsweise fordert der Secure Proxy anschließend den Benutzer zur Eingabe der PIN auf, mit der die geschützten Resourcen der in der Datei „comport .cfg" spezifizierten PSE freigeschaltet werden können. Im Gegensatz zum SP Client wird beim Secure Proxy die PIN während der gesamten Laufzeit des Secure Proxy im Speicher gehalten.
Falls die Verifikation der eingegebenen PIN positiv verläuft - bei den Windows-Versionen wird dies erst beim ersten SSL- Handshake-Protokoll festgestellt -, aktiviert der Secure Proxy die Konfigurationsdaten aus der Datei „server.cfg" im Konfigurationsverzeichnis und übernimmt deren aktuelle Einstellungen.
Im Rahmen einer SSL-Authentisierungsphase erhält der Secure Proxy das Zertifikat vom Client, welches er bei DIR prüfen lässt .
Die Smart Card sollte dauerhaft im Karten-Leser verbleiben, da sonst der Secure Proxy nur eingeschränkt funktionsfähig ist. Beim Entfernen der Chipkarte aus dem Terminal beendet der Secure Proxy automatisch alle über ihn laufenden Aktionen. Insbesondere werden alle Online-Verbindungen abgebrochen. Der Secure Proxy sollte anschließend erneut gestartet werden: Es beginnt erneut eine Startphase mit PIN- Eingabe und -Verifikation, Zertifikatstest und Einlesen der Konfigurationsdatei „server.cfg" .
Auf jedem Rechner, der als Secure Proxy bei einer durch SSL abgesicherten Verbindung fungieren soll, sollte ein Secure
Proxy- Prozess im Hintergrund gestartet werden. Ein solcher Secure Proxy gleicht in seinem Aufbau dem SP-Client. Er erwartet Verbindungsanfragen von SP-Clients, führt die Authentisierung durch, empfängt die verschlüsselten Datenpakete, entpackt diese und leitet sie an die „regulären" Web-Server weiter. Ebenso werden die Antworten der Server an die entsprechenden SP-Clients weitergeleitet.
Der in Verbindung mit dem Secure Proxy verwendete Web-Server sollte so konfiguriert sein, dass nur Zugriffe vom
„localhost" (IP-Adresse: 127.0.0.1) möglich sind. Anderenfalls könnte der Mechanismus der sicheren Datenübertragung umgangen werden, in dem eine Client- Applikation (z.B. ein Browser) seine Anfrage direkt an den Web-Server richtet. Zusätzlich kann eine „Firewall" den entfernten Zugriff auf bestimmte Ports des Web-Servers verhindern.
Der Secure Proxy hat außer der Weiterleitung von Anfragen an den Web-Server und Weiterleitung der Antworten an den SP- Client auch die Überprüfung der Zugriffsrechte des Benutzers durchzuführen.
Beim Aufbau einer sicheren Verbindung erhält der Secure Proxy Informationen über den Benutzer des SP-Clients. Zur Überprüfung der Zugriffsrechte auf bestimmte URLs wird das bei der Authentisierung übertragene Zertifikat des Clients verwendet. Die Zertifikatsnummer sowie den Herausgeber des
Zertifikats vergleicht der Secure Proxy mit den in der Datei „access.cfg" abgelegten Daten.
Ist der Besitzer des entsprechenden Zertifikats zugriffsberechtigt, das heißt, das Paar Herausgeber und Zertifikatsnummer ist in der Datei „access.cfg" der angefragten URL zugeordnet, leitet der Secure Proxy die HTTP- Anfrage an den Web-Server weiter. Anderenfalls wird eine entsprechende Fehlermeldung generiert und an den SP-Client in Form eines HTTP-Dokuments versendet.
In Bezug auf die Datei „comport . cfg" besteht auf der Server- Seite kein Unterschied zur Client-Seite.
Nachfolgend ist dargestellt, wie der Inhalt einer
„Server. cfg"-Datei aussehen kann. Je nach Systemkonfiguration weichen die individuellen Dateiinhalte voneinander ab.
Figure imgf000035_0001
Jeder Server Proxy verfügt über eine Datei „server.cfg", welche dessen Basis-Konfiguration enthält. Die einzelnen Parameter werden nachfolgend näher erläutert : Die Datei „server.cfg" kann mit Hilfe der Konfigurations-Tools bearbeitet werden. Um festzulegen, ob der Proxy im Rahmen des KRs eingesetzt wird oder auch mit Soft-PSEs arbeiten soll, wird in dem Secure Proxy Modus die Variable „MODE" gesetzt. Diese kann einen der drei Werte „KR", „WITHSOFTPSE" oder „Normal" enthalten.
Der Unterschied zwischen dem „NORMAL"-Modus einerseits und den Modi „WITHSOFTPSE" und „KR" anderseits liegt zum einen im unterschiedlichen Format inkludierter Dateien und zum anderen in der Modifikation des HTTP-Reguests. Der „NORMAL"-Modus des Secure Proxy nimmt keine Modifikation des HTTP-Reguests vor, und die beiden anderen Modi hängen die Seriennummer des Zertifikats des Kommunikationspartners als URL-Parameter an den HTTP-Reguest an. Der „KR"-Modus allerdings nur, wenn der String „raclient" im HTTP-reguest gefunden werden kann, der „WITHSOFTPSE"-Modus hingegen modifiziert den HTTP_Reguest generell .
In einem Service Port wird festgelegt, auf welchem Weg Nachrichten von dem Konfigurationswerkzeug Nachrichten an den Proxy sendet. Vorzugsweise stammen diese Nachrichten von dem Localhost .
Um auch außerhalb des eventLog Mechanismus bei Windows, beziehungsweise des Syslog Mechanismus bei UNIX, weitere Fehlermeldungen nach außen geben zu können, besteht hier mittels der Variablen „LOG_FILE" die Möglichkeit, eine Log Datei anzugeben, in die Fehlermeldungen geschrieben werden können.
Der Variablen „IΝACTIVITY_TIME" wird mit dem Gleichheitsoperator „=" ein Wert im Format „Stunden:Minuten" zugeordnet. Gültige Werte für die Inaktivitätszeit können zwischen einer Minute (0:01) und einem Tag (24:00) liegen. Im Server Proxy wird pro gesicherter Verbindung zu einem Client Proxy ein Timer gestartet, welcher die Inaktivitätszeit bezüglich einer Verbindung misst. Die Inaktivitätszeit wird als die Zeit definiert, die seit dem letzten Reguest des zugehörigen Client Proxies vergangen ist. Nach Ablauf des festgelegten Wertes für die Inaktivitätszeit wird jede Verbindung abgebaut, über die keine Datenübertragung stattgefunden hat .
Falls der Proxy im KR-Modus arbeitet, wird dieser Wert ignoriert .
Zur Verifikation von Zertifikaten wird der Verzeichnis-Dienst von Signtrust genutzt. Dazu sollte der Verzeichnis-dienst von Signtrust im Format „<IP-Adresse>:<Port>" per Gleichheitsoperator „=" der Variable „DIR" zugewiesen werden. Der Server Proxy kann so das Zertifikat des Client Proxys, welches dieser im Rahmen des SSL-Handshake-Protokoll- Prozesses an den Server Proxy schickt, bei DIR prüfen.
Alle URLs, deren Anforderung zu einer gesicherten Übertragung führen sollen, werden per Zuweisungsoperator „=" einer Listenvariable „SECURE_URL" hinzugefügt. Auch die Angabe von Wildcards (Verwendung von „*" für beliebige Ausdrücke beliebiger Länge und von „?" für beliebige einzelne Zeichen) ist möglich.
Der Ausdruck ,,SECURE_URL=http: //www. secure. com/" steht dabei nur eingeschränkt für die Absicherung der Daten, die auf diesen Reguest zurückkommen, jedoch für die Verschlüsselung aller auf diesem Web Server liegenden Seiten; dafür ist es notwendig, das Wildcard Zeichen „*" an die Zeile anzuhängen: „SECURE_URL=http : //www. secure . com/*" .
Analog zu den abzusichernden URLs wird hier ein Umlenken sowie ein Absichern von Ports definiert. Ähnlich der Syntax in „dient. cfg" wird für ankommende Daten auf einem Port angegeben, ob sie „SECURE" (sicher) oder „INSECURE" (unsicher) sein sollen. Anders geartete Anfragen werden abgelehnt. Ist ein Port als „In-SECURE" definiert, so kann es sein, dass der Proxy die Verbindung ablehnt, obschon das Schlüsselwort „HTTP" gegeben und die URL der HTTP-Anfrage in der Liste der abzusichernden URLs zu finden ist.
Vorzugsweise verfügen die Proxy-Server über eine Datei „access.cfg", welche die Zugriffsrechte auf Web-Server- Inhalte verwaltet. Anhand der bei der Authentisierung übertragenen Zertifikate der Clients wird die Zugriffsberechtigung überprüft. Die Datei enthält eine Gruppierung aller gültigen und zugriffsberechtigten Paare aus Herausgebern und Zertifikatsnummern. Neue Zertifikate und Gruppen können mittels der Konfigurationstools hinzugefügt und anschließend den abzusichernden Web-Inhalten zugewiesen werde .
[ACCESS_CAS]
CA_1="CA-1" CA_2="CA-2" CA_3="CA-3"
[ACCESS_GROUPS]
CHEF ONLY=123456789:"CA-l" MINI_GROUP=543216789:CA_l/432156789:CA_l MAXI_GROUP=MINI_GROUP/987654321: CA__2/234567891:"CA-1" WILDCARD_GROUP_l=1234* : *
WILDCARD_GROUP_2=1234* : CA_l/5678???? : CA_2 WILDCARD_GROUP_3=1234???9 : CA_3 KR_GROUP=include /etc/man-db-acl FROM_FILE=include dynamic_group . cfg VIP_GROUP=ALL: CA_1
[URL]
# abzusichernde URLs
# in Gruppe PUBLIC sind alle user, die sich vorher mit einem
# gültigen Zertifikat authentisiert haben
URL=http : //www. Server. de/encrypted/users/chef/ALLOWED_TO
CHEF DNLY
URL=http: //www. server.de/encrypted/public/ALLOWED_TO PUBLIC
URL=http: //www. Server. de/encrypted/mini/ALLOWED_TO MINIJ3ROUP
URL=http : //www. Server. de/encrypted/mini/ALLOWED_TO MAXI_GROUP
URL=http : //www. from_file . de/*ALLOWED_TO FROM_FILE
URL=http: //www.vip.de/*ALLOWED_TO VIP_GR0UP
Sie einzelnen Parameter werden nachfolgend erläutert : Unter dem Abschnitt [ACCESS_CAS] werden symbolisch Cas (Certification Authorities) definiert. In diesen Ausdrücken sind auch Wildcards („*", „?") erlaubt.
Unter dem Abschnitt [ACCESS_GR0UPS] werden alle Gruppen aufgelistet. Eine Gruppe enthält eine Menge von Paaren, bestehend aus Zertifikatsnummer und Herausgeber (CA) , wobei auch Untergruppen erlaubt sind. Die einzelnen Paare sind durch den Separator „/" voneinander getrennt. Gruppennamen müssen zusammenhängend sein (keine Leerzeichen, Tabs) und dürfen nur eingeschränkt das Separatorzeichen enthalten. Neue Gruppen werden unter [ACCESS_GROUPS] eingefügt. Wie dargestellt, können bei der Spezifikation der Zertifikatsnummern auch Wildcards („*" für eine beliebige Anzahl beliebiger Zeichen und „?" für ein beliebiges Zeichen) benutzt werden. Bei der Angabe des Herausgebers kann sowohl einer der symbolischen Namen aus ACCESS_CAS verwendet werden als auch ein in Anführungszeichen gestellter normaler Name der CA.
Ein bevorzugter Verzeichnisdienst wird nachfolgend als CA dargestellt.
Für die Spezifikation aller Kunden einer CA kann auch das Key Word „ALL" verwendet werden. Das Statement
„ALL_OF_HERBERT=AL:Herbert" etwa definiert eine Gruppe „ALL_OF_HERBERT", die alle Kunden der CA „Herbert" meint.
Alternativ kann eine Gruppe auch durch den Inhalt einer Datei spezifiziert werden. Diese Datei sollte dann zeilenweise die Paare bestehend aus Zertifikatsnummer und CA Dname (in Anführungszeichen) , getrennt wie oben durch einen Doppelpunkt, enthalten. Diese Verfahrensweise macht es leichter, automatisch generierte Listen in die Überprüfung einzubinden. Hierzu wird das Schlüsselwort „include" verwendet . Die unkludierte Datei besteht aus einzelnen Zeilen der Form
<CertNr> : <Issuer Dname> : <Flag> : <Hashwert>
Bei einer bevorzugten Verschlüsselung, beziehungsweise bei einer bevorzugten nicht rückgängig machbaren Datenoperation, wird ein Hash-Wert gebildet. Die Hash-Wert-Bildung erfolgt durch ein mathematisches Verfahren, bei dem eine zu einem Datenstrom eindeutig zuordnende Zeichenkette berechnet wird. Ein Beispiel für ein Hash-Verfahren ist SHA1.
<CertNr> und <Issuer Dname> bezeichnen die Seriennummer und den Herausgeber des Zertifikats. <Flag> steht für eine Zahl, die „0" oder „1" sein kann. Dabei steht „0" für die Information, dass es sich bei dem spezifizierten Zertifikat um ein SigG-Zertifikat einer Smart Card handelt. Das Feld <Hashwert> inklusive des trennenden Doppelpunktes entfällt dann. Ist für <Flas> der Wert „1" angegeben, dann handelt es sich beim Eintrag um die Kennzeichen einer Soft-PSE, und das Feld <Hashwert> ist erforderlich und spezifiziert den Hash- Wert über den öffentlichen Schlüssel des Soft- PSE_Zertifikates. Der Hashwert ist dabei mittels SHA1 zu generieren und in der Base-64 kodierten Darstellung hier einzugeben. Beispiele:
12345678:"cn=DPAG CA1" Dieses Beispiel spezifiziert einen Teilnehmer im KR- oder Normal-Modus .
12345678 :"cn=DPAG CA1":0
Dieses Beispiel spezifiziert einen Teilnehmer im Soft-PSE- Modus, der ein SigG-Zertifikat besitzt.
12345678 : "cn=Hinz und Kunz" : 1 : abcdefghijklmnopgrst Dieses Beispiel spezifiziert einen Teilnehmer im Soft-PSE- Modus, der kein SigG-Zertifikat besitzt und via Hashwert identifiziert wird.
Unter dem Abschnitt [URL] werden alle URLs aufgelistet und der entsprechenden Gruppe zugeordnet. Nur Mitglieder dieser Gruppe sind berechtigt, auf die entsprechenden Web-Inhalte zuzugreifen. Neue URLs werden unter [URL] eingefügt.
Nachfolgend werden dynamisch sich ändernde Zugriffslisten auf der Server-Seite dargestellt.
Ein auf der Server-Seite oft vorkommendes Problem ist die Dynamik bei der Gruppe zugriffsberechtigter Personen auf eine bestimmte Resource (URL) . Da aber die Datei „access.cfg" nur einmal beim Start des SP Servers von diesem eingelesen wird, sind Modifikationen an dieser Datei erst nach einem Neustart des SP Server wirksam.
Die Möglichkeit, Zugriffe auf eine URL trotzdem ohne Secure Proxy-Neustart dynamisch zu ändern, bietet die Definition einer zugriffsberechtigten Gruppe über eine von „access.cfg" inkludierte Datei.
So wird etwa in der Sektion „ [ACCES_GROUPS] " von „access.cfg" aus obigem Beispiel die Gruppe „FROM_FILE=include dynamic_group.cfg" eingetragen, deren Mitglieder sich aus der Datei „dynamic_group.cfg" rekrutieren. Dieser Gruppe wird in der Sektion „[URL]" der Zugriff auf „www.from_file.de/*" gestattet. Bei jeder Zugriffskontrolle auf „www.from_file.de/*" prüft der SP Server, ob sich das
Modifikationsdatum der Datei „dynamic_group.cfg" geändert hat. Sollte dies der Fall sein, so wird vor Auswertung der Zugriffsrechte diese Datei vom Secure Proxy Server neu eingelesen und damit neu hinzugekommene Einträge neu berücksichtigt. Der SP Server sollte allerdings nur eingeschränkt neu gestartet werden.
Ferner ist es zweckmäßig, auf der Seite der zweiten Datenverarbeitungseinheit, insbesondere falls diese Informationen über Web-Seiten überträgt, VIP-Bereiche einzurichten.
Speziell zum Einrichten von VIP-Bereichen - also Resourcen, die ausschließlich den Kunden einer bestimmten CA zugänglich sein sollen - wurde das Key Word „ALL" eingeführt.
So wird etwa in der Sektion „ [ACCESS__GROUPS] " von „access.cfg" aus obigem Beispiel die Gruppe ,NIP_GROUP=ALL : CA_! " eingeführt, die alle Kunden der CA „CA_1" meint. In der „ [URL] "-Sektion wird die URL www.vip.de/* genau diesen Kunden der „CA_1" ausschließlich zugänglich gemacht.
Mit Hilfe des Konfigurationswerkzeuges kann der Benutzer
(hier: Server-Administrator) in der Datei „server.cfg" eine Inaktivitätszeit angeben. Im Secure Proxy wird pro gesicherter Verbindung zu einem SP-Client ein Timer gestartet, welcher die Inaktivitätszeit bezüglich der festgelegten Gültigkeitsdauer misst. Die Inaktivitätszeit wird als die Zeit definiert, die seit dem letzten Datentransfer zum zugehörigen SP-Client vergangen ist.
Bei Überschreitung der Inaktivitätszeit wird die sichere Verbindung zum entsprechenden SP-Client unterbrochen. Erfolgt jedoch innerhalb der Inaktivitätszeit eine neue Anfrage an den Server Proxy, so wird der Timer zurückgesetzt und dieser beginnt erneut mit seiner Zeitmessung.
Nach dem Abbruch einer speziellen Verbindung wird bei einer erneuten Anfrage durch den entsprechenden Client eine neue - falls entsprechend konfiguriert - durch SSL gesicherte Verbindung aufgebaut. Da die PIN beim Server Proxy dauerhaft gespeichert wird, muss diese nicht bei dem nun erforderlichen SSL-Handshake-Protokoll erneut eingegeben werden.
An dieser Stelle wird eine Gesamtübersicht über die Parameterisierung der Laufzeitumgebung des SP Server gegeben.
Mittels eines Satzes von Umgebungsvariablen (unter Windows NT von System-Variablen) kann der SP Server auf spezielle System-Gegebenheiten abgestimmt werden. Die folgende Übersicht zeigt die Möglichkeiten des Umgebungs-Tunings auf.
Die Installation der Softwaremodule wird unter Windows durch das Setup-Programm „InstallShield" und unter UNIX durch die betriebssystemspezifischen Package Handler realisiert und verläuft weitestgehend automatisch.
Durch Anklicken des Progra mes setup.exe wird der Installationsvorgang gestartet.
Nach der Bestätigung des Begrüßungsdialoges durch die Schaltfläche „weiter" gelangt man zum Auswahldialog für den Zielordner der Installation. Ohne explizite Auswahl eines Ordners, erfolgt die Installation in das Verzeichnis c:\Programme\DPAG Secure Proxy\SQRP\.
In einem Abschlussdialog hat der Benutzer die Möglichkeit zu entscheiden, ob ein Neustart nach dieser Installation erfolgen soll oder nicht. Wird ein Neustart ausgelöst, so wird dabei der SP automatisch als Hintergrundprozess gestartet.
Wird beim Abschlussdialog kein Neustart gewünscht, so kann der Anwender den SP jederzeit manuell starten.
Die Installation erfolgt bei HP-UX über den HP-UX eigenen Software Depot Installer swinstall.
Eine Installation ist durch einen speziellen Installer, beispielsweise einen HP-UX Installer möglich. Hierbei werden Konfigurationsdateien in einem Inhaltsverzeichnis konfiguriert und ein SQRP installiert.
Die Installation erfolgt bei Computern des Typs Sun-Solaris über den Solaris eigenen Software Package Installer. Dieser wird mit folgendem Befehl aufgerufen: pkgadd -d. -a noask /cdrom/cdromθ/SQRP_Server- 1.0. i86pc . Solaris .2.7
Der Fachmann weiß, wie er die dazu erforderlichen Schritte, beispielsweise mit einem Einloggen als root-user durchführt.
Bei Einsatz als Hintergrund-Prozess unter Windows wird durch die Installation mit InstallShield der Secure Proxy unter • Windows als automatisch beim Systemstart startender Hintergrund-Prozess eingerichtet .
Sollte der SP aus irgendeinem Grund beendet worden sein, so kann er jederzeit über den Start-Button von Windows (Start - Programme) manuell gestartet werden.
Unter Windows ist es möglich, den SP so zu konfigurieren, dass er den Windows Smart Card Resource Manager benutzt. Ansprechbare Card Terminals werden dann als User-friendly names spezifiziert. Um diese User-friendly names kennenzulernen, kann der SP-Client unter Windows zunächst ohne die Datei „comport .cfg" gestartet werden. Er schreibt diese Datei, die nun alle User-friendly names enthält, die das System bereitstellt, dann in sein Installationsverzeichnis und beendet sich.
Bei einem Einsatz als Windows-Hintergrundprogramm kann der Secure Proxy über ein geeignetes Menü, insbesondere ein kontext-sensitives Menü, starten.
Bei Einsatz als Daemon-Prozess unter UNIX wird im Installations-Verzeichnis des Secure Proxy das ausführbare Programm „SQRP" abgelegt.
Ein Νeustart des Secure Proxies ist auch hier jederzeit möglich.
Nachfolgend werden geeignete Benutzerschnittstellen erläutert.
Das Erstellen und Bearbeiten der Konfigurationsdateien der Benutzerschnittstellen ist kein notwendiger Bestandteil der eigentlichen SP-Applikation, sondern wird beispielsweise mit dem in [SP_CfgDoc] dokumentierten Konfigurationswerkzeug durchgeführt.
Um die Datensicherheit zu erhöhen, enthält der Proxy Server möglichst wenige direkte Benutzerschnittstellen. Eine mögliche Benutzerschnittstelle ist ein Eingabedialog für einen geeigneten Code, insbesondere eine PIN. Die
Schnittstelle dient zu der Eingabe der PIN für die verwendete Chipkarte, mit der sich der Benutzer identifiziert. Ohne erfolgreiche PIN-Eingabe wird der Secure Proxy beendet, beziehungsweise nur eingeschränkt gestartet.
War die eingegebene PIN korrekt, so wird dies in der Mitteilungszeile des Dialoges für ca. eine Sekunde bestätigt, bevor der Dialog geschlossen wird und der SP in den „normalen" Betriebszustand eintritt.
Konnte die eingegebene PIN nur eingeschränkt bestätigt werden, so wird eine entsprechende Meldung in der Mitteilungszeile des Dialoges ausgegeben mit der Aufforderung, die PIN-Eingabe zu wiederholen. Die Schaltfläche „ok" wird deaktiviert und wird erst wieder aktiviert, wenn eine PIN eingegeben wird.
Wurde für die aktuell verwendete Chipkarte mehrmals, beispielsweise zum dritten Mal eine falsche PIN eingegeben, so erscheint eine Meldung, dass die Anzahl der maximalen Fehlversuche erreicht wurde. Die Karte ist nun gesperrt und kann nur noch eingeschränkt verwendet werden.
Nachfolgend wird erläutert, wie der Secure Proxy rekonfiguriert wird. In dem dargestellten Beispiel erfolgt die Rekonfiguration des Secure Proxy durch einen Neustart. Dies ist besonders zweckmäßig, jedoch nicht notwendig.
Mit dem Konfigurationswerkzeug werden lediglich die in den Konfigurationsdateien gespeicherten Informationen eingegeben, beziehungsweise gewartet.
Das Einlesen dieser Konfigurationsinformationen erfolgt durch den Secure Proxy selbst. Dies geschieht entweder beim Start des SP oder kann durch Auswahl der Schaltfläche „Proxy rekonfigurieren" im Hauptmenü des Konfigurationswerkzeuges erzwungen werden. Der SP führt daraufhin einen kompletten Neustart durch, das heißt, alle Verbindungen werden zunächst beendet, anschließend verhält sich der SP wie beim Programmstart: Der PIN-Eingabedialog wird angezeigt. Nach Eingabe der korrekten PIN wird der Secure Proxy mit den nun aktuellen Konfigurationsinformationen gestartet.
Nach erfolgreicher Installation und erfolgreichem Start des SP geht dieser in seinen Wirkbetrieb über. Der SP läuft in seinem Wirkbetrieb autark.
Schwere Fehler führen zum Beenden des SP, da ansonsten die
Sicherheitsfunktionalitäten bedroht sein können. Da der SP im reinen Wirkbetrieb (Proxy-Betrieb) keine Benutzerinteraktion vorsieht, werden die Fehlermeldungen nur protokolliert, aber nur eingeschränkt unmittelbar angezeigt. Eine Ausnahme bilden hier Fehlermeldungen, die dem Benutzer als HTML-Seite angezeigt werden, wenn dieser versucht hat, mit einem WebBrowser (Netscape Communicator, beziehungsweise Microsoft Explorer) eine URL auszuwählen, die für ihn in der Zugriffsliste des Secure Proxys („access.cfg") nur eingeschränkt eingetragen ist, das heißt, für die er keine Berechtigung hat. In einem solchen Fall sendet der Secure Proxy eine Fehlermeldung als HTML-Seite an den SP-Client, die den Benutzer darüber informiert, dass der Zugriff verweigert wurde.
Bei mehreren Betriebssystemen, insbesondere bei Windows NT werden die Meldungen des SP im sogenannten Ereignisprotokoll verzeichnet. Über die folgenden Menüeinträge der Windows-NT Task-Leiste gelangt man zur Anzeige des Ereignisprotokolls: Start - Programme - Verwaltung (Allgemein) - Ereignisanzeige
Die Einträge des SP werden in der Kategorie Anwendungsprotokoll eingetragen. Die Einträge ihrerseits können Fehlermeldung, Warnungen und Informationsmeldungen darstellen.
Unter den UNIX-Betriebssystemen (Solaris, HP-UX, Linus) wurde die Protokollierung von Fehlermeldungen des SP durch Aufruf des Systembefehles „syslogO" realisiert. Die diesem Befehl übergebenen Meldungstexte werden vom Betriebssystem in die sogenannte Syslog-Datei geschrieben. Diese befindet sich beispielsweise bei Solaris im Verzeichnis (var/log/ und bei HP-UX im Verzeichnis /var/adm/syslog/ .
Um Meldungen des SP, die in diese Datei geschrieben wurden zu betrachten, wird das Kommando „tail" in einer Shell verwendet . Die dabei erforderlichen Kommandoparameter sind in der nachfolgenden Tabelle aufgelistet :
Figure imgf000050_0001

Claims

Patentansprüche :
1. Verfahren zur Übertragung von Daten zwischen einer ersten Datenverarbeitungseinheit (C) und einer zweiten
Datenverarbeitungseinheit (S), d a d u r c h g e k e n n z e i c h n e t , dass die Übertragung über mindestens einen zwischengeschalteten Proxy-Server (SPC; SPS) erfolgt, wobei der Proxy-Server Signaturinformationen erfasst, die Signaturinformationen mit wenigstens einem Teil der Daten verknüpft und hierdurch die Daten beglaubigt und/oder verschlüsselt.
2. Verfahren nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t , dass die
Signaturinformationen einem digitalen Signaturschlüssel entsprechen.
3. Verfahren nach einem oder beiden der Ansprüche 1 oder 2 , d a d u r c h g e k e n n z e i c h n e t, dass der
Proxy-Server die SignaturInformationen von einer Smart- Card (SCI; SC2) liest.
4. • Verfahren nach einem oder mehreren der vorangegangenen Ansprüche, d.a du r c h g e k e n n z e i c h n e t, dass der Proxy-Server (SP; SPC) , der die Daten durch Verknüpfung mit der SignaturInformation authentisiert und/oder verschlüsselt, die verschlüsselten Daten an einen Authentisierungsserver (AS) übermittelt.
Verfahren nach einem oder mehreren der vorangegangenen Ansprüche, d a d u r c h g e k e n n z e i c h n e t , dass ein weiterer Proxy-Server (SPS) , der mit der Signaturinformation authentisierte und/oder verschlüsselte Daten empfängt, die verschlüsselten und/oder authentisierten Daten an den Authentisierungs- Server (AS) überträgt.
6. Verfahren nach einem oder beiden der Ansprüche 4 oder 5, d a d u r c h g e k e n n z e i c h n e t , dass der Authentisierungs-Server eine Authentisierungsinformation an den Proxy-Server (SP; SPC) sendet, der unter Einsatz der Signaturinformation die Daten verschlüsselt und/oder authentisiert .
7. Verfahren nach einem oder mehreren der Ansprüche 4 bis 6, d a d u r c h g e k e n n z e i c h n e t , dass der Authentisierungs-Server die Authentisierungsinformation an den weiteren Server (SP; SPS) sendet, der die mit der SignaturInformation verschlüsselten und/oder authentisierten Daten empfängt.
8. Verfahren nach einem oder mehreren der vorangegangenen
Ansprüche, d a du r c h g e k e n n z e i c h n e t , dass ein Aufbau einer sicheren Datenverbindung mittels eines Authentisierungsmechanismus eingeleitet wird.
9. Verfahren nach Anspruch 8, d a d u r c h g e k e n n z e i c h n e t, dass ein Secure Sockets Layer - Handshake-Protokoll als Authentisierungsmechanismus dient .
10. Verfahren nach einem oder mehreren der vorangegangenen Ansprüche, d a du r c h g e k e n n z e i c h n e t, dass der Proxy-Server (SPC) von der ersten Datenverarbeitungseinheit (C) als ein virtueller Rechner simuliert wird.
11. Verfahren nach einem oder mehreren der vorangegangenen Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass der Proxy-Server (SPS) durch die zweite
Datenverarbeitungseinheit (S) als ein virtueller Rechner simuliert wird.
12. Verfahren nach einem oder beiden der Ansprüche 11 oder 12, d a d u r c h g e k e n n z e i c h n e t, dass der Proxy-Server (SPC; SPS) in einem geschützten Bereich der Datenverarbeitungseinheit (C; S) betrieben wird.
13. Proxy-Server mit einem Eingang zum Empfang von Daten von einer ersten Datenverarbeitungseinheit (C) und zur
Übertragung der Daten an eine zweite
Datenverarbeitungseinheit (S), d a d u r c h g e k e n n z e i c h n e t, dass der Proxy-Server eine Signaturinformation einliest, mit der Signaturinformation die Daten verschlüsselt und/oder authentisiert und die verschlüsselten und/oder authentisierten Daten an die zweite Datenverarbeitungseinheit (S) übermittelt.
14. Datenübertragungssystem zur Übertragung von Daten zwischen einer ersten Datenverarbeitungseinheit (C) und einer zweiten Datenverarbeitungseinheit (S) , d a d u r c h g e k e n n z e i c h n e t , dass die erste Datenverarbeitungseinheit (C) mit einem ersten Proxy-Server (SPC) verbunden ist, dass die zweite Datenverarbeitungseinheit (S) mit einem weiteren Proxy-
Server (SPS) verbunden ist, dass der erste Proxy-Server (SPC) mit Mitteln zum Verschlüsseln und/oder Authentisieren von Daten versehen ist, dass der weitere Proxy-Server (SPS) mit Mitteln zum Verschlüsseln und/oder Authentisieren von Daten versehen ist, und dass zwischen dem ersten Proxy-Server (SPC) und dem weiteren Proxy- Server (SPS) verschlüsselte und/oder authentisierte Daten übertragen werden.
15. Datenübertragungssystem, nach Anspruch 14, d a d u r c h g e k e n n z e i c h n e t , dass wenigstens einzelne Daten durch einen Authentisierungs-Server beglaubigt werden.
PCT/DE2002/000587 2001-02-19 2002-02-19 Verfahren zur übertragung von daten, proxy-server und datenübertragungssystem WO2002067532A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE2001107883 DE10107883B4 (de) 2001-02-19 2001-02-19 Verfahren zur Übertragung von Daten, Proxy-Server und Datenübertragungssystem
DE10107883.8 2001-02-19

Publications (1)

Publication Number Publication Date
WO2002067532A1 true WO2002067532A1 (de) 2002-08-29

Family

ID=7674688

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2002/000587 WO2002067532A1 (de) 2001-02-19 2002-02-19 Verfahren zur übertragung von daten, proxy-server und datenübertragungssystem

Country Status (2)

Country Link
DE (1) DE10107883B4 (de)
WO (1) WO2002067532A1 (de)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3681095A4 (de) * 2017-09-08 2021-04-28 Kabushiki Kaisha Toshiba Kommunikationssteuerungssystem und kommunikationssteuerungsvorrichtung
US20210400484A1 (en) * 2019-03-04 2021-12-23 Kabushiki Kaisha Toshiba Communication system
EP3917071A4 (de) * 2019-03-04 2022-10-12 Kabushiki Kaisha Toshiba Kommunikationssteuerungsvorrichtung und kommunikationssystem
EP3917072A4 (de) * 2019-03-04 2022-10-12 Kabushiki Kaisha Toshiba Kommunikationssteuerungsvorrichtung und kommunikationssystem
EP3913851A4 (de) * 2019-03-04 2022-10-12 Kabushiki Kaisha Toshiba Kommunikationssteuerungsvorrichtung und kommunikationssystem

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10305413B4 (de) 2003-02-06 2006-04-20 Innominate Security Technologies Ag Verfahren und Anordnung zur transparenten Vermittlung des Datenverkehrs zwischen Datenverarbeitungseinrichtungen sowie ein entsprechendes Computerprogramm und ein entsprechendes computerlesbares Speichermedium

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997015885A1 (en) * 1995-10-25 1997-05-01 Open Market, Inc. Managing transfers of information in a communications network
WO2001007979A2 (en) * 1999-07-21 2001-02-01 Sun Microsystems, Inc. Application firewall

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6003084A (en) * 1996-09-13 1999-12-14 Secure Computing Corporation Secure network proxy for connecting entities
US5983350A (en) * 1996-09-18 1999-11-09 Secure Computing Corporation Secure firewall supporting different levels of authentication based on address or encryption status
US6101543A (en) * 1996-10-25 2000-08-08 Digital Equipment Corporation Pseudo network adapter for frame capture, encapsulation and encryption
US6173399B1 (en) * 1997-06-12 2001-01-09 Vpnet Technologies, Inc. Apparatus for implementing virtual private networks
WO1999066384A2 (en) * 1998-06-17 1999-12-23 Sun Microsystems, Inc. Method and apparatus for authenticated secure access to computer networks

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997015885A1 (en) * 1995-10-25 1997-05-01 Open Market, Inc. Managing transfers of information in a communications network
WO2001007979A2 (en) * 1999-07-21 2001-02-01 Sun Microsystems, Inc. Application firewall

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DEUTCHE TELECOM AG: "Das TeleSec LineCrypt L für sichere Netzwerkverbindungen", LINECRYPT L BENUTZERHANDBUCH, 14 April 2000 (2000-04-14), XP002207127 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3681095A4 (de) * 2017-09-08 2021-04-28 Kabushiki Kaisha Toshiba Kommunikationssteuerungssystem und kommunikationssteuerungsvorrichtung
US11431706B2 (en) 2017-09-08 2022-08-30 Kabushiki Kaisha Toshiba Communication control system and communication control device
US20210400484A1 (en) * 2019-03-04 2021-12-23 Kabushiki Kaisha Toshiba Communication system
EP3917071A4 (de) * 2019-03-04 2022-10-12 Kabushiki Kaisha Toshiba Kommunikationssteuerungsvorrichtung und kommunikationssystem
EP3917072A4 (de) * 2019-03-04 2022-10-12 Kabushiki Kaisha Toshiba Kommunikationssteuerungsvorrichtung und kommunikationssystem
EP3913851A4 (de) * 2019-03-04 2022-10-12 Kabushiki Kaisha Toshiba Kommunikationssteuerungsvorrichtung und kommunikationssystem

Also Published As

Publication number Publication date
DE10107883B4 (de) 2006-02-09
DE10107883A1 (de) 2002-08-29

Similar Documents

Publication Publication Date Title
DE69830726T2 (de) Verfahren zum betrieb eines systems von authentifizierungsservern sowie ein solches system
DE60114986T2 (de) Verfahren zur herausgabe einer elektronischen identität
DE60220665T3 (de) Verfahren und system für den aufbau einer verbindung zwischen einem personal security device und einem fernrechnersystem
DE69835416T2 (de) Verfahren zur sicheren ausführung eines fernmeldebefehls
DE69932003T2 (de) System und Verfahren zur Kontrolle einer Netzwerkverbindung
DE60200451T2 (de) Herstellung einer gesicherten Verbindung mit einem privaten Unternehmensnetz über ein öffentliches Netz
DE60121483T2 (de) Sicherheitkommunikationsverfahren, System und Vorrichtung welche erlauben den Sicherheitstyp zu wechseln
EP1777907B1 (de) Vorrichtungen und Verfahren zum Durchführen von kryptographischen Operationen in einem Server-Client-Rechnernetzwerksystem
DE60217962T2 (de) Benutzerauthentisierung quer durch die Kommunikationssitzungen
DE60200093T2 (de) Sichere Benutzerauthenifizierung über ein Kommunikationsnetzwerk
DE60319791T2 (de) Verfahren und Vorrichtung für den Zugang eines Computers zu einem Kommunikationsnetzwerk
DE60221113T3 (de) Verfahren und system für die fernaktivierung und -verwaltung von personal security devices
DE19741239C2 (de) Verallgemeinertes Sicherheitspolitik-Management-System und Verfahren
DE10392208T5 (de) Mechanismus zum Unterstützten drahtgebundener und drahtloser Verfahren für eine client- und serverseitige Authentifizierung
DE10212620A1 (de) Sichere Benutzer- und Datenauthentisierung über ein Kommunikationsnetzwerk
DE69925482T2 (de) Verfahren, einrichtung und gerät zur authentifizierung
DE112011102224T5 (de) Identitätsvermittlung zwischen Client- und Server-Anwendungen
EP3970337A1 (de) Verfahren zum selektiven ausführen eines containers und netzwerkanordnung
DE60319985T2 (de) Verfahren zur selbst-registrierung und automatischen ausgabe von digitalen zertifikaten und entsprechendes netz
DE10147889A1 (de) Proxy-Einheit, Verfahren zum rechnergestützten Schützen eines Applikations-Server-Programms und Anordnung mit einer Proxy-Einheit und einer Einheit zum Ausführen eines Applikations-Server-Programms
DE10107883B4 (de) Verfahren zur Übertragung von Daten, Proxy-Server und Datenübertragungssystem
DE60219915T2 (de) Verfahren zur Sicherung von Kommunikationen in einem Computersystem
DE60310872T2 (de) Verfahren zur Verwaltung einer Einstellung eines Gateways von einem Benutzer des Gateways
DE19645006B4 (de) Verfahren zur Kommunikation zwischen Prozessen
DE60031004T2 (de) Elektronisches sicherheitssystem und verfahren für ein kommunikationsnetz

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP