System and method for securing a non-secure communication channel
Abstract
The present invention features systems and methods for establishing a secure communication channel between a client and an application server. In one embodiment, the ticket service generates a ticket with an identifier and a session key. The communication device obtains the ticket from the ticket service and transmits the ticket to the client via a secure communication channel. The client transmits the ticket identifier to the application server via the application communication channel. The application server then obtains a copy of the ticket session key from the ticket service. The communication exchanged between the client and the application server over the application communication channel is then encrypted using the session key to establish the application communication channel as a secure communication channel.
Term
Term ended
Projected expiry passed 2 November 2021, 4.9 years ago.
- Priority
- Filed
- Published
- Projected expiry
- Today
33 claims: 6 independent, 27 dependent
- 1クライアントとアプリケーションサーバとの間の安全な通信チャネルを確立するための方法であって、識別子およびノンヌル(non-null)価値セッション鍵を有するチケットをチケットサービスによって、生成するステップと、該チケットサービスから、該チケットを取得するステップと、安全な通信チャネルを介して、クライアントに該チケットを伝送するステップと、アプリケーション通信チャネルを介して、該クライアントによって該チケットの該識別子をアプリケーションサーバに伝送するステップと、該チケットサービスからの該チケットの該ノンヌル価値セッション鍵のコピーを該アプリケーションサーバによって取得するステップと、該アプリケーション通信チャネルを安全な通信チャネルとして、確立するために該ノンヌル価値セッション鍵を使用して、該アプリケーション通信チャネルを介して該クライアントと該アプリケーションサーバとのやりとりを行う通信を暗号化するステップとを包含する、方法。
- 2前記チケットサービスから前記チケットを取得するステップは、該チケットをウェブサーバに伝送するステップをさらに包含する、請求項1に記載の方法。
- 3前記チケットをクライアントに伝送するステップは、前記ウェブサーバによって該チケットを伝送するステップを含む、請求項2に記載の方法。
- 4前記チケットサービスは、前記ウェブサーバ上に常駐する、請求項2に記載の方法。
- 5前記アプリケーションサーバによって、前記識別子をサーバ通信チャネルを介して前記ウェブサーバに伝送するステップをさらに包含する、請求項2に記載の方法。
- 6前記識別子を前記ウェブサーバに前記伝送するステップの応答を、アプリケーションサーバによって受け取るステップをさらに包含する請求項5に記載の方法。
- 7前記アプリケーションサーバによって伝送された前記識別子を前記ウェブサーバによって確証するステップをさらに包含する、請求項5に記載の方法。
- 8前記確証するステップは、前記識別子が、前記ウェブサーバによって前記クライアントに伝送された時間に関連する特定の時間フレーム内で受け取られることを該ウェブサーバによって確認するステップをさらに包含する、請求項7に記載の方法。
- 9クライアントとアプリケーションサーバとの間の安全な通信チャネルを確立するための方法であって、該クライアント上で実行するウェブブラウザとウェブサーバとの間に安全なウェブ通信チャネルを確立するステップと、該安全なウェブ通信チャネルを介し、該ウェブサーバから識別子およびノンヌル価値セッション鍵を有するチケットを受け取るステップと、該ノンヌル価値セッション鍵のコピーを取得するために情報を該アプリケーションサーバに供給するアプリケーション通信チャネルを介して、該アプリケーションサーバに該チケットの該識別子を伝送するステップとを包含する方法。
- 10クライアントとアプリケーションサーバとの間の安全な通信チャネルを確立するための方法であって、安全なウェブ通信チャネルを介して、識別子とノンヌル価値セッション鍵を有するチケットを受け取るステップと、該ノンヌル価値セッション鍵のコピーを取得するための情報を該アプリケーションサーバに提供するために、アプリケーション通信チャネルを介して、該チケットの該識別子を該アプリケーションサーバに伝送するステップと、該アプリケーション通信チャネルを安全な通信チャネルとして確立するために、該安全なウェブ通信チャネルを介して受け取られた該ノンナル価値セッション鍵を使用して、該アプリケーション通信チャネルを介して該アプリケーションサーバに伝送されるおよび該アプリケーションサーバから受け取られる通信を暗号化および復号化するステップとを包含する、方法。
- 11前記安全なウェブ通信チャネルを介して、ソフトウェアアプリケーションを要求するステップをさらに包含する、請求項10に記載の方法。
- 12前記識別子はナンスである、請求項10に記載の方法。
- 13前記安全なウェブ通信チャネルを確立するために、安全なソケット層技術を使用するステップをさらに包含する、請求項10に記載の方法。
- 14前記チケットは、チケットサービスによって生成される、請求項10に記載の方法。
- 15前記識別子は、アプリケーションサーバ電子署名である、請求項10に記載の方法。
- 16前記アプリケーション通信チャネルを確立するために、安全なソケットレイヤー技術を使用するステップをさらに包含する、請求項15に記載の方法。
- 17パスワードを前記アプリケーションサーバに伝送するステップをさらに包含する、請求項10に記載の方法。
- 18前記ウェブ通信チャネルを介して、前記チケットおよびリモートディスプレイプロトコルアプリケーションを受け取るステップをさらに包含する、請求項10に記載の方法。
- 19安全な通信チャネルを確立するための通信システムであって、識別子およびノンヌル価値セッション鍵を有するチケットを生成するチケットサービスと、該チケットサービスから該チケットを取得するために、該チケットサービスと通信する通信デバイスと、該安全な通信チャネルを介して該通信デバイスから該チケットを受け取るために、安全な通信チャネルを介して該通信デバイスと通信するクライアントと、該クライアントから該チケットの該識別子を受け取るためにアプリケーション通信チャネルを介して該クライアントと通信し、および該チケットサービスから該ノンヌル価値セッション鍵のコピーを取得するために該チケットサービスと通信するアプリケーションサーバであって、該アプリケーションサーバおよび該クライアントは、該アプリケーション通信チャネルを安全な通信チャネルとして確立するために該ノンヌル価値セッション鍵を使用して、該アプリケーション通信チャネルを介して、暗号化された通信のやり取りを行うアプリケーションサーバとを含む、通信システム。
- 20前記チケットサービスは、前記通信デバイス上に常駐する、請求項19に記載のシステム。
- 21サーバ通信チャネルを介して、前記識別子を前記通信デバイスに伝送する前記アプリケーションサーバをさらに含む、請求項20に記載のシステム。
- 22前記識別子に応答して、前記ノンヌル価値セッション鍵のコピーをを要求する前記アプリケーションサーバをさらに含む、請求項21に記載のシステム。
- 23前記アプリケーションサーバによって伝送される前記識別子を確証する前記通信デバイスをさらに含む、請求項22に記載のシステム。
- 24確証する前記通信デバイスは、前記識別子が以前に前記アプリケーションサーバによって伝送されてなかったことを確認する前記通信デバイスをさらに含む、請求項23に記載のシステム。
- 25確証する前記通信デバイスは、前記識別子が、前記通信デバイスによって前記クライアントに伝送された時間に関連する特定の時間フレーム内で前記通信デバイスによって受け取られることを確認する前記通信デバイスをさらに含む、請求項23に記載のシステム。
- 26前記識別子に応答して前記サーバ通信チャネルを介して前記ノンヌル価値セッション鍵を前記アプリケーションサーバに伝送する前記通信デバイスをさらに含む、請求項24に記載のシステム。
- 27前記サーバ通信チャネルは、安全な通信チャネルである、請求項24に記載のシステム。
- 28前記通信チャネルを介して、付加的な情報を前記アプリケーションサーバに伝送する前記通信デバイスをさらに含む、請求項19に記載のシステム。
- 29前記付加的なチケット情報は、前記クライアントのユーザのログイン情報をさらに含む、請求項28に記載のシステム。
- 30前記付加的なチケット情報は、アプリケーションサーバ上で実行するソフトウェアアプリケーションの名前をさらに含む、請求項29に記載のシステム。
- 31前記通信デバイスは、ウェブサーバをさらに含む、請求項19に記載のシステム。
- 32前記クライアントをオペレーティングするユーザのパスワードを前記アプリケーションサーバに伝送する該クライアントをさらに含む、請求項19に記載の方法。
- 33少なくとも一つの前記クライアントと該クライアントをオペレーティングするユーザに対応する情報を前記アプリケーションサーバに伝送する前記チケットサービスをさらに含む、請求項19に記載の方法。
Independent claims33
79 paragraphs, as filed
【0001】
The present invention generally relates to a client-server computer network. More specifically, the present invention relates to systems and methods for securely accessing software applications using remote display protocols.
【0002】
(Background of the Invention) A client computer or software application required to be displayed remotely on a client is normally accessed in a graphic or windowed terminal session. When a user requests an application on a client computer, the application runs on the server and generally input information (eg, mouse and keyboard information) and display information is transmitted from the server computer to the client computer. Graphical or windowed terminal sessions often use connections between unauthenticated clients and servers. Alternatively, a graphic or windowed terminal session can authenticate the connection between the client and the server by providing the user with a password to the server.
【0003】
The techniques described above used by terminal sessions have various drawbacks. For example, transmitting information such as password information to an unauthenticated server allows this server to be viewed by a server that is not trusted by the client. Its insecure connection allows eavesdroppers to intercept the user's password for future use.
【0004】
To avoid these problems, clients and servers are commonly authenticated using traditional cryptography. One type of cryptography used by networks is a ticket-based authentication scheme. Most of the ticket-based authentication schemes currently in use carry tickets. Tickets that may generally be used only once may include an encryption key for use in future communications and / or a private password to assist in future communications. If both the client and the server have the encryption key, the client and server can communicate securely.
【0005】
However, currently used ticket-based authentication schemes are limited within some areas. First, tickets are generally transmitted to clients over insecure communication channels. This allows an eavesdropper to intercept the ticket and retrieve the encryption key. The encryption key can be used by an eavesdropper to make the client look like a server or to the server as a client. Second, the schemes currently in use do not take advantage of secure web pages. Currently used ticket-based authentication schemes allow transactions over the Internet, such as purchases, because owner information, such as the purchaser's credit card information, can be transmitted to unsecured web pages. Make it unsafe. Third, software applications running on the server are generally transmitted over an unsecured communication channel to the display of the remote display protocol on the client machine. For example, a network may be a specific application server (eg, Citrix Systems, Ft. Lauderdale, Florida) for running specific applications that are commonly transmitted to remote display services over insecure communication channels. It can consist of Metaframe for Windows®, manufactured by Inc. Fourth, the ticket is generally used only once (ie, make it a "one-time use" ticket) and has no additional value after its first use, but this one-time use ticket Does not protect the password used to log in to the user's operating system or application from an eavesdropper during the first transmission of the ticket (the password is used to log in to the operating system or application). Therefore, the user's password is still not fully protected from interception, and the server is not authenticated to the client as a result.
【0006】
The present invention is characterized by a system and a method for establishing a secure communication channel between a client and an application server. The ticket service generates a ticket with an identifier and a session key. The communication device obtains the ticket from the ticket service and transmits the ticket to the client through a secure communication channel. The client uses the application communication channel to transmit the ticket identifier to the application server. The application server then obtains a copy of the ticket session key from the ticket service. The communication exchanged between the client and the application server over the application communication channel is then encrypted using the session key to establish the application communication channel as a secure communication channel.
【0007】
In one embodiment, a web browser running on a client establishes communication with a web server over a secure web communication channel. The client receives a ticket with an identifier and a session key from a web server via a secure web communication channel. The client then transmits the ticket identifier to the application server via the application communication channel to provide the application server with information for obtaining a copy of the session key.
【0008】
In one aspect, the invention relates to a method for establishing a secure communication channel between a client and an application server. The client receives a ticket with an identifier and a session key from a web server via a secure web communication channel. The client then transmits the ticket identifier to the application server over the application communication channel to provide the application server with information for obtaining a copy of the session key. The client establishes a secure communication channel over the application communication channel by using the session key to encrypt and decrypt communication to and from the application server. This identifier is a nonce. In one embodiment, the client and web server use secure socket layer technology to establish a secure web communication channel.
【0009】
In another aspect, the invention relates to a communication system that establishes a secure communication channel. Communication systems include clients, application servers, communication devices and ticket services. The ticket service generates a ticket with an identifier and a session key. The communication device communicates with the ticket service to obtain the ticket. The client communicates with the communication device over a secure communication channel in order to receive a ticket from the communication device. The application server communicates with the client through the application communication channel to receive the ticket identifier from the client, and with the ticket service to obtain a copy of the session key from the ticket service. The application server and client exchange communication over the application communication channel as a secure communication channel. In one embodiment, the ticket service resides on the communication device. In one embodiment, the communication device is a web server.
【0010】
Many of the aspects of the invention described above and the ancillary advantages of the invention are better understood by reference to the accompanying figures. The accompanying drawings show a system according to a preferred embodiment of the present invention.
【0011】
(Detailed Description) FIG. 1 is a block diagram of an embodiment of a communication system 100 including a client 10 that communicates with an application server 15 via an application communication channel 25 and communicates with a communication device 20 via a communication channel 30. Shown. The communication channel 30 and the application communication channel 25 pass through the network 27. In other embodiments, the communication channel 30 and the application channel 25 pass through other different networks. For example, communication channel 30 may traverse a first network (eg, the Worldwide Web) and application communication channel 30 may traverse a second network (eg, a direct dial-up modem connection). The communication channel 30 is a secure communication channel because the communication is encrypted. Further, the application server 15 communicates with the communication device 20 via the server communication channel 35. The application server 15 and the communication device 20 are part of the server network 33. By utilizing the security of secure communication between the client 10 and the communication device 20 over the secure communication channel 30, the communication system 100 is insecure for securely remotely displaying the desktop application on the client 10. Establish a secure communication link over the application communication channel 25.
【0012】
The network 27 and the server network 33 can be a local area network (LAN) or a wide area network (WAN), or can be the Internet or the Worldwide Web, ie, a network within multiple networks such as the Web. The communication channel 30 can be any secure communication channel. In one embodiment, the communication channel 30 (hereinafter referred to as the web communication channel 30) supports communication via the web. In one embodiment, the server network 33 is a protected network that cannot be accessed by the public. The server communication channel 35 crosses the server network 33 and can therefore be an unsecured communication channel. Examples of embodiments of communication channels 25,30,35 include LAN or WAN links (eg, T1, T3,56kb, X.25), broadband connections (ISDN, Frame). Includes Relay, ATM) and wireless connectivity. Connections over communication channels 25,30,35 can be established using a variety of communication protocols (eg HTTP, TCP / IP, IPX, SPX, NetBIOS, Ethernet®, RS232 and direct asynchronous connections). ..
【0013】
Client 10 can be any personal computer (eg, 286,386,486, Pentium®, Pentium® II, Macintosh computer), Windows®-based terminal, Network Computer, wireless device (eg, mobile phone). ), Information equipment, RISC Power It can be a PC, X-device, workstation, minicomputer, mainframe computer, personal digital assistant, or other communication device capable of communicating over a secure web communication channel 30. In one embodiment, the client 10 operates according to a server-based computer model. Execution of the application program in the server-based computer model occurs entirely on the application server 15, and user interfaces, keystrokes and mouse movements are transmitted to the client 10 via the application communication channel 25. The user interface can be a text drive type (eg, DOS) or a graphic drive type (eg, Windows®). The platform that can be supported by Client 10 can be Windows® CE for DOS and windows® based terminals.
【0014】
In one embodiment, Client 10 is an Internet Explorer developed by Microsoft Corporation, eg, in Redmond, Washington, to connect to the web.<sup>TM</sup>Includes web browser 40 like. In a further embodiment, the web browser 40 is an existential Secure Socket Layer (SSL) developed by Netscape in Mountain view, California to establish a secure web communication channel 30 for communication devices such as communication device 20. Use support. The web browser 40 also has a user interface that can be text-driven or graphic-driven. The output of the application running on the application server 15 may be displayed on the client 10 via the user interface of the client 10 or the user interface of the web browser 40. Further, the client 10 includes an application client 41 for establishing and exchanging communication with the application server 15 via the application communication channel 25. In one embodiment, Application Client 41 is Independent, developed by Citrix Systems, Inc. of Fort Lauderdale, Florida. It is a Computing Architecture (ICA) client and is referred to below as ICA Client 41. Other embodiments of Application Client 41 are Remote Display Protocol (RDP) developed by Microsoft Corporation in Redmond, Washington, and X-Windows® developed by the Massachusetts Institute of Technology in Cambridge, Massachusetts. Includes data entry clients in traditional client / server applications, and Java® applets.
【0015】
The application server 15 is a host of one or more application programs that can be accessed by the client 10. An application made available to a client for use is referred to as a published application. Examples of such applications include word processing programs such as MICROSOFT WORD® and spreadsheet programs such as MICROSOFT EXCEL®. Both of these are manufactured by Microsoft Corporation in Redmond, Washington, and are financial reporting programs, customer registration programs, programs that provide technical support information, consumer database applications, or application configuration managers. In another embodiment, the application server 15 is an element of a server farm (not shown). A server farm is one or more managed logical groups, such as a single entity.
【0016】
In one embodiment, the communication device 20 (hereinafter, web server 20) is a computer that transmits a web page to the client 10. In other embodiments, the communication device 20 is any personal computer such as 286,386,486, Pentium®, Pentium® II, Macintosh computer), Windows® based terminal, Network Computer, wireless. Devices (eg mobile phones), information devices, RISC Power PCs, X-devices, workstations, mini-computers, mainframe computers, personal digital assistants, or other secure web communication channels 30 with clients 10 can be established. It can be a communication device.
【0017】
In one embodiment, the web server 20 also includes a ticket service 60. This ticket service 60 controls communication security. The ticket service 60 generates a ticket containing an encryption key. The ticket is transmitted to the client 10 (ie, the web browser 40) via the secure web communication channel 30. Transmission of the ticket to the client 10 over the secure web communication channel 30 facilitates the establishment of secure communication over the application communication channel 25 between the client 10 and the application server 15 according to the principles of the invention. In another embodiment, the ticket service 60'residents on another server 20'. The server 20'(and the ticket service 60') communicates with the web server 20 and the application server 15 via the server communication channel 35'. Further, in another embodiment, the ticket service 60 is a separate component (not shown) from the server network 33. The web browser 40 then sends the ticket to the ICA client 41. A technique often used to transfer application data from an application running on application server 15 over a secure connection to client 10 is to make the application data a secure connection between client 10 and web server 20. It is transmitted to the client 10 through the web server 20 via the web server 20. This technique is inefficient in that the communication between the application server 15 and the client 10 goes through an additional "hop" (ie, the web server 20). The present invention uses a ticketing mechanism to establish a direct secure communication link between the application server 15 and the client 10. Thereby, the intermediate transmission of application data from the application server 15 to the web server 20 is removed.
【0018】
For example, a client user requesting an application desktop or server to be displayed remotely on client 10 establishes a communication link 32 to web server 20 via web communication channel 30 and logs in and passwords to web server 20. Send information. In one embodiment, the client user uses the web browser 40 to request an application from the web server 20 listed on the web page displayed by the web browser 40.
【0019】
In a further embodiment, the web browser 40 uses SSL to establish a secure web communication channel 30. To use the SSL protocol to establish a secure web communication channel 30, a web browser 40 or application running on client 10 attempts to connect to a secure web page on web server 20. The web server 20 then asserts the identity of the web server to the client 10 by transmitting a secure web server digital signature to the client 10. The Certificate Authority (CA) issues a secure web server digital signature to the web server 20. The web browser 40 has a list of trusted CAs (ie, the CA's public key) embedded within the software of the web browser 40. The client 10 demonstrates the web server digital signature by decrypting the CA signature in the web server digital signature with the CA public key embedded in the web browser 40 (or application). Therefore, in order to establish a secure communication channel using SSL, an application running on a web browser 40 or client 10 is embedded in the software before attempting to connect to a secure web page. Have the CA's public key. In addition to using the SSL protocol to establish a secure web communication channel 30, the web browser 40 uses other security protocols to connect to the web server 20 via the web communication channel 30. Other security protocols include, but are not limited to, for example, via Secure Hypertext Trasfer Protocol (SHTTP) developed by Terisa Systems of Los Altos, California, and SSL developed by Microsoft Corporation in Redmond, Washington. HTTP (HTTPS), Private Communication
【0020】
Once the communication link 32 is established, the web server 20 generates a ticket for the communication session. This ticket includes a first part and a second part. In one embodiment, the first part referred to as a session identifier (ID) or nonce is a cryptographic random number that can be used within a particular time period determined by web server 20. The second part is the encryption key, which is referred to below as the session key. The web server 20 stores the ticket in local memory and then transmits a copy of the ticket to the web browser 40 on the client 10 (arrow 34).
【0021】
In one embodiment, the ticket contains additional information such as the network address of application server 15. In another embodiment, the web server 20 independently transmits the address of the application server 15 to the client 10. For example, if client 10 requests an application by name from web server 20, web server 20 translates the name of the application into a network address. Examples of additional information contained in the ticket are, but not limited to, the time the ticket is valid, the screen size of the application as it is displayed to client 10, the bandwidth of web communication channel 30 and / or application communication channel 25. Bandwidth limit, as well as billing information. More fully, as shown below, the web server 20 also associates the user's login information, such as the user's password, with a ticket stored by the application server 15 in local memory for future searches.
【0022】
The ICA client 41 obtains the ticket from the web browser 40 and then transmits the session ID (ie, the first part) of the ticket to the application server 15 (arrow 42). The session ID can be transmitted in encrypted form or in cleartext format. If the session ID is encrypted, the application server 15 decrypts it and transmits a request to the web server 20 to obtain the session key corresponding to the session ID received from the client 10 (arrow 44). The web server 20 confirms the session ID as shown below and sends the corresponding session key to the application server 15 via the server communication channel 35 (arrow 48).
【0023】
Both application server 15 and client 10 (ie, ICA client 41) own a copy of the session key without requiring the transmission of the ticket or session key over the insecure application communication channel 25. By using the session key to encrypt and decrypt communication over the previous insecure application communication channel 25, the client 10 and application server 25 establish a secure communication link over the application communication channel 25. (Arrow 50). Further, the user login information (eg, password) is not transmitted between the client 10 and the application server 15 via the insecure application communication channel 25. Therefore, the present invention provides the insecure application communication channel 25 by not showing the eavesdropper who intercepts the communication through the insecure application communication channel 25 the information to be paid close attention to, such as the user's password. Increase the security (arrow 50) of the communication link 50 through. Further, since the application server 15 and the client 10 communicate with each other with the same session key, the application server 15 and the client 10 share the secret transmitted by the ticket service 60. The ticket service 60 indirectly trusts the application server 15 and the client 10, and the ticket service 60 guarantees each of them. Therefore, the application server 15 and the client 10 perform mutual authentication. In one embodiment, the client 10 retransmits the user's password to the web server 20 over the web communication channel 30 to provide compatibility with the legacy system (eg, the user's password to the client 10). An unchanged operating system login sequence on the web server 20 that requires multiple transmissions).
【0024】
In further detail, FIG. 2 shows an embodiment of the processing performed by the communication system 100 to establish a secure communication link 50 between the client 10 and the application server 15 via the application communication channel 25. The web browser 40 lists the software application on the web page viewed by the user of the client 10 or the web link to the server desktop (step 200). The client user uses the web browser 40 to request a software application from the web server 20 (step 205). In one embodiment, the web browser 40 establishes a secure web communication channel 30 using the SSL protocol already shown. In this embodiment, the client 10 (eg, web browser 40) uses a public key (eg, X509) digital signature to trust the web server 20. In a further embodiment, the client 10 is also authenticated to the web server 20 using the public key digital signature.
【0025】
In another embodiment, when the user uses the web browser 40 to request an application from the web server 20, the web server 20 authenticates the user. For example, the web server 20 requests the user's login information. The user's login information includes the user's login name and password, as well as the request displayed on the web browser 40. The user provides the web browser 40 with the user's login information (step 210). The web browser 40 then transmits the user's login name and password to the web server 20 via the secure web communication channel 30 (step 220). In another embodiment, the user login information is any code or method that the web server 20 accepts to identify the user's account on the web server 20.
【0026】
The web server 20 transmits the user login information to the ticket service 60 (step 230). The ticket service 60 verifies the user's login information (step 240) and determines whether the user is entitled to access the requested application. In accordance with the declared communication security policy for the application, Ticket Service 60 denies or grants access to the application by the user. If the ticket service 60 denies access, the web browser 40 displays an HTML error or error web page on the client 10. When the ticket service 60 grants access to the requested application, the ticket service 60 generates a ticket during the session (step 245) and transmits the ticket to the web server 20 (step 250).
【0027】
As mentioned above, the ticket contains the session ID and session key. The session ID can be used once within a particular time period, causing the ticket to become a "one-time use" ticket with no further value after the first use. The web server 20 then stores the ticket in local memory (step 253). In a further embodiment, the web server 20 is later provided by the application server 15 with the login information provided by the user in step 210 and other security information used to authorize the session (eg, the requested application name). Connect with the stored ticket to search. The web server 20 then transmits the ticket to the client 10 over the secure web communication channel 30 (step 255).
【0028】
The web browser 40 extracts the session ID from the ticket (step 260) and gives the application server 15 the session ID (step 265). The application server 15 checks the session ID to ensure that the session ID was not previously used by the client 10. In one embodiment, the application server 15 monitors each ticket (ie, session ID) transmitted by the client 10 to the application server 15 (eg, stores it in local memory). In another embodiment, the ticket service 60 checks the session ID to ensure that the session ID was not previously used by this client 10. In yet another embodiment, the ticket service monitors each ticket transmitted to the web server 20 to ensure that each session ID is transmitted to the ticket service 60 only once.
【0029】
The application server 15 then uses that session ID to determine the session key associated with the given session ID. To accomplish this, the application server 15 transmits the session ID to the ticket service 60 and requests the session key from the ticket service 60 of the web server 20 in response to the session ID (step 270). The ticket service 60 accesses the local memory and uses the session ID as an index for searching the ticket information associated with the session ID. Ticket service 60 then returns the session key associated with the session ID to application server 15 (step 280).
【0030】
To improve the optimization of communication between the application server 15 and the web server 20, in an alternative embodiment, the web server 20 adds additional information (eg, a request) previously associated with the ticket in step 253. The applied application name and user login information) are transmitted to the application server 15 (shown as phantom step 266). The application server 15 extracts additional ticket information from this additional information (phantom step 267) and authorizes the communication session. Additional information, such as the requested application user's password and / or name, is not transmitted by the client 10 to the application server 15 over the insecure application communication channel 25, thereby potentially attacking. Protect information from people. In this embodiment, the application server 15 demonstrates additional information (phantom step 268). If this additional information is not valid, the application server 15 denies access to the application requested by the user (Phantom Step 269). If this additional information is valid, grant access to the requested application and request the session key from ticket service 60 as described above (step 270).
【0031】
In another embodiment, the ticket service 60 performs an additional check on the session ID. For example, the ticket service 60 replays (ie checks that the session ID has never been transmitted to the ticket service 60 before) and / or denies a service attack (DoS) (ie with unauthorized data packets). Check on the session ID for early detection (which floods the remote server and eventually disables it). In a further embodiment, the web server 20 transmits the first and second parts of the ticket to the application server 15 before the application server 15 requests (step 270). Therefore, the requirement is removed in step 270. In this embodiment, the application server 15 stores the session key in its local memory, and after the client 10 gives the session ID to the application server 15 (step 265), the session key is fetched from this local memory.
【0032】
After the application server 15 obtains the session key (step 280), the application server 15 decrypts the communication from the client 10 to the client 10 in order to encrypt the communication and via the application communication channel 25. Use the session key to make it. Similarly, the client 10 is a ticket transmitted over the secure web communication channel 30 for the client 10 to decrypt the communication from the application server 15 and to encrypt the communication to the application server 15. Use the session key obtained from. Client 10 and application server 15 use the session key to encrypt and decrypt communication over application communication channel 25, so client 10 and application server 15 go through the previous insecure application communication channel 25. Establish a secure communication link 50 (step 290). Further, since the client 10 and the application server 15 have the session key without transmitting the ticket through the unsecured application communication channel 25, the client 10 and the application server 15 communicate through the former unsecured application communication channel 25. Increase the security of Link 50.
【0033】
In one embodiment, the application communication channel 25 is secured using the SSL protocol. In this embodiment, the ticket service 60 replaces the application server digital signature in place of the session key in this ticket. Client 10 uses the application server digital signature to communicate with application server 15. The application server digital signature is downloaded to the client via the web communication channel 30 in response to the request for the ticket. Therefore, the application server digital signature does not need to be signed by a well-known public CA, as the application server digital signature is downloaded to the client 10 via a secure link (ie, web communication channel 30). Client 10 did not have an application server digital signature or CA key in advance, but an authenticated secure connection is made through the application communication channel 25 using the application server digital signature contained in the ticket. , Established.
【0034】
For example, if client 10 requests another SSL component (eg, another instance or implementation of the requested software application), and client 10 requests its local memory (eg database, local disk, RAM, ROM). Without a CA digital signature within, the client 10 may use the application server digital signature in the transmitted ticket to establish an authenticated and secure connection over the application communication channel 25. More specifically, when client 10 does not have a CA root digital signature stored in the local memory associated with the requested SSL component (or client 10 does not include a CA digital signature for the requested SSL component). When the client 10 has an incomplete list of CA digital signatures) and when the client 10 cannot access the CA database of the web browser 40, the client 10 uses the application server digital signature in the transmitted ticket. In addition, the signed CA digital signature is required for the web server 20, but not for the application server 15 (ie, each application server 15 that is an element of the server farm), so it is secure. The cost (and overhead) of obtaining the required number of signed CA digital signatures for communications is reduced. In another embodiment, the application server 15 stores a private key for decrypting a message encrypted with the corresponding public key. As a result, the ticket service 60 transmits the public key corresponding to the application server 15 to the client 10 in order to encrypt the communication.
【0035】
In this embodiment, the client 10 can gain access to the requested application, and the ticket service 60 (or web server 20) monitors the ticket (ie, session ID), thus gaining one access. In ensuring that, the session ID provides additional value. In addition, if the application server 15 and client 10 use different session keys to encrypt or decrypt communication over the application communication channel 25, the session ID and cryptographic checksum will be the application server 15 (ie, full). The eavesdropper cannot change the session ID transmitted by the client 10 to the application server 15 because it does not match the check sum expected by the check. Therefore, the client 10 and the application server 15 are when different session keys are used by the application server 15 and the client 10 to encrypt and decrypt over the application communication channel 25 (eg, "dispute mediator". "Attack) to decide.
【0036】
In a further embodiment, the session key is substantially equal to a null value (ie, this ticket includes a nonce only or a nonce and a constant value for the session key). When the session key is substantially equal to the null value, the client 10 does not transmit the user's login information (eg, password) between the client 10 and the application server 15 over the insecure application communication channel 25. Therefore, external exposure of the password can be avoided, as the ticket is only valid for one-time use and only grants access to previously authorized resources (eg, ICA Client 41). Individual session-level access control can be done, albeit at the value of a null or fixed session key.
【0037】
In addition, there is no pre-configured information in the web browser 40 or client 10 for the requested application to be displayed remotely (ie, the client 10 has a server digital signature or a CA digital signature). This method is a "zero-install" solution for secure access to desktop applications via the web (because it is not necessary). Further, the web browser 40 receives a ticket or an ICA client from the web server 20 via the communication channel 30. In this embodiment, the web server 20 transmits a ticket and a MINE type document as described above, specifying that it contains a "document" for the ICA client 41 (as a helper application). The MINE type document calls the ICA client 41 and the web browser 40 transmits the ticket to the ICA client and thus the application communication channel 25 on the client 10 without having the pre-installed ICA client 41. Enables the use of security on communication channel 30 for security. It will be appreciated by those skilled in the art that other embodiments incorporating the concepts of the present invention may be used, as shown in particular embodiments of the present invention. Therefore, the present invention should not be limited to any particular embodiment, but rather should not be limited solely by the intent and scope of the above-mentioned claims.
[Simple explanation of drawings]
[Figure 1]
FIG. 1 is a block diagram of an embodiment of a communication system for establishing secure communication between a client and an application server according to the principles of the present invention.
[Figure 2]
FIG. 2 is a flowchart of a communication embodiment performed by the communication system shown in FIG. 1 to establish secure communication between the client and the application server.
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| JP2021018615A | Cited by | Japan | Search report |
| US9083685B2 | Cited by | United States of America | Applicant |
| US8887242B2 | Cited by | United States of America | Applicant |
| WO2008068976A1 | Cited by | World Intellectual Property Organization (WIPO) | Search report |
| US8761402B2 | Cited by | United States of America | Applicant |
| US11288381B2 | Cited by | United States of America | Applicant |
| JP6671701B1 | Cited by | Japan | Search report |
| JP2010250825A | Cited by | Japan | Search report |
| JP2010250825A | Cited by | Japan | Examiner |
| JP2000010929A | Cites | Japan | Search report |
| JP2000049766A | Cites | Japan | Search report |
| JP2000163369A | Cites | Japan | Search report |
| JP2000183866A | Cites | Japan | Search report |
| JPH11170750A | Cites | Japan | Search report |
| JPH11282884A | Cites | Japan | Search report |
20 members in 11 offices
Priority claims9
| Document | Office | Kind | Date |
|---|---|---|---|
| 09706117 | United States of America | – | |
| 70611700 | United States of America | A | |
| 70611700 | United States of America | A | |
| 0145461 | United States of America | W | |
| 0145461 | United States of America | W | |
| 2000706117 | – | – | – |
| 200145461 | – | – | – |
| US20000706117 | – | – | – |
| WO2001US45461 | – | – | – |
Members20
| Document | Office | Kind | |
|---|---|---|---|
| CA2427699A1 | Canada | A1 | |
| WO0244858A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU3514902A | Australia | A | |
| WO0244858A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP1332599A2 | European Patent Office (EPO) | A2 | |
| HK1054281A | Hong Kong, China | A | |
| HK1054281A1 | Hong Kong, China | A1 | |
| IL155698A0 | Israel | A0 | |
| KR20040004425A | Republic of Korea | A | |
| CN1505892A | China | A | |
| JP2004531914AThis record | Japan | A | |
| US2005050317A1 | United States of America | A1 | |
| AU2002235149B2 | Australia | B2 | |
| US6986040B1 | United States of America | B1 | |
| RU2279186C2 | Russian Federation | C2 | |
| KR100783208B1 | Republic of Korea | B1 | |
| IL155698A | Israel | A | |
| CN100583871C | China | C | |
| CA2427699C | Canada | C | |
| EP1332599B1 | European Patent Office (EPO) | B1 |
4 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Decision of refusalJAPANESE INTERMEDIATE CODE: A02A02 | A02 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 2004531914
- Publication, DOCDB
- 2004531914
- Publication, EPODOC
- JP2004531914
- Application
- 2002546958
- Application, DOCDB
- 2002546958
- Application, EPODOC
- JP20020546958
Titles2
- Japanese
- 非安全通信チャネルを安全にするためのシステムおよび方法
- English
- Systems and methods for securing insecure communication channels
Classification
- CPC, 13
- H04L63/0435
- H04L9/08
- G06F21/606
- G06F2221/2115
- G06Q20/0855
- G06Q20/367
- G06Q20/3674
- G06Q20/3829
- H04L63/06
- H04L63/0807
- H04L63/0823
- H04L63/18
- G06Q20/401
- IPC, 4
- H04L9 08
- G06F21 00
- H04L9 32
- H04L29 06
Designated states4
- Regional, 4
- Zimbabwe
- Turkmenistan
- Türkiye
- Togo