BACKGROUND OF THE INVENTION Today, people may access networks and other computer systems from remote locations. One problem with the currently available remote access techniques is that a user typically must have a computer system with specifically designed software and hardware to support communication with the network (or computer system) that is being accessed from a remote location. For instance, a modem is usually required to provide the communication channel, while software running on the computer system is responsible for providing the protocols necessary to use the communication channel.

The software may also be responsible for ensuring that all accesses occur in a secure manner. Similarly, the network (or computer system) must also include the necessary hardware and software to communicate with the computer system that is accessing it.

Unfortunately, a particular software product used to provide remote access capability is usually incompatible with the other remote access products. That is, if the network (or computer system) is only configured for remote access using a specific remote access software package, then a computer system attempting to access the network must have that specific remote access software or the access will be unsuccessful. Thus, if the user doesn't have a computer system with the specifically designed software, such a person will not be allowed access.

Although many remote access products are marketed towards employees trying to access their employer's network or computer system, these people often find themselves at work wishing they had access to files and applications that are located on their home computer. That is, it is not uncommon for individual to want access to their files or other assets that are stored on their home computer while they are at work or some other remote location. The only way that they can gain access is if they had a remote access product on their computer at work or other remote location as well as on their computer at home. However, the same problem remains in that the person would be required to use a computer with the same remote access software as their home computer. Without the same software being available, the employee would not be able to gain access to their home computer. Thus, what is needed is access to one's home computer or any other computer from a remote location without the above limitations.

The use of networks to transfer information has become a mainstay in today's society. The World Wide Web (hereinafter the"web") may be accessed using simple web browsers. Although browsers may look different, they access the same information (e. g., documents) in the same way. It would desirable to use the flexibility that is associated with web browsers and networking to overcome the limitations of current remote access techniques to provide an individual access to their home computer or other computers situated in remote locations.

Problems exist with remote connectivity via networks (e. g., the Internet). For instance, when using a dial-up service, a service provider either limits the connection time or bills accordingly. Therefore, the user generally does not leave the home computer connected to the Internet or suffers from higher costs. Because the home computer does not remain connected to the Internet, any remote access over the Internet must provide for some mechanism to cause the computer to obtain network connectivity to enable access. Also, when using a dial-up service, the service usually grants them a temporary IP address. Each time a connection is made, this address is different. This changing address creates a problem for a person attempting to remotely access a computer system. There must be an effective method for obtaining this temporary address.

Additionally, once a connection to the Internet is made or is statically present, security becomes a major concern. In such a case, a computer is running a set of services that allow remote interaction with a another computer system. The security implications of the connection are beyond the scope of most users to handle on their own. Most commercial and enterprise situations have built-in security measures (e. g., using certificates from certification authorities) to provide a way to authenticate participants as well as enable privacy to be maintained for communication. However, these mechanisms are often cumbersome or too costly to the average user to utilize efficiently when accessing their own computers.

SUMMARY OF THE INVENTION A method and apparatus for accessing a computer system over a public network using an arbitrary browser is described. In one embodiment, the method includes activating the computer system using an intermediary server, registering the computer system with the intermediary server, redirecting the browser to the computer system, and negotiating a secure channel between the arbitrary browser and the computer system to enable access.

BRIEF DESCRIPTION OF THE DRAWINGS The present invention will be understood more fully from the detailed description given below and from the accompanying drawings of various embodiments of the invention, which, however, should not be taken to limit the invention to the specific embodiments, but are for explanation and understanding only.

Figure 1 illustrates one embodiment of a system in which an arbitrary web browser accesses a computer system.

Figure 2 is one embodiment of a process for remotely accessing a computer system.

Figure 3 illustrates one embodiment of the activation protocol for activating a computer system using an intermediary server.

Figure 4 is a flow diagram of one embodiment of a process for registering a computer system.

Figure 5 is a flow diagram of one embodiment of a process for negotiating an encrypted (private) channel between a browser and a computer system.

Figure 6 illustrates one embodiment of a HTTPC process.

DETAILED DESCRIPTION OF THE PRESENT INVENTION A method and apparatus for using an arbitrary browser to gain access to a computer system over a network are described. In the following description, numerous details are set forth, such as distances between components, types of molding, etc. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present invention.

