Patent Publication Number: US-8973111-B2

Title: Method and system for securing electronic transactions

Description:
RELATED APPLICATIONS 
     The present application is Continuation of U.S. application Ser. No. 13/035,830 filed on Feb. 25, 2011 (to issue on Jun. 18, 2013 under U.S. Pat. No. 8,468,582) which is a Continuation-in-Part (CIP) of the U.S. application Ser. No. 12/639,464 for “Network Transaction Verification and Authentication” filed on Dec. 16, 2009, which claims priority from the following US provisional applications: 61/248,047 filed on Oct. 2, 2009; 61/247,223 filed on Sep. 30, 2009; 61/183,830 filed on Jun. 3, 2009; 61/149,501 filed on Feb. 3, 2009, the entire contents of which are incorporated herein by reference. 
     The present application also claims benefit from 61/416,270 filed on Nov. 22, 2010, the entire contents of which are incorporated herein by reference. 
    
    
     FIELD OF THE INVENTION 
     The invention relates generally to network security systems. More particularly, the invention relates to a system and method for verifying the identity of a user and establishing a secure and mutually trusted connection within a public telecommunications network. 
     BACKGROUND OF THE INVENTION 
     On-line web-based services are widely used in today&#39;s society, a typical example being on-line banking services. However, problems associated with transaction security have caused serious challenges and risks to institutions and their customers. The increase in identity theft and the resulting financial losses have become major obstacles that institutions have sought to overcome to ensure a secure on-line environment and to maximize the potential benefits and value of on-line services. 
     In a global economy with billions of transactions carried daily over insecure public Internet Protocol (IP) networks, identity protection becomes paramount. Commerce transactions are based on the trust that each party places in the integrity of the other&#39;s credentials. The resultant proliferation of identity systems is forcing individuals to become their own identity administrators. 
     Organizations are increasingly vulnerable to substantial economic loss from cyber security attacks. In the case of an information security breach, financial institutions in particular can be exposed to a significant financial loss, as well as a loss of reputation. In general, the customer computer environment is considered to be insecure with potential for a variety of malicious software to be inserted, such as keystroke recorder, Trojan horse, or even screen recorder, etc., able to record a customer&#39;s keystrokes, redirect critical messages to a fake server, or to effectively “video record” the customer computer&#39;s screen (buffer). By using a variety of means, hackers are able to steal customer&#39;s identities. Even worse, local sessions can be hijacked and critical data modified. 
     Current solutions are largely aimed at improving the network communication security aspects (even though the actual network communication links are secure enough—as long as man-in-the-middle attacks and the like are prevented). However, the bigger problem lies in detecting and preventing attacks on communications within the client platform itself. 
     The shortcomings of the current systems apply to personal computer clients running browsers, as well as to personal hand-held digital assistants, ‘smart-phones’, and like network client devices. 
     Authentication 
     The traditional way to authenticate a customer is to provide a user name and password from the customer&#39;s client computer. However, this one-factor (e.g. user-id+password) authentication is not secure enough to protect either the customer or the institution from attack by malicious software or malware (including ‘Trojan horses’) using approaches such as man-in-the-middle (MITM), man-in-the-browser (MITB), and keystroke logging. 
     A man-in-the-middle (MITM) attack is one in which the attacker intercepts messages in a public key exchange and then retransmits them, substituting his own public key for the requested one, so that the two original parties still appear to be communicating with each other. 
     Man-in-the-browser (MITB) is a security attack where the perpetrator installs a Trojan horse on a victim&#39;s computer that is capable of modifying that customer&#39;s web commerce transactions as they occur in real time. A man-in-the-browser attack, unlike “phishing”, can occur even when the victim enters the Uniform Resource Locator (URL) into the browser independently, without an external prompt. On the surface, commerce transactions take place normally with expected prompts and password requirements. An MITB attack is more difficult to prevent and disinfect, however, because the activity, instead of occurring in an interchange of messages over the public network, takes place between the customer and the security mechanisms within that customer&#39;s browser or client computer. 
     Two-factor authentication (TFA) is a security process in which the customer provides two means of identification, one of which may be a physical token, such as a card, security token or Universal Serial Bus (USB) device, and the other is typically something memorized, such as a security code. In this context, the two factors involved are sometimes spoken of as “something you have” and “something you know”. 
     Although TFA improves the authentication security, its implementation tends to lead to a costly system. In many TFA systems today, the verification of both the physical token and the security code are conducted at a remote authentication server. This approach may require separate protocols to authenticate the physical token identifier and the customer security code. Since a centralized authentication server must deal with large volumes of on-line commerce transactions at the same time, this approach also results in scalability issues. 
     Transaction Authentication Numbers 
     In addition to the two factor authorization (TFA) systems mentioned earlier, some on-line banking services use a transaction authentication number (TAN). This takes the form of one time passwords (OTP) to authorize financial transactions. The list of TANs is therefore an additional factor. TANs provide another layer of security above and beyond traditional authentication. 
     An Outline of how TANs Function
         1. The bank creates a set of unique TANs for the customer.   2. The customer picks up the list from the nearest bank branch. This is deemed to be secure.   3. The customer receives a password by mail to the customer&#39;s home address.   4. To log on to his/her account, the customer enters a user name and password as normal. This gives access to certain account information but the ability to process transactions is disabled.   5. To perform a transaction, the customer enters the request and “signs” the transaction by entering an unused TAN. The bank verifies the TAN submitted against the list of TANs they issued to the customer.   6. The TAN has now been consumed and will not be recognized for any further transactions.   7. If the TAN list is compromised, the customer may cancel it by notifying the bank.
 
In some scenarios TANs provide additional security by acting as another form of two-factor authentication. If the physical document containing the TANs is stolen, it will be of little use without the password. On the other hand, if a hacker cracks the customer&#39;s password, they can not process transactions without the TAN.
       

     The risk of compromising a TAN list can be reduced by using algorithms that generate TANs on-the-fly, based on a secret known by the bank and stored in the token or a smartcard inserted into the token 
     Thus as increased security has become more critical, the customer is faced with increased complexity and the need to remember several procedures, not to mention user names, passwords, and other security codes or PINs, in order to carry out on line transactions, particularly commerce transactions. This has the effect of discouraging potential customers. In some cases, customers compromise the security of their transactions by reusing passwords, or writing them down, or worse, saving them in a file on their computer for ease of recall/reference. 
     Factors that require to be addressed include: 
     
         
         
           
             Customer perception of complexity; 
             Customer concerns with security; 
             Merchant reduction of loss by fraud; 
             Scalability; 
             Managing the process(es); 
             Balancing usability with security; 
             Minimizing impact on customer computing platform; 
             Minimizing impact on merchant computing platform; and 
             Migration from existing to new system. 
           
         
       
    
     What is needed is a further development of a flexible and simple identity protection and authentication system and method combined with transaction verification ability that could be used across several service providers, and would be able to accommodate complex identity relationships, and provide ways to eliminate or mitigate common security vulnerabilities, at the same time allowing a complex task to appear simpler to the customer, for example by hiding the complexity under a simple GUI. There is also a need for stronger identity credentials providing better protection from tampering, and enabling safer high-value and sensitive transactions in areas such as health-care, and banking operations. 
     SUMMARY OF THE INVENTION 
     There is an object of the present invention to provide a system and method for securing electronic commerce transactions, in particular, a system and method for verifying the identity of a user and establishing a secure and mutually trusted connection within a public telecommunications network, which would avoid or mitigate shortcomings of the prior art as discussed above. 
     According to one aspect of the invention, there is provided a method for secure electronic transaction over a computer network, comprising: 
     at a trusted relationship profile server computer operably connected to the computer network: 
     (a) storing a unique identity of a trusted computing unit; 
     (b) generating a confirmation message regarding the unique identity of the trusted computing unit in response to a request from the trusted computing unit; 
     at a computer operably connected to the computer network and comprising a security proxy server, having computer readable instructions stored in a computer readable storage medium for execution by a processor: 
     (c) storing real credentials and local credentials of a customer in a secure vault; 
     (d) receiving the confirmation message and permitting a login process to be performed with the security proxy server using the local credentials, provided the confirmation message is valid; and 
     (e) replacing the local credentials submitted in the login process with the real credentials. 
     In the embodiments of the invention, the steps (c), (d) and (e) of the method are performed at a security proxy server computer, and the steps (c), (d) and (e) are performed at a computer of the customer comprising the security proxy server. 
     The step (a) of storing the unique identity of the trusted computing unit comprises storing a unique identity of a portable security device. 
     The method further comprises modifying a login password entered in a login process to a transaction server computer to produce a modified login password, based on the credentials of the portable security device. For example, the modified login password may comprise the login password appended with at least a part of the credentials of the portable security device. 
     The method further includes completing the login process to the transaction server computer with the modified login password. 
     The method further comprises completing the electronic transaction with the trusted computing unit at a transaction server using the real credentials. 
     In the method described above, the storing the unique identity of the portable security device comprises storing a unique identity of one or more of the following: a cellphone, a smart phone, and a personal portable computing device having a further computer readable storage medium having computer readable instructions stored thereon for executing by a further processor for communicating with the security proxy server. 
     According to another aspect of the invention, there is provided one or more computer readable storage media having computer readable instructions stored thereon for execution by a processor, for performing a method for secure electronic transaction over a computer network, comprising: 
     at a trusted relationship profile server computer operably connected to the computer network: 
     (a) storing a unique identity of a trusted computing unit; 
     (b) generating a confirmation message regarding the unique identity of the trusted computing unit in response to a request from the trusted computing unit; 
     at a computer comprising a security proxy server, having computer readable instructions stored in a computer readable storage medium for execution by a processor, the computer being operably connected to the computer network: 
     (c) storing real credentials and local credentials of a customer in a secure vault; 
     (d) receiving the confirmation message and permitting a login process to be performed with the security proxy server using the local credentials, provided the confirmation message is valid; and 
     (e) replacing the local credentials submitted in the login process with the real credentials. 
     According to yet another aspect of the invention, there is provided a computer-based system for providing security for an electronic transaction over a computer network, comprising: 
     a) a trusted relationship profile server computer operably connected to the computer network, the computer having a first processor and a first computer readable storage medium having computer readable instructions stored thereon for executing by the first processor, storing a unique identity of a trusted computing unit; the trusted relationship profile server computer having a message generator unit for generating a confirmation message regarding the unique identity of the trusted computing unit in response to a request from the trusted computing unit; 
     b) a security proxy server operably connected to the trusted computing unit, the security proxy server having a second computer readable storage medium having computer readable instructions stored thereon for executing by a second processor, comprising: 
     (i) a secure vault, storing real credentials and local credentials of a customer in the secure vault; 
     (ii) a message confirmation unit receiving the confirmation message from the message generator unit and permitting a login process to be performed with the security proxy server using the local credentials, provided the confirmation message is valid; and 
     (iii) a message parameter replacement unit for replacing the local credentials submitted in the login process with the real credentials. 
     In the system described above, a computer of the customer comprises the security proxy server; or the trusted computing unit comprises the security proxy server. The trusted computing unit includes a portable security device, for example, a flash memory device. The portable security device is configured to be connected to a computer of the customer. 
     The system further includes a transaction server computer operably connected to the computer network, the transaction server computer having a computer readable storage medium having computer readable instructions stored thereon for executing by a processor for completing the electronic transaction with the trusted computing unit. 
     The trusted computing unit comprises a portable computer-based device comprising one or more of the following: a cellphone, a smart phone, and a personal portable computing device having a further computer readable storage medium having computer readable instructions stored thereon for executing by a further processor for communicating with the security proxy server. 
     In the system described above, the secure vault further comprises computer readable instructions for storing credentials of the portable security device, and the security proxy server further comprises a password replacement unit, modifying a login password entered in a login process with the transaction server computer to produce a modified login password, based on the credentials of the portable security device. For example, the modified login password may comprise the login password appended with at least a part of the credentials of the portable security device. 
     The system further includes a transaction server computer operably connected to the computer network, the transaction server computer having a computer readable storage medium having computer readable instructions stored thereon for executing by a processor for completing the login process with the transaction server computer with the modified login password. 
     Thus, an improved method and system for verifying the identity of a user and establishing a secure and mutually trusted connection within a public telecommunications network have been provided. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Illustrative embodiments of the invention will be described with reference to the drawings, in which: 
         FIG. 1A  depicts a prior art implementation of an authorization system; 
         FIG. 1B  depicts a prior art implementation of a client computing platform; 
         FIG. 2  illustrates an embodiment of a previous invention, using a physical trusted device; 
         FIG. 3  shows a trusted device for use in an embodiment of the previous invention; 
         FIG. 4  shows the prior art situation wherein the ‘weak link’ extends from the network to the user; 
         FIGS. 5 ,  5 A and  5 B illustrate an architecture in which a system for securing electronic transactions using embodiments of the invention has been implemented; 
         FIG. 6  shows a message sequence diagram for the registration phase of embodiments of the present invention; 
         FIG. 6A  shows a flowchart for the registration phase of embodiments of the present invention; 
         FIG. 7  shows a message sequence diagram for the IP address updating phase of the embodiments of the present invention; 
         FIG. 7A  shows a flowchart for the IP address updating phase of the embodiments of the present invention; 
         FIGS. 8 and 9  show message sequence diagrams for the login and payment phases of the embodiments of the present invention; 
         FIGS. 8A and 9A  show flowcharts for the login and payment phases of the embodiments of the present invention; 
         FIG. 10  shows details of parts of the architecture in which a system for securing electronic transactions using embodiments of the invention has been implemented; 
         FIGS. 11A and 11B  illustrate a merchant agent module  910  of  FIG. 10  in more detail;  FIGS. 12 and 13  show message sequence diagrams illustrating examples of message sequences executed according to various embodiments of the invention for logging on to a transaction server and completing a payment transaction; 
         FIGS. 12A and 13A  show flowcharts illustrating logging on to a transaction server and completing a payment transaction; 
         FIGS. 14 and 15  show message sequence diagrams illustrating examples of message sequences executed according to various embodiments of the invention for changing and using two-factor passwords with a transaction server; and 
         FIGS. 14A and 15A  show flowcharts illustrating yet another embodiment of the invention using two-factor passwords. 
     
    
    
     DETAILED DESCRIPTION OF EMBODIMENTS THE INVENTION 
     All trademarks herein are property of their respective owners. 
     Throughout the following description the use of Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), or equivalent capabilities, is assumed. These are cryptographic-based protocols that provide for secure communications on the Internet for web browsing and other forms of data transfer. Those of ordinary skill in the art will appreciate that embodiments of the invention may make use of these (or equivalent) secure communication protocols, although they are not necessary in understanding the invention. Their detailed operation is therefore omitted. 
     In the following description, some messages between elements of the system, for example, between servers and customers computers pertaining to the request for and display of web pages, are omitted in the interests of clarity. 
     The present invention may be embodied in a variety of computer hardware and software configurations. The term server refers to a computer-based system having a processor and computer readable storage medium having computer readable instructions stored thereon for executing modules of the present invention. The term “computer-based” as used herein, refers to any machine or apparatus that is capable of accepting, performing logic operations on, storing, or displaying data, and includes without limitation processors and memory; the term “computer software,” or “software,” refers to any set of instructions operable to cause computer hardware to perform an operation. A “computer,” as that term is used herein, includes without limitation any useful combination of hardware and software, e.g. a general purpose or a specialized computer, and a “computer program” or “program” includes without limitation any software operable to cause computer hardware to accept, perform logic operations on, store, or display data. A computer program is comprised of a plurality of smaller programming units, including without limitation subroutines, modules, functions, methods, and procedures having computer readable instructions stored in a computer readable storage medium such as memory, DVD, CD-ROM or else, for execution by a processor. Thus, the functions of the present invention may be distributed among a plurality of computer-based systems and computer programs. 
     The systems and architectures illustrated in the  FIGS. 5 ,  10  and  11  comprise computer program modules having computer readable/executable instructions stored in a computer readable storage medium such as memory to be executed on one or more computer-based systems, each having a processor. Alternatively, the modules may be implemented in hardware. 
     For comparison with the present invention, we first describe one instance of the prior art systems, illustrated by  FIG. 1A . Typically such systems comprise a customer&#39;s client computing platform or device (customer&#39;s computer)  100 , containing software, including a web browser  105 , to permit communication with a web server (also called a Transaction Server) computer  120 , also to be referred to as Transaction Server  120 , maintained by an ‘on-line service provider’, sometimes referred to as ‘institution’, ‘enterprise’ or ‘merchant’. An institution may include on-line institutions that require secure, authenticated and trusted communication between the institution and its customers. Such institutions may include, for example, a bank, health care provider, or other sites with sensitive or personal information. A merchant may provide goods and/or services in exchange for payment. The browser  105  is also able to communicate with a third party web server computer  130 , capable of authenticating a physical token  110 , which can be operably connected to the client computing platform  100  over a local communications link  150 . It will be appreciated that the physical token  110  does not need to be physically connected to the client computing platform  100 . Instead, the authentication information of the physical token  110  may be input into the client computing platform  100  in other ways, such as using wireless communications. Communication between the client computing platform  100  and the web servers  120 ,  130  takes place over a network, such as the Internet  160 , using an appropriate communication protocol, for example, the Internet Protocol (IP). The customer&#39;s identity is authenticated by the customer inputting a personal identification number (PIN)—the User ID  140 . 
       FIG. 1B  depicts a typical prior art computer architecture of a customer&#39;s computing platform, in which embodiments of the present invention may be implemented or used. The client computing platform  100  contains one or more processors (CPU)  172  connected to an internal system bus  173 , which interconnects random access memory (RAM)  174 , read-only memory  176 , and an input/output adapter  178 , which supports various I/O devices, such as printer  180 , disk units  182 , USB devices  184 , or other devices not shown, such as an audio output system, etc. System bus  173  also connects with a communication adapter  186  that provides access to external communications link  188 . User interface adapter  194  connects various user devices, such as keyboard  190  and mouse  192 , or other devices not shown, such as a touch screen, stylus, or microphone, to the system bus  173 . Display adapter  196  connects the system bus  173  to display device  198 . 
     Those of ordinary skill in the art will appreciate that the hardware in  FIG. 1B  may vary depending on the system implementation. For example, the system may have one or more processors, and one or more types of volatile and non-volatile memory. Other peripheral devices may be used in addition to or in place of the hardware depicted in  FIG. 1B . The depicted examples are not meant to imply architectural limitations with respect to the present invention. 
     Embodiments of the present invention may be implemented in a variety of software environments. An operating system may be used to control program execution within each platform or device. For example, the computing platform  100  may run one, or more, different operating systems, such as Windows®, Mac OS®, Linux®, Android®, Web OS®. The client computing platform  100  may include, or be based on, a simple Java® run-time environment. A representative computer platform may include a browser such as Internet Explorer®, Firefox®, Safari®, Opera®, or Chrome®, which are well known software applications for accessing hypertext documents in a variety of formats including text files, graphics files, word processing files, Extensible Markup Language (XML), Hypertext Markup Language (HTML), Hand-held Device Markup Language (HDML), and various other formats and types of files. 
     A prior application to the same assignee, Ser. No. 12/639,464 filed on Dec. 16, 2009 for “NETWORK TRANSACTION VERIFICATION AND AUTHENTICATION”, the entire contents of which are incorporated herein by reference, describes a two-level security verification system, which makes use of the architecture illustrated in  FIG. 2 . In  FIG. 2 , in contrast with the prior art shown in  FIG. 1A , there is no need for a third party server  130  for authentication of the physical token  110 . Instead, the trusted device  300  has attributes and features, which differentiate it from the physical token  110  used in earlier systems. The trusted device  300  includes a trusted proxy service, which may be implemented by code stored in a memory of the trusted device  300 . When the trusted proxy service is implemented, for example, by executing the code of the trusted proxy service by the processor  172  of the client computing platform  100 , it configures the client computing platform  100  to provide a proxy web server  210 . The client computing platform  100  also includes a web browser  105  or other means for accessing a network location, such as an institution web (transaction) server  120 , maintained by an on-line service institution. A User ID  140  may be received at the browser  105  and used to authenticate a customer&#39;s access to the trusted device  300 . The trusted device  300  may be connected to the client computing platform  100  over a local communication link  150 , such as a wired or wireless connection. The client computing platform may be connected to the institution web server via a network  160 . The browser  105  accesses the institution web server through the proxy web server  210  in order to provide a trusted communication path between the customer&#39;s client computing platform  100  and the institution transaction server  120 . 
     A block diagram of a trusted security device  300  described in the parent patent application Ser. No. 12/639,464 filed on Dec. 16, 2009, cited above, is schematically shown in  FIG. 3 . A Global Unique ID (UID)  310  may be created and stored in the device  300 . The UID  310  may be stored in encrypted form. The UID  310  is used to uniquely identify the trusted security device  300 , in order to ensure that a customer physically has the trusted security device  300  when accessing the institution web server. 
     In the parent patent application Ser. No. 12/639,464 cited above, the Global UID  310  is generated by an algorithm that is capable of taking device identity information, such as information that is hard-coded into computing hardware of the trusted security device  300 , and possibly other data, for example, a customer selected personal identifier (PIN), as its input, and producing the UID as its output. Various software and data elements may also be present in the trusted device  300 , including a database  320  and trusted proxy service software  330  that implement the proxy web server  340  when executed. These elements may be present as data and instructions stored in a memory of the trusted device. The trusted device  300  is logically connectible to the client computing platform  100  over the local communication link  150 . The local communication link  150  is a Universal Serial Bus (USB) interface, although other connections are possible. 
     The database  320  and the trusted proxy service software  330  may be used to store access credentials of a network location of an institution and access the network location on behalf of the browser  105  using the stored access credentials. As a result, a customer does not need to enter their institution access credentials into the browser  105 . 
     Embodiments of the present invention further improve and expand on those earlier implementations of the parent patent application Ser. No. 12/639,464 filed on Dec. 16, 2009, cited above. The present application protects commerce transactions between customers and on-line service providers, in which there is a two-way exchange requiring both authentication and the offered level of security/protection. The effect is to extend the trust boundary from the Internet into the end user device, and in effect, to the user interface. 
     One analogy is an ATM, in which that device serves as a trusted user interface between the customer and the enterprise (e.g. a Bank). However, in the present invention, the interface requires no specialized equipment, but rather the trust is provided through functional modules, which conveniently may be implemented in software, and through interaction between the functional modules. 
     Note that customers may be internal to an enterprise, and commerce transactions may not have direct monetary value, but nonetheless be of high value to the enterprise. 
     Securing commerce transactions of this nature makes use of “Identity and Trust as a Service” (ID/TaaS). Generally, ID/TaaS protects electronic transactions between the customer and the enterprise, relying on a security service provider (which may be the enterprise itself) for specific trust-improving functions. Such transactions require identity data that is managed by the security service provider. The trust-improving functions include, but are not limited to, registration, identity verification, authentication, management of credentials and their life-cycle, and, management of roles and entitlement. Some or all of these functions may be provided by a third-party. 
     The embodiments of the present invention provide for varying levels of trust (or security) protection. 
     In the  FIG. 4 , a typical prior art situation is illustrated, where entire local connections  400  from the customer computers  100  to the network ‘cloud’, web, or public network  402 , constitute “weak links” in terms of their vulnerability to the various forms of attack on security as discussed earlier. 
     Secure Access 
       FIG. 5  illustrates embodiments of the invention where security and authentication functions are provided by a Security Proxy (SP)  502  in conjunction with a Trusted Relationship Profile Server (TRPS)  503  computer having a processor and memory, also to be referred to as TRP server  503 , that is under the control of a security service provider. In the embodiments of the invention, the term Security Proxy  502  will be used for both a security proxy computer having a processor and memory, and for security proxy software instructions stored in a computer readable memory for execution by a processor. A trusted portable security device  604  is operably connected to the Security Proxy (SP)  502  to form a trusted computing unit  101 . In some embodiments the portable security device  604  is a flash memory device, but other technologies are possible. In some embodiments a USB link  103  is used to connect the trusted portable security device  604 , but other means are possible. The Security Proxy (SP)  502  provides features somewhat analogous to those in a firewall, but in the security domain, and may be implemented at a router or other local access point, or, in some embodiments, in the customer&#39;s portable computer-based device, which will be referred to as the Trusted Personal Device,TPD, in this application. The security proxy  502  comprises a Vault  1090 , to be also referred to as Secure Vault  1090 , a Message Checking Unit  1064 , and a Password replacement unit  1095 , each comprising computer readable instructions stored in a computer readable storage medium for execution by a processor. The Security Proxy  502 , together with the Portable security device  604  constitute a Trusted Computing Unit  101 . The “weak links”  400  are now restricted to the internal links between the security proxy  502  and the customer&#39;s computers  100  across the LAN  501 . We call this Secure Access. 
     Connections are made across the web  402  via the Security Proxy (SP)  502  to Transaction Servers (TS)  120 . 
     In some embodiments, illustrated in  FIGS. 5A and 5B , the various elements are configured differently. 
     In  FIG. 5A , the customer&#39;s network is reduced to a single computer  101 A, operably connected to the Web  402 . The customer&#39;s computer  100  contains the security proxy  502  software stored in a memory of the computer  100 , and is operably connected to the Portable security device  604 , which together become the trusted computing unit  101  which is connected via a modem or router (not shown) to the web  402 , and thereby carry out transactions with the Transaction Server  120 , and interact with the TRP server  503  and a message generating unit  504  comprising computer readable instructions stored in a computer readable storage medium for execution by a processor. 
     In  FIG. 5B , the customer&#39;s Portable Computer-based device  102 , such as cell phone, smart phone or similar device having a processor and a computer readable storage medium, is used to access the Security Proxy  502  (and hence the Trusted Computing Unit  101 ), and thereby carry out transactions with the Transaction Server computer  120  having a processor and memory, to be also referred to as Transaction server  120 , and interact with the TRP server  503  and the message generating unit  504  over the web  402 . In this configuration some elements of the trusted computing unit  101  may reside in the portable computer-based device  102 , making use of the SSL capabilities to secure the connections across the Web  402 . In some embodiments the unique identity of the Portable Computer-based device  102  may replace the unique identity of the Portable Security device  604  as illustrated in the following descriptions. 
     In the following descriptions, the invention is described with reference to  FIG. 5 , but those skilled the art will recognize that the description will also be applicable to configurations of  FIGS. 5A and 5B , as well as other like combinations. 
     As mentioned above, it will be recognized that the Security Proxy  502  may be either a computer, having a processor and memory, or a computer-readable storage memory having instructions stored thereon for execution by a processor. 
     Enhanced Network Secure Access 
     A further level of security provides for enhanced protection during the completion of certain high-value on-line transactions. In this context high-value refers to transactions whose value is agreed by the parties involved to be worth extra protection. In the following a transaction using a credit card is described, but other like identity credentials might be used. 
     Referring once more to  FIG. 5 , embodiments of the invention introduce functions at the Security Proxy (SP)  502  that intercept and modify messages passed between the LAN  501  and the web  402 . The SP  502  performs the functions of Secure Access described above, but in addition processes messages sent between the user browser (not shown) in the trusted computing unit  101  and a Transaction Server (TS)  120 , typically run by a bank, vendor or merchant. In embodiments of the invention no changes are required at the Transaction Server  120 , although some optional enhancements may be made. The principle of replacing “real” identity credential data, in this case credit card numbers, with internally generated local versions is extended. This Enhanced Network Secure Access provides advantages similar to those for Secure Access, extending them to commerce transactions. 
     Thus, in both scenarios the Security Proxy  502  and the Trusted Relationship Profile Server computer  503  provide a trustworthy intermediary service for transactions over the public network. 
     The trusted relationship profile server computer  503  knows a unique identity of a trusted computing unit  101  and has a message generator unit  504  that generates a confirmation message regarding the unique identity of the trusted computing unit  101  to respond to a request from the trusted computing unit  101 . The security proxy computer  502  has a secure vault  1090  in which are stored real identity credentials and the corresponding local identity credentials. The SP  502  also has a message confirmation unit  1064  that receives the confirmation message from the message generator unit  504  and permits a login process to be performed with the secure proxy  502  using local identity credentials provided the confirmation message is valid. A message parameter replacement unit  1095  in the security proxy  502  replaces the local identity credentials submitted in the login process with the real identity credentials. 
     More details of the embodiments of the present invention are now described with reference to the  FIG. 5 , as well as  FIGS. 6 and 7 , which show message sequence diagrams, and  FIGS. 6A and 7A , which show flowcharts of the various phases of a transaction:
         Registration ( FIGS. 5 ,  6  and  6 A)   Address/Location updating ( FIGS. 7 and 7A )   Secure commerce transactions over the public network       

     Once the necessary software modules of the invention are installed in the customer&#39;s computer and other computer-based elements (such as router, laptop, USB drives, portable computer-based devices, and other digital devices) within the LAN  501  to add the Security Proxy (SP)  502  and related functionality, the Security Proxy (SP)  502  must be made aware of the various security credentials and other data (local and real) used to complete transactions, by initially adding them into the account manager and the secure vault. The process involves the creation of a Web Account, which contains local and real data as well as providing for any relationships between such data, for example:
         a local identity (also known as a global user identity or user name),   a local password (also known as a global password),   unique identity data stored in customer devices, including simple USB portable security devices and Trusted Personal Devices   translation to (real ID, real password) from (local ID, local password),   translation to real customer identity credential information from local customer identity credential information.       

     The Web Account therefore provides the information needed to replace local ID and password with the real ID and password. It also makes use of more credential-related data in the form of service names and identity credential (e.g. credit card) information as described in embodiments of the invention. In some embodiments multiple customers are supported, where each customer may have a Web Account. 
     Registration 
     The registration phase is described with reference to  FIGS. 5 ,  6  and  6 A. Registration is a communication interaction involving the customer&#39;s browser  105  (implemented in the customers computer  100 ), the Security Proxy (SP)  502 , a Trusted Relationship Profile Server (TRPS)  503 , and an operably connected trusted portable security device  604  (within the trusted computing unit  101 ), capable of storing data. This interaction is required before a first secure transaction with a Transaction Server  120 . Messages are carried over the LAN  501  and the web  402  as appropriate. Other similar communication interactions may take place later to allow for changes to the identity credentials, for example if the customer changes a computing platform or portable security device  604 . These changes are much less frequently performed than the transaction phase, and this allows implementation without the daunting scaling issues of existing secure transaction services. 
     Note that registration is not possible using remote access. 
     The message sequence diagram of  FIG. 6  and flowchart of  FIG. 6A  show how information is transferred between the customer&#39;s browser or equivalent application  105 , the Security Proxy (SP)  502  and a Trusted Relationship Profile Server (TRPS) computer  503 , also to be referred to as a TRP server  503 . For illustrative purposes, the procedures are described using a Registration module (not shown) within the SP  502  stored in a computer readable storage medium, and a USB connected trusted portable security device  604 , although other environments and devices may be used, including but not limited to a web browser applet, a security-enabled smart-phone, a desktop computer, a laptop computer or any digital storage device. In such environments and devices, the portable security device may include a general purpose or specialized computer having a processor and computer readable storage medium having computer readable instructions stored thereon for executing modules of the present invention. 
     The process starts by the customer connecting the portable security device  604  containing identifying data to the Security Proxy  502 , and, using a small application (not shown) in the Customer&#39;s computer  100  inputting some other sign-on credentials. Once an HTTP-based (or equivalent, such as HTTPS-based) session has been established between the Registration module in the SP  502  and the TRPS  503 , the customer is asked to input their credentials  608 , and an incomplete internal Registration-Request message  610  is generated  609  containing the sign-on credentials. The Security Proxy SP  502  intercepts the message  610  and accesses hardware information by reading  611  information in the USB trusted portable security device  604 . The information from the USB trusted portable security device  604  is combined  612  with the sign-on credentials from the message  610 , and a full external Registration-Request message is assembled  613  and passed  620  to the Trusted Relationship Profile Server  503 . 
     At the Trusted Relationship Profile Server  503 , the credentials within the message  620  are examined and verified  621  by comparison with the registration key in a database  603 . An external Registration-Response message is generated  622  and forwarded  630  to the SP  502 . Information from the response is stored  631  into a local Trusted Relationship Profile (TRP)  606  for future use, and an internal Registration-Response message generated  632  and sent  640  to the Registration module within the browser  105  to confirm success. The database  603 , the Trusted Relationship Profile  606  and the registration module within the browser  105  comprise computer readable instructions stored in a computer readable storage medium for execution by a processor. 
     At this point the Secure Access is ready for use by the customer, in both local and remote locations, through the Security Proxy (SP)  502 . 
     Address/Location Updating 
     However, in some Internet environments, particularly domestic ones, a further step is required in order to ensure that the IP address of the SP  502  is kept updated since it is subject to change. In contrast, the TRPS  503  is located in the network cloud (or web)  402  with a static public address and domain name. Therefore the TRPS  503  naturally becomes the co-ordination point for a remote customer and associated Secure Access point or Security Proxy (SP)  502 . For illustrative purposes, one solution is described below. Other solutions are also possible. 
     In some embodiments a Device Identity is generated by the Security Proxy  502 . This Device Identity relates a particular combination of credentials with the Transaction Server  120  that is assigned a customer-generated Service Name. Such a combination of Service Name and Device Identity constitutes a Security Subscription. A Security Subscription is generated for each device/transaction server pair. 
     As shown in the  FIGS. 7 and 7A , the SP  502  initiates  701  the process, periodically generating  719  and sending an Address-Report message  720 , for each Security Subscription, containing the Device Identity and the customer generated Service Name to the TRPS  503 . The periodicity is not critical, but must be sufficiently frequent to reduce the chances of the IP address update being unacceptably delayed to a very low level. The process should be initiated whenever the IP link is restarted; the subsequent periodicity is configurable. 
     By its nature, the message header of the Address-Report message  720  contains the (WAN IP) address of the SP  502 . TRPS  503  uses an address updating module  721  to access the record for the SP  502  within its database  603 , associating it using the Service Name and the Security Proxy Device Identity, and updates the Security Proxy IP address within its database  603 . The Service Name is selected to be significant to the customer. Typically it is formatted like a Domain Name to further hamper and confuse any attempt to capture the information at the user computer. 
     Later, the customer (through an application, typically a browser  105 ) generates  723  an Address-Request message  730  to the TRPS  503 . The message  730  contains the customer-generated Service Name (alias). The identity of the SP  502  is known from the Service Name and its Device Identity, and the TRPS  503  uses an IP address retrieval module  722  to access the database  603  to provide the required real IP address of the SP  502  to generate  725  an Address-Response message  740 . 
     The trusted computing unit  101  uses a connection map updating module  741  to update a map of Connections (not shown), which relates Service Name to the updated SP IP address. Now it can start to establish the connection to the SP  502  within the LAN environment; this is the ‘home’ location. A Login Request message  750  containing the device PIN and a One Time Password is generated  742  by the browser  105 , and the SP  502  uses a validation module  751  to confirm their validity and generate  719  a corresponding Login Response message  760 . 
     The following cases, referring to  FIG. 5 , give further examples of Secure Web Access features and advantages of embodiments of the present invention. 
     For simple secure web access, the customer is required to login to the Security Proxy  502 . This process requires the customer to be in possession of the registered portable computer-based device (not shown in  FIG. 5 , but designated by reference numeral  102  in  FIG. 5B ) such as a laptop, smart-phone, etc. known to the Security Proxy  502 , and connected to the Security Proxy  502  over the LAN  501 . Only after the login is successful can the customer continue their secure web access through the Secure Access point namely the Security Proxy  502  and associated Portable Security device  604  which comprise a Trusted Computing unit  101 . 
     In some embodiments of the invention the user accesses the LAN  501  over the web  402  from a portable computer-based device (not shown), such as a smart-phone, connecting first with the Trusted Relationship Profile Server  503  to obtain the IP address of the LAN  501 , connecting to the Trusted Computing Unit  101  and, after authentication, performing subsequent transactions as though connected directly to the LAN  501 . In these embodiments the portable computer-based device  102  has a further unique identity, which is known to the TRP server  503  and the Security Proxy  502 . 
     As shown in the  FIGS. 8 and 8A , using a browser application or equivalent  105 , the customer initiates  801  access to a Transaction Server  120  by generating  802  an internal Web-Login message  810  containing parameters (Local user ID and Local password) that is intercepted by the SP  502 , which uses a parameter conversion module  815  to obtain the parameters to the real user ID and real password, from data stored within an Account manager module (not shown) of the SP  502  and creates  816  an external Web-Login message  820 . 
     In some embodiments, for additional security, the SP  502  checks the sender&#39;s IP address and rejects the message if the IP address is different either from that previously used in the present session by the customer device, or differs from that registered as being the current IP address of that device. Otherwise, the external Web-Login message  820  is created and forwarded  826  to the Transaction Server  120  as normal. The parameters in the message  820  are checked by the Transaction Server  120  using a transaction parameter checker module  825  with its database (not shown), and the Transaction Server  120  responds with a Web-Login-Response message  830 . Since there are no parameters in this message, it is passed  840  by the SP  502  directly to the user&#39;s browser application  105 . 
     Secure on-Line Commerce Transactions 
     Following a series of messages (not shown) which result in the need for a payment (monetary) transaction, the customer may choose  902  to pay using, for example, a credit card. As shown in the  FIGS. 9 and 9A , the request for this is the internal Checkout message  850 , generated  904  within the browser application  105 , and containing the customer&#39;s Local Credit ID. The message is intercepted by the SP  502 , which uses a Credit card ID swap module  855  to replace the Local Credit ID with the Real Credit ID using data stored in the secure Vault  1090  and forwards  856  the amended external Checkout message  860  to the TS  120 , which performs its normal transaction processing activities  865  before sending  866  the appropriate Checkout-Response message  870 . Since there are no parameters, this message is passed by the SP  502  directly  880  to the customer&#39;s browser application  105 . Note that the use of a credit card in this situation is illustrative, and other identity credential information is also possible. 
     In some embodiments, for trusted on-line commerce transactions requiring a higher level of security, the merchant provides a TAN module, (not shown), typically in the form of an application Plug-in, in the SP  502 . For each transaction, the TS  120  sends a token number. In response the TAN module produces a new trusted token number (TTN) which is received at the TS  120 . If the trusted token number (TTN) is validated by the TS  120 , the transaction is trusted. 
     A further illustrative embodiment provides for establishing a trusted transaction environment between an on-line customer and multiple on-line service institutions. This is a form of Web Single Sign On (WSSO) which co-ordinates and integrates customer sign-on functions and customer account management functions for multiple institutions. Among other benefits, WSSO improves security through the reduced need for a customer to handle and remember multiple sets of authentication information. 
     In some embodiments a certification procedure is provided to further enhance the security of vulnerable weak links. 
     It should be noted that in embodiments of the present invention the location of each of the modules described here and interconnected by the Transmission Layer  1040  is subject to much variation, provided only that the Security Proxy Authentication Platform must be attached directly to the LAN at the home location. 
     Embodiments of the present invention, which establish a trusted transaction environment, are further illustrated with reference to the  FIGS. 5 and 10  in which are shown the major modules involved. Authentication Module (or Login)  1000 , which resides in the trusted computing unit  101 , has an Authentication User interface (AUI)  1010  that provides for registration of the customer through a Register module (RM)  1020 , and management of several customers and their devices through an Identity Manager module (IDM)  1030 . Also included in the authentication module  1000  is a Password manager (PM)  1032  for the management of passwords used to access the web server  120 . The authentication Platform  1050  of the Security Proxy  502  also includes a Message Confirmation Unit (MCU)  1064  for receiving confirmation of identity of the portable security device  604  from the message generator unit  504  of the TRP server  503 . 
     The AUI  1010  is connected by an appropriate Transmission Layer  1040 , to an Authentication Platform (AP)  1050 , which resides in the Security Proxy  502 . The AP  1050  comprises modules performing the following functions:
         Two factor authentication module (TFA)  1060 ;   Device verification module (DV)  1070 ;   Account Management module—including device registration and updating of IP addresses and other parameters (AM)  1080 ;   Secure storage of private data (secure Vault)  1090 ;   Support of multiple merchants using WSSO—Merchant agent module (MA)  910 ;   A Message Parameter Replacement Unit  1095  supports parameter replacement in messages from the authentication module  1000  directed to the web server  120 ; and   A Password Replacement Unit  1096  supports the management of passwords through the Password Manager  1032 .       

     In addition, a process for ensuring that the IP address of the SP  502  is sent regularly to the TRPS  503  is provided as described earlier. 
     Messages from other major modules sent over the Transmission Layer  1040  are directed to the appropriate module within the security proxy  502  by a Packet Inspector (PI)  1110 . 
     A browser or equivalent application  105 , having several different instances (e.g., windows or tabs)  1210 , is also shown communicating with the Authentication Platform AP  1050  over the Transmission Layer  1040 . 
     All modules and units shown in  FIG. 10  comprise computer readable instructions stored in a computer readable storage medium such as memory, DVD, CD-ROM or similar storage medium, for execution by a processor. 
     Web Single Sign On 
     We now further explain the two factor authentication (TFA) procedures, using Web Single Sign On (WSSO) as an example, referring first to the  FIG. 10 , in which the block  100 A, comprising an Authentication module  1000  and a Browser module  1210  is a module within the customers computer  100 , and the authentication platform  1050  is a module within the Security Proxy  502 . The first phase of the procedure requires messages between the AUI ID manager module  1030  within the Login module  1000 , and the AP Device Verification module  1070  and Two Factor Authentication module  1060  within the Authentication Platform AP  1050 . This local authentication phase ensures that the customer can authenticate against the Trust Relationship Profile TRP  606  previously forwarded by the TRP Server  503  and stored in the secure Vault  1090  of the Authentication Platform  1050  of the Security Proxy  502 . 
     In another phase the procedure requires messages between the Browser  105 , the AP Account Management module  1080 , and the merchant&#39;s Transaction Server (TS)  120 . Only following successful local authentication can the Authentication Platform secure Vault  1090  of the Security Proxy  502  be opened and the Account Management module  910  intercept web login messages and arrange for the Message Parameter Replacement unit (PRU)  1095  to correctly replace the local login credentials with the real ones in the messages to the TS  120 . 
     To illustrate the stage following successful creation of a Trust Relationship Profile TRP  606  and its storage in the Authentication Platform secure Vault  1090  we now refer also to  FIGS. 12 and 12A . After connecting to the relevant Transaction Server  120  (using HTTP and the browser  105 —message(s) not shown) a (HTTP) login page message  1202  is received  1203  by the Login module  1000 . The customer provides a PIN  1210  and a Login-Request message  1204  containing the PIN is generated and sent  1211  to the SP  502 . The SP  502  also reads  1220  the credentials of the customer&#39;s USB portable security device (not shown) and once the credentials have been verified  1230  against the TRP  606  (held in the Authentication Platform secure Vault  1090 ), a login Response message  1206  is generated  1231  and returned to the Login module  1000 . At this time, the secure vault  1090  can be opened with the extracted secret key from TRP. 
     Thus, the Login page displayed by the web browser  105  as a result of receiving a login page (HTTP) message  1202  is an ordinary-looking Login ID form that the customer “fills in” with local Alias credentials. 
     Using the browser or equivalent application  105 , an alias Login ID is inputted  1240 , and a simple “single factor” (eg UserID with password) internal Login-Request  1208  initiated by the customer is intercepted by the Security Proxy  502  that examines its database A/C  1270  of account information relating to the customer (held in the Authentication Platform Vault  1090 ), and using the Message Parameter Replacement unit  1096 , replaces  1250  the alias to create  1251  an external Login-Request  1212  with the real ID and passes it to the Transaction Server  120 . 
     Once the Transaction Server  120  has sent its Login-Response  1214  to the web browser  105 , the transaction proceeds normally until the checkout process begins. 
     In some embodiments of the present invention, the system and method are enhance to permit a plurality of merchants or other enterprises to make use of the service defined by the invention, in some cases provided by a third party. This is a form of “Identity as a Service” (IdaaS) described above. The  FIG. 11A  shows a Merchant Agent module  910 , which resides within the Security Proxy  502  as part of the Authentication Platform  1050 , having a User Interface  915  and a plurality of TTN generating modules  920 , one for each of a plurality of merchants  905  that the platform supports. As depicted in the  FIG. 11B , each TTN generating module  920  is able to generate a new TAN&#39; (or TTN)  930  independently to replace the dummy TAN  925  in messages sent from the web browser. The algorithm to generate the TTN within each TTN generating module  920  is provided during an initialization phase following registration. 
     All modules and units shown in  FIGS. 11A and 1  lB comprise computer readable instructions stored in a computer readable storage medium such as memory, DVD, CD-ROM or similar storage medium, for execution by a processor. 
     In some embodiments, the device ID of the customer related Two Factor Authentication TFA process is incorporated in the message to the merchant&#39;s transaction server for additional verification of the customer&#39;s identity. 
     Other embodiments add authentication methods in various combinations to further increase the assurance level of security and authentication. 
     As previously mentioned, the level of security is enhanced as needed for high-value transactions. One example of a high-value transaction is checkout. The procedure is described with reference to the  FIGS. 13 and 13A . 
     As in the previous example, after connecting to the relevant Transaction Server  120  (using HTTP and the browser  105 —message(s) not shown) a (HTTP) login page message  1202  is received  1203  by the Login module  1000 . The customer inputs a PIN  1210  and a Login-Request message  1204  containing the PIN is generated and sent  1211  to the SP  502 . The SP  502  also reads  1220  the credentials of the customer&#39;s USB portable security device (not shown) and once the credentials have been verified  1230  against the Trust Relationship Profile TRP  606  (held in the Vault  1090 ), a login Response message  1206  is generated  1231  and returned to the Login module  1000 . 
     At the end of the transaction processing  1271 , during which items are selected for purchase, for example, the Transaction Server  120  sends a Checkout page (not shown) containing a dummy Transaction authorization number (TAN). An internal Transaction-Request message  1216  is generated  1215  containing that dummy TAN and sent to the Transaction Server  120 , the Security Proxy  502  intercepts the internal Transaction-Request message  1216 . After replacing the dummy TAN with a real Trusted Transaction Number TTN generated from the associated merchant agent module  910  (step  1280 ), which is expected from the Transaction Server  120 , the SP  502  creates an external Transaction-Request message  1218 . The TTN is generated in real-time using a trusted TAN generator module provided by the merchant. The Transaction Server  120  provides a Transaction-Response  1222  (as normal). The transaction, having been validated, concludes normally (not shown). 
     As before, if the expected TTN is not found and the original TAN is visible, then the customer does not use the trusted platform for the transaction. In this case, more attention is needed based on policy. If neither TAN or TTN are provided for the Transaction-Request message, the transaction must be rejected. 
     In some embodiments, to verify the trust status of any login and to verify that users are indeed authorized users, a server-end password regime is implemented including a two-factor password assigned to the user. This two-factor password comprises a simple login password modified by a portable security device-linked extension. The two parts of the two-factor password verify the trust status of any access to the secured transactions since the presence of the portable security device-linked extension confirms that the portable security device is present in the system at time of log-in. The portable security device-linked extension to the two-factor password is never exposed to the browser and is used automatically when the user attempts to log-in to secured applications. 
     The  FIG. 10  shows the elements related to verification of the trust status of the login. The Password Manager  1032  performs the normal functions of updating and verifying passwords in collaboration with the web server  120  and the Password Replacement Unit  1096  contained in the Authentication Platform  1110  of the Security Proxy  502   
     The  FIGS. 14 and 14A , together with  FIGS. 5 and 10  show how the two-factor password is synchronized with web server (or transaction server)  120  using a familiar-looking “Change-Password-Request” web API. The password manager  1032  is invoked  1401 , the old and new passwords are entered by the user  1403 , to generate and send  1405  an internal Change Password request message  1410  containing both the old simple password and a new login password. At the Security Proxy  502  the packet inspector  1110  directs the message  1410  to the Password Replacement Unit  1096  where the new login password comprising two parts, the old simple password, a first part, and a second part, based on the credentials and identity of the Portable Security Device  604  previously stored in the Trust Relationship Profile TRP  606  within the secure Vault  1090  are used to modify the message  1410  to become an external Change Password request  1420  which is generated and forwarded  1415  to the transaction server  120 . Following normal protocol, the transaction server  120  responds appropriately with a Change Password Response message  1430  which goes to the Password manager  1032  by way of the Security Proxy  502  without modification. 
     The  FIGS. 15 and 15A , together with  FIGS. 5 and 10  illustrate the use of the two-factor password at the start of a transaction, in which the new simple password is used to log into the remote web server  120 , and this new simple password is converted to the two-factor password by the Security Proxy  502 . Since this two-factor password is synchronized at the web server  120 , log in is successful. The procedure begins after a normal Login page (not shown) is displayed at the browser  105 . The user fills in their credentials including the new password, and a login Request message  1510  is generated  1505  by the browser  105 . At the Security Proxy  502  the packet inspector  1110  directs the message  1510  to the Password Replacement Unit  1096  where the new login password is modified by the addition of an extension based on the credentials of the Portable Security Device  604  previously stored in the Trust Relationship Profile TRP  606  within the secure vault  1090 . In other embodiments, the modification of the simple password to a new password may be made by extending, replacing part or parts of the simple password or performing any logical or mathematical processing on the simple password. The internal message  1510  is thus modified  1515  to become an external Login request  1520  containing the new login password and forwarded  1516  to the transaction server  120 . Following normal checks  1525 , the transaction server  120  responds appropriately with a Login Response message  1530  which goes to the browser  105  by way of the Security Proxy  502  without modification. The browser  105  displays  1535  the appropriate page and processing proceeds normally, Login having been successfully completed. 
     This two-factor password system and method can be used by enterprises to provide a simple two-factor authentication without the user necessarily being aware of the mechanism. 
     In some embodiments having two-factor passwords, the old simple password, that is the first part of the two-factor password, is replaced at the security proxy  502  by a system generated password which is then stored in the secure vault  1090  for future use and combined with the portable security device-linked extension, the second part. In these embodiments the simple password generated and provided by the user is in effect a token or placeholder.
 