In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention can be practiced without these specific details. In other instances, well- known structures and devices are shown in block diagram form in order to avoid obscuring the present invention.

Some portions of the detailed descriptions which follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present invention, discussions utilizing terms such as"processing"or"computing"or"calculating"or "determining"or"displaying"or the like, may refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

The present invention also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. Instructions are executable using one or more processing devices (e. g., processors, central processing units, etc.).

The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose machines may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these machines will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein.

Overview The present invention provides access to a remotely located computer (e. g., host) using a public network as a transport and an arbitrary browser as a client. In one embodiment, the present invention uses the public Internet network to access a computer (e. g., a user's home computer) securely from a web browser. This computer is referred to herein as a home portal computer.

The connection between the browser and the home portal computer is set up by an intermediary server. In one embodiment, the intermediary server creates a network connection between the browser and the home portal computer in response to a request from the browser. The intermediary server causes the computer to obtain network connectivity in response to the request from the browser. Once network connectivity is obtained for the home portal computer, the intermediary server redirects the browser to a network server on the home portal computer.

In order to enhance the security of the information being transferred between the home portal computer and the browser, the information being transferred may be encrypted. Such encryption is routinely used on transfers with browsers over the Internet. However, in one embodiment, the security used is improved through by the browser setting up an SSL channel with the home portal computer.

An Exemplary System Figure 1 illustrates one embodiment of a system in which an arbitrary web browser accesses a home portal computer. Referring to Figure 1, an end-user arbitrary remote browser 101, an intermediary server 102, a home portal computer system 103, and a network service provider 104 (e. g., an Internet Service Provider (ISP)), a public network (e. g., Internet) 105, and the public switched telephone network 106 are shown.

Although it is referred to as a"home portal", the computer system 103 is not limited to being a home personal computer system and may be any system remotely located for which access is sought.

The arbitrary browser 101 connects to the public network 105. In one embodiment, the browser 101 connects to the public Internet network via TCP/IP. The arbitrary browser 101 is arbitrary in that it doesn't need any additional hardware or software support (on the client side) to allow it to give access to the home portal computer system 103.

The network service provider 104 provides individuals access to the public network 105 in a manner well-known in the art.

The intermediary server 102 acts as an intermediary to receive requests from browser 101 for access to the home portal computer system 103, to cause the home portal computer system 103 to become accessible, and to redirect the browser 101 to the home portal computer system 103 for communication.

In one embodiment, the intermediary server 102 comprises a secure web server 102A, a database of user accounts 102B, and a server telephony module 102C. The secure web server 102A coordinates the functions of having the home portal computer system 103 obtain network connectivity, redirecting the browser 101 to the home portal computer system 103, as well as facilitating additional security measures as will be described in greater detail below. The database 102B maintains records of user accounts, including contact information enabling the telephony module 102C to contact individual computer systems, such as for instance, the home portal computer system 103, and to activate the home portal computer system 103 in a secure manner to enable access thereto. In one embodiment, the telephony module 102C includes a modem connected to the plain old telephone system (POTS) which is used for negotiating a data connection with the home portal computer system 103 via the public switched telephone network 106.

In one embodiment, the home portal computer 103 comprises a client telephony module 103C that permits connection to an incoming data call. Client telephony module 103C may also permit connection to voice or facsimile transmission in other embodiments (which does not interfere and is not interfered with by the data call). In one embodiment, the telephony module 103C includes a modem connected to the plain old telephone system (POTS) which can be used for accepting a dial-in modem connection. A dedicated Internet connection module 103D and a dial-up connection module 103E are also included for connecting to the network service provider 104. In one embodiment, the network service provider provides TCP/IP connectivity with the public Internet network. An agent 103B communicates to the intermediary server 102 and the network via modules 103C-E to provide access to the home portal computer system 103. The agent 103B controls and executes processes and logic described below to enable this access to occur, including all of the oversight of the application server.

The home portal computer 103 further includes an application server 103A that provides access to assets (e. g., files, applications) in response to browser requests. In other words, the application server 103A is able to receive requests from over the network, process the requests, and provide responses thereto. In one embodiment, the application server 103A operates in conjunction with applications such as web applications 115A-C on home portal computer system 103 and is able to process native code in requests. Although only three applications are shown, home portal computer system 103 may have more than or less than three applications.

Figure 2 is one embodiment of a process for remotely accessing a computer system. The process is performed by processing logic, which may comprise hardware, software, or a combination of both. The processing logic may be in either or both of the home portal computer system and the intermediary server. In an alternative embodiment, some of the processing logic may not be in the home portal computer system or the intermediary server; instead, the processing logic may be in a separate device and/or system.

Referring to Figure 2, the process begins with processing logic connecting a registered user to the intermediary server for mutual authentication (processing block 201). Next, processing logic in the intermediary server signals the home portal computer system to activate the home portal computer system and passes a registration token to the home portal computer system (processing block 202). One embodiment of the process of signaling the home portal computer system and sending the registration token is described in more detail below in conjunction with Figure 3.

Next, processing logic in the home portal computer system registers with the intermediary server and processing logic in the intermediary server redirects the browser (by which the registered user connected to the intermediary server) to the home portal computer (processing block 203). In one embodiment, the process of the home portal computer system registering with the intermediary server and the browser being redirected to the home portal computer system is performed using a registration mechanism is described in greater detail in conjunction with Figure 4.

Afterwards, processing logic in the home portal computer system negotiates a secure channel with the browser (processing block 204). In one embodiment, the process for negotiating a secure channel between the browser and the home portal computer system is described in greater detail below in conjunction with Figure 5.

After the secure channel has been negotiated, a user passes their pass phrase to the home portal computer system to gain access thereto (processing block 205). The pass phrase may be user-selected and operates as a shared secret between the user and the home portal computer system. The use of the pass phrase ensures that only the user or other authorized individuals gain access to the home portal computer system once the home portal computer system has already been activated, registered and has negotiated a secure channel with the browser. That is, the pass phrase ensures that no other individuals can access the home portal computer system once it has been brought to this state of access readiness.

Once the user gains access to the home portal computer system, processing logic in the home portal computer system runs a series of applications in conjunction with an application server directed by the user (processing block 206). In one embodiment, these applications comprise web-based applications directed using a web browser.

When finished with the access, the user directs processing logic in the home portal computer system to shut down the services provided by the intermediary server and the software executed on the home portal computer system (processing block 207).

In one embodiment, the processing logic in the home portal computer system disconnects from the network, causing the connection to the home portal computer system to be halted. In response to the interruption, processing logic on the home portal computer system closes the application server.

Activation Protocol An activation protocol causes the home portal computer system to become activated and prepare for access by an arbitrary browser. If the home portal computer system is not on-line, the activation protocol causes the home portal computer system to connect to the network (e. g., the Internet) as part of an out-of-band process. If the home portal computer system is already on-line, activation refers to an in-band process of alerting the home portal computer system that access is desired. In one embodiment, this connection is made using only authentic messages that have integrity (i. e., the message has not been changed). Thus, messages are not subject to spoofing or subject to third party alteration. In one embodiment, the messages themselves are passed in clear text.

Additionally, in one embodiment, the activation protocol securely passes a URL (or other resource identification information) and a registration token to the home portal computer system to register with the intermediary server. The URL provides information by which the home portal computer system connects to the intermediary server after coming on-line. That is, the URL specifies the address for the intermediary server. Note that the URL and the registration token are not used by the home portal computer system until authenticated and only after they are determined to have integrity.

Figure 3 illustrates one embodiment of the activation protocol for activating the home portal computer system using the intermediary server to cause the home portal computer system to prepare for access.

In one embodiment, the activation process occurs over POTS. The process is performed by processing logic, which may comprise hardware, software, or a combination of both.

In one embodiment, the activation occurs in response to a user request with an arbitrary client browser in the form of a universal resource locator (URL) that directs the client browser to the intermediary server. The URL may be stored locally or manually entered by the user. The user may also be required to log in through the client browser to initiate the connection process. This log in procedure allows the intermediary server to authenticate the user. In one embodiment, authentication may require that the user enter a name and a password. After logging in, the client browser waits for a response. In response to the user being authenticated, the intermediary server accesses the database to obtain contact information (e. g., a telephone number, an IP address, etc.) from the user's account information. Using the contact number, the intermediary user is able to contact the home portal computer system over the public service telephone network (PSTN).

Referring to Figure 3, the activation protocol begins with the intermediary server sending a request to the home portal computer system to communicate with the intermediary server (processing block 301). In one embodiment, the request enumerates the current and pending key IDs and supported protocols and versions the home portal computer system may select for use in communicating with the intermediary server. The keyIDs are identifiers for the keys and not the actual keys themselves. In one embodiment, the request also includes a large random number (NONCEI). In one embodiment, NONCEI is a random number greater than or equal to 64 bits (e. g., 128 bits). The NONCEI will be used by the home portal computer system to authenticate the reply. The information passed to the home portal computer system is sent in clear text.

The intermediary server may contact the home portal computer system in a number of ways. For instance, in one embodiment, the intermediary server may contact the home portal computer system using a dedicated or non-dedicated phone line. In an alternative embodiment, particularly advantageous when the phone line is being shared for other purposes, caller ID and telephone lines signaling method may be used to enable the computer system to determine when the call is directed towards the home portal computer system or the other purpose. In one embodiment, one signaling method comprises a double ring method to signal to the home portal computer system that the call is directed toward it. Note the use of any ringing method may be used. In one embodiment, the home portal computer system is already connected to the network (e. g., the Internet) and, thus, is"always-on". In this instance, the activation occurs in- band.

The home portal computer system generates a response to accept the proposal to the request that is received by the intermediary server (processing block 302). In one embodiment, the response indicates the protocol by which the intermediary server can communicate with the home portal computer system. The response also specifies the pre-shared keyID (k), a large random number (NONCER), and a customer ID. In one embodiment, the protocol, pre-shared keyID (k), customer ID and the large random number are hashed into a message authentication code (MAC) using a hashing algorithm. The MAC represents the signature that is sent with the response. Since the response includes the pre-shared key ID and the large random number, the intermediary server is able to generate the same signature as accompanied the response.

In one embodiment, the hashing is performed using a one-way hashing algorithm HMAC according to the following: HMAC (k, text! NONCEI) where"refers to concatenation such that text is concatenated with the large random number (NONCEI) using the key identified by the keyID. In one embodiment, the base formula for calculating the authentication code is as follows: HMAC (K, text) = TRUC128 (H9K XOR opad, H (K XOR ipad, text))) where K is the pre-shared key, length <=64 bytes; text is the message body to be authenticated; ipad=the byte 0x36 repeated B times (where B=64 for SHA-1); opad=the byte Ox5C repeated B times; and H is a one way function (e. g., SHA-1 algorithm).

Note that the output of the SHA-1 algorithm is 160 bits. However, in one embodiment, only the first 128 bits of the hash output are used. The truncation function is denoted as TRUC128.

(A text representation has been used for the digest, in HEX, 2 characters per byte, in caps).

In an alternative embodiment, the MD5 algorithm is used instead of SHA-1. Any hashing algorithms may be used.

The MAC is then sent to the home portal computer system along with a message containing the keyID, the larger random number NONCER, the customer ID and the protocol.

The intermediary server verifies the authenticity of the message from the home portal computer system by calculating the message authentication code (MAC). If this MAC matches the MAC sent with the message, then the intermediary server communicates with the user via the browser to obtain a browser activation code (BAC).

The browser generates a browser activation code (BAC) formulated according to the following: BAC = SHA (NONCER I Activation password), where the large random number (NONCER, which is sent to the browser with the request) is concatenated with the activation password entered by the user. The result of the concatenation is hashed using a hashing algorithm. In one embodiment, the hashing algorithm used is SHA1, which is well-known in the art. Note that the activation password is provided by the user and is not sent to the intermediary server, only the result of the hashing algorithm is sent (e. g. BAC).

Note that the BAC could be calculated by the intermediary server, instead of the browser. In such a case, the intermediary server communicates with the user, via the browser, to obtain the activation password. The intermediary server then calculates the BAC using the same method as described above.

Once the intermediate server possesses the BAC, either calculated by the browser or done locally on the intermediary server, the intermediary server sends an activate command to the home portal computer system (processing block 303). The activation command includes the intermediary server common name, a URL, the BAC and a registration token. These are passed to the home portal computer system. The URL enables the home computer to contact the intermediary server later during registration.

The registration token is a one-time identifier that enables the browser and home portal computer system to know that they are communicating with each other about the same session and prevents replay. The BAC is used by the home portal to authenticate the user.

In one embodiment, a service identifier, URL, registration token and BAC are combined as text, concatenated with a random number (NONCER), and hashed into a MAC using the function: HMAC (k, text I NONCER), which is sent to the home portal computer system.

In response to the request to activate command, the home portal computer system provides status as to whether of the home portal computer system has agreed to be activated (processing block 304). If the previous request is authentic and has integrity, the home portal computer system agrees to be activated. The home portal computer system determines whether the message has integrity by using the same shared key and applying the same hashing function used by the intermediary server on text in the response message to determine if the same digital signature (i. e., the same MAC) is created. That is, the hashing algorithm itself is well-known; however, only parties that have the same input information will generate the same result. The home portal computer system and the intermediary server are the only parties with the same shared secret, which is not sent between the two. Therefore, they are the only two parties that generate the same results when using the same hashing algorithm. If so, then home portal computer system considers the message received from the intermediary server to have integrity, to be authentic, and to be unique (i. e., not a replay).

After verifying integrity, the home portal computer system calculates a BAC according to the same formula above (used by the intermediary server) using the NONCER concatenated with its copy of the activation password and hashing the result of the concatenation with a SHA. The resulting BAC is then compared by the home portal computer system with the BAC contained in the response message. If the BAC generated by the home portal computer system matches the BAC in the response message from the intermediary server, then the home portal computer system knows the message is authentic (i. e., the message came from the intermediary server and has come from an authorized user of the service). Therefore, by performing the two matches, the home portal computer system determines that the response message is authentic and has integrity, and in response thereto, the home portal computer system agrees to be activated.

If the home portal computer system has agreed to become activated (allowing access), then to indicate that, the home portal computer system responds with a message that a network connection for itself will be obtained shortly. If the home portal computer system does not agree to be activated (because the message is not authentic and/or doesn't have integrity), the home portal computer system provides an error code or other indication. Again, the home portal computer system's response is hashed into a MAC according to the following: HMAC (k, text I NONCEI).

The intermediary server generates a message to the home portal computer system indicating that communication has ended (processing block 305). This message is ancillary.

It is important to note that the activation protocol is transport independent (other than that the transport is stream reliable). In one embodiment, the transport may use TCP/IP (in-band) or data modem over POTS (out-of-band). In one embodiment, the activation protocol is extensible because it is achieved by text-based syntax. The specification of the versioning allows the protocol to be backward compatible. The protocol has a low number of round trips and provides extra protection agent accidental activation in that the activation must be from both the intermediary server and the activation password, which is only possessed by the user.

The activation protocol also allows mutual authentication to be achieved by use of preshared keys. Each key is unique and generally only used once. The message authenticity and integrity is achieved with hashing algorithms using preshared keys. A protocol also prevents replay by using NONCE (s) (large random numbers) generated by both parties during each unique session. These large random numbers are used to sign messages sent between the two.

After processing block 305 the home portal computer system has agreed to become activated, the home portal computer system dials into the network service provider or uses a dedicated network connection. In one embodiment, the home portal computer system uses an ISP to connect to the network. While the home portal computer system is dialing into the public network, the browser waits. Similarly, the intermediary server is essentially unaware of the current state of the current functioning of the home portal computer system. As a result of getting IP connectivity, the ISP issues an IP address.

Registration A flow diagram of one embodiment of a process for registering the home portal computer system is shown in Figure 4. This registration process provides a secure mechanism for registering the home portal computer system when it becomes activated.

In one embodiment, the process also refreshes the preshared symmetric key. The word "secure"in this context refers to the fact that the messages are verified to be authentic, the messages being passed are encrypted and the messages have integrity (i. e., have not been changed during transmission). In one embodiment, the registration process occurs over a secure channel using a protocol, such as, for example, https or the HTTPC. The HTTPC protocol is described in greater detail below in conjunction with Figure 6.

Referring to Figure 4, the process of registering begins with the home portal computer system generating a registration post request to the intermediary server (processing block 401). It should be noted that when the home portal computer system makes the registration post request, the home portal computer system knows the following (from the activation protocol process described above): the URL with which to register (e. g., the IP address of the intermediary server (e. g., nsl. companyname. com), the registration token (which in one embodiment is random and used only once) used by the intermediary server to match the session being facilitated, an ID of a shared key that is used for sharing transmissions, and its IP address (home portal computer system's IP address).

The home portal computer system makes a registration post request that includes a key ID, an IP address of the current connection, a port on which the application server on the home portal computer system is listening, a URI optional page on the home portal computer system to which the server is redirected, an indication of whether the SSL is on or off, agent and platform information (e. g., the agent version, and agent update request, a platform version, a platform update request), to enable the intermediary server to provide information to allow the home portal computer system the opportunity to update the agent and the platform version, and/or other data as required. The update requests allow the home portal computer system to indicate that it desires to get updates to applications its running (or capable of running).

The intermediary server generates a response to the registration post request (processing block 402). In one embodiment, the response includes a new key and key ID for the next connection (since the previous key is only used once and discarded).

Such a new key ID may not be offered or may be rejected by either party in alternative embodiments. In one embodiment, the intermediary server also provides the update link to the home portal computer system for updating the agent, platform, file browser, or any intermediary server application.

The response also includes the public certificate of the domain which is issued by a valid certificate authority. For example, the public domain could be *. c. companyname. com. The intermediary server registers the IP address received from the home portal computer system in a DNS server, where it is assigned a domain name consistent (user. c. companyname. com) with the certificate. In one embodiment, the certificate includes a public key as well as its domain name consistent with X. 509.

The home portal computer system also starts an application server, which will be used later, after a secure channel has been established, to enable the client browser to access files and applications available through the home portal computer system.

One benefit of the registration mechanism described above is that it is a reliable process to renew symmetric preshared keys. In one embodiment, the system always has multiple keys, and includes a slot for a new key and at least one successful key. The system holds onto the last successful key until a new one is used. Once the new one has been confirmed to be present on both the intermediary server and the home portal computer system, the previous key may be discarded. The registration process relies on the previous activation protocol which is responsible for the authentication of the home portal computer system. This process provides secure IP registration with messages that are text based.

After registration, the intermediary server redirects the client browser to the home portal computer system using the URL of the assigned fully qualified domain name.

Next the client browser connects to the home portal server in a secured manner (using HTTPs) using the URL provided by the intermediary server. To make the connection, the client browser contacts the DNS server and retrieves the numeric address associated with the domain name. Using a numeric address, the client browser is able to connect to a server on the home portal computer system.

A Secure Channel Figure 5 is a flow diagram of one embodiment of a process for negotiating an encrypted (private) channel between a browser and a home portal system. In one embodiment, this process is performed after authentication between the user and the home portal computer system has already been achieved. Prior to the process, the home portal computer system has a certificate from the intermediary server that was received during registration. An example is"*. c. companyname. com" and is issued by one of the browser built-in Certification Authorities. The certificate is public (e. g., freely available). Also, for the purposes of the process to obtain a secure channel, the home portal computer system possesses a preshared key that is used in the secure communications with the intermediary server.

Note that a portion of the process occurs over a secure line. The secure line may be achieved by using a protocol such as, for example, the https or HTTPC. Using an HTTPC protocol, which is described in greater detail below in conjunction with Figure 6.

Referring to Figure 5, the process for negotiating a secure channel between the browser and the home portal computer system begins by initiating an SSL handshake (processing block 501). In one embodiment, the SSL handshake is initiated by the browser sending a Client-Random (i. e., a random number) and a list of browser- supported cipher suites to the home portal computer system. A Client-Random is well- known in the art.

In response to initiating the SSL handshake, the home portal computer system replies by sending a Server-Random (i. e., a random number), an indication of a cipher form the list of cipher suites that the home portal computer system has agreed to use (e. g., RSA) and a digital certificate to the browser (processing block 502). A Server- Random is well-known in the art. In one embodiment, the certificate used conforms to the 509 standard.

Then, the browser formulates a pre-master secret (processing block 503). The pre- master secret is used to calculate the symmetric key that will be used to encrypt the ensuing session. In this step, the browser validates the certificate, calculates the pre- master secret using a Server-Random and Client-Random and encrypts the pre-master secret using the public which is included in the certificate that was passed previously.

The calculation of the pre-master secret using the Server-Random and the Client- Random is built into the browser. The browser then sends the encrypted pre-master secret to the home portal computer system.

Next, the home portal computer system sends a request and the encrypted pre- master secret to the intermediary server requesting the intermediary server to decrypt the encrypted pre-master secret received from the browser (processing block 504). It should be noted that the intermediary server maintains the unique private key that is paired with the public key of the certificate to perform the decryption. The home portal computer system does not maintain a copy of this private key. In one embodiment, the request for decryption is sent over a secure line.

After receiving the request, the intermediary server uses a private key which it maintains securely (to the exclusion of the home portal computer system) to decrypt the pre-master secret and sends the pre-master secret to the home portal computer system unencrypted (processing block 505). In one embodiment, the transmission of the key occurs over a secure link. The link may communicate over a link using a secure protocol, such as https or using the HTTPC protocol described below, to obtain its security.

At this point, the browser and the home portal computer system both posses the same pre-master secret. Using this pre-master secret, they independently calculate the bulk key to use in the cipher that was selected in the first phase of the handshake. The browser and the home portal computer system now can encrypt all the information that passes between them.

Note that the browsers is not an independent variable. The processes described herein operate within the predefined behavior that these browsers have for creating a secure channel. However, also note that processing blocks 501,503, and 505 are capable of being performed by any arbitrary browser.

It should be appreciated that each individual will not have their own certificate with key (e. g., public/private keys) because individual certificates are to difficult to manage and expensive.

The HTTPC Protocol HTTPC (cryptic http) protocol provides a secure protocol for directed communication between a home portal computer system and the intermediary server.

The term"secure"in this context refers to the fact that the messages are verified to be authentic, the messages being passed are encrypted, and the messages have integrity (i. e., have not been changed during transmission). In one embodiment, the authentication is provided by mutual authentication achieved by using pre-shared keys, the customer ID, and an HMAC-like algorithm as described above. Message integrity is also achieved through HMAC as described above.

In one embodiment, this process is a request response based process (stateless process).

In one embodiment, the secure protocol fits into an existing protocol such as HTTP. The security of the channel is based on cryptography. In one embodiment, the cryptography is based on a public key algorithm, such as, for example, DES. The cryptography that is employed reuses the existing infrastructure of the pre-shared keys from the activation protocol described above.

Figure 6 illustrates one embodiment of the HTTPC process. Referring to Figure 6, the process begins by an initiator generating a request to a respondent (processing block 601). In one embodiment, the request has a message format that includes an HTTP header, HTTP extension headers, and a message body. In one embodiment, the HTTP header includes a content length, the customer ID (as used in the activation protocol described above), the keyID to identify a pre-shared key, date & time, all of which including the encrypted message text are hashed into a message authentication code (MAC). This is computed according to the following: HMAC (k, date & time | customerID | encrypted text).

In one embodiment, the HTTP extension headers include an indication of the cipher that is currently being used. For instance, the cipher may include DES-CBC. In one embodiment, the message to be securely sent is encrypted using DEC-CBC using the key identified in the key ID section of the header. This key has already been pre- shared between the parties.

In response to initiator request, the respondent generates a response to the initiator (processing block 602). In one embodiment, the response includes a header and message body. In one embodiment, the header comprises an HTTP header. In one embodiment, the header includes a date & time and a message authentication code calculated according to the following: HMAC (k, date & time! customerID! encrypted response message).

In one embodiment, the message to be securely sent is encrypted using DEC- CBC using the key identified in the key ID section in the header of the received generic header request.

Whereas many alterations and modifications of the present invention will no doubt become apparent to a person of ordinary skill in the art after having read the foregoing description, it is to be understood that any particular embodiment shown and described by way of illustration is in no way intended to be considered limiting.

Therefore, references to details of various embodiments are not intended to limit the scope of the claims which in themselves recite only those features regarded as essential to the invention.

Thus, a method and apparatus for remotely accessing a computer using a web browser has been described.