Other Embodiments
 
     Embodiments of the invention provide for incorporating the Security Proxy  502  functionality within a personal computer, rather than within a router or modem. This is particularly suitable for simpler environments and also during transition stages where not all routers or modems support the functionality of the SP  502 . 
     Embodiments of the invention, by providing for User Identities, allow several users, having different identity and other credentials, to make use of the same computer infrastructure using different registered devices. 
     In some embodiments, the secure sign-on and other transactions are internal to the enterprise: Then the customer may be an employee of the enterprise or another enterprise, and LAN may be at a place of business of the enterprise or another enterprise. In these embodiments the secure sign-on and other transactions are valuable and require the trustful nature of embodiments of the invention, even though they may not involve direct financial transactions and settlement. 
     The embodiments of the present invention use security features combined in a unique fashion to allow merchants and other service providers to provide a highly secure (and therefore low risk) transaction infrastructure that does not allow the web-based (remote) nature of the situation to interfere with the apparent simplicity of the transaction, making it comparable to a face-to-face situation. 
     In the embodiments of the present invention the customer&#39;s real identity credential data, such as passwords, credit card numbers, and user-ids, are used only in the connection within the security enhanced (e.g. using TLS) web  402 , e.g., between the SP  502  and the TS  120 . “Local” (or alias) customer identity credentials in the form of internally generated versions are used within the “weak link”  400 , i.e. the LAN  501  and the applications environment of the trusted computing unit(s)  101  attached thereto. These local identity credentials are translated by the SP  502  into the real identity credentials, protected by extra levels of security introduced and controlled by the embodiments of the invention. Thus, no useful credential data can be captured within the LAN  501  environment by malicious software; the Security Proxy  502  in cooperation with the trusted relationship profile server provides a trusted intermediary function between the LAN and the web. 
     The embodiments of the present invention, although described largely in terms of software modules having computer readable instructions stored in a computer readable storage medium for execution by a processor, residing in particular hardware entities, may be implemented in hardware and in combinations of hardware and software and such modules may reside in other hardware entities. 
     For greater certainty, all software modules or units described in this application comprise computer readable instructions stored in a computer readable storage meduim, such a memory, DVD, CD-ROM or the like, for execution by a general purpose or specialized processor. Alternatively, functionality of these modules can be implemented in specialized hardware. 
     In some embodiments the trusted transaction data is sent to a separate server for further verification, thereby avoiding the need to make changes in the transaction server. 
     In some further embodiments real time transaction monitoring is implemented. In such embodiments, when a transaction is submitted, the SP  502  intercepts the data and re-displays it back to the user before sending the data out to the transaction server. Only when the user confirms the integrity of the data will it be sent to the transaction server. This process defeats the so-called session hijack attack. 
     While embodiments of the invention have been described by way of example, modifications and equivalents will suggest themselves to those skilled in the art, without departing from the scope of the invention as defended in the appended claims.