1. Endpoint Vulnerabilities in SSL/TLS Systems

Most implementations of SSL assume that the client computer is a secure environment for key negotiation, key storage, and encryption. This is untrue in principle and in practice, as malicious technologies such as Spyware, KeyJacking, and Man in the Browser have proven to be able to circumvent SSL by obtaining sensitive data prior to encryption.^[1][2] Furthermore, the reliance on the host PC for PKI certificate validation renders the infrastructure vulnerable to man-in-the-middle attacks.^[3]

1.1. Challenges for Public Networks

Traditional solutions to endpoint security rely on custom protocols or proprietary authentication architectures that are not interoperable with SSL. In many circumstances, particularly in anonymous or distributed environments where interoperability with SSL is a requirement, synchronization of client and server systems with a proprietary security protocol is simply not feasible. This is known as the Endpoint Security Problem in public networks.

In layman's terms, the Endpoint Security Problem essentially asserts that any anonymous transaction through a web browser must inherently be at risk, and that it cannot be fixed without removing the anonymity of the transaction. Since virtually all web transactions assume that the client is anonymous at the protocol level,^[4] this means that any proposed third-party solution will essentially break the system.^[5] This is a fundamental vulnerability that undermines the entire web security infrastructure, rendering virtually ever web transaction at risk.

Dynamic SSL solves this fundamental problem by focusing on transparently closing the implementation vulnerabilities rather than on redefining a new protocol. Therefore, the existing SSL system remains intact as the default secure communication protocol. However, implementation vulnerabilities are solved to achieve endpoint security.

2. Principles of Dynamic SSL

The underlying principle in Dynamic SSL is that encryption of sensitive information cannot be performed in an untrusted environment, such as most personal computers, where the security of the encryption process could be compromised. Rather, encryption of sensitive information must be done outside of the personal computer. Dynamic SSL assumes that the end user's computer is an untrusted environment, and can only be used as the channel to transmit sensitive information. Dynamic SSL thus guarantees the security of sensitive data by ensuring that it is never present in the insecure environment.

3. Implementations

Typical implementations involve two core components: a secure environment which hosts the sensitive data to be protected, and a cryptographic proxy, which securely redirects the encryption of the host process of the insecure environment to a cryptographic provider within the secure environment which hosts the sensitive data. An optional third component which controls the tokenization process can be inserted at the application layer. Nothing is required at the server end.

Generally speaking, the only change which is required on the endpoint computer is the replacement of the default SSL cryptographic provider with a Dynamic SSL cryptographic proxy. Most operating systems and web browsers support pluggable cryptographic providers, meaning that most implementations will require no changes whatsoever to the application on either end of the system.

Dynamic SSL works by using a tokenization system for sensitive data in conjunction with secure redirection of cryptographic operations to a secure environment. For example, rather than typing in your online banking password into a web browser, you would type in a meaningless token instead. When the form is submitted, an HTTP request containing the token is generated, and sent to the SSL cryptographic provider for encryption and secure transmission to the remote server. Instead of the encryption happening on the host PC, which may be compromised, the session is redirected to the secure environment (secure input device, server, etc..) which would contain your real online banking password. Inside the secure environment, the token within the HTTP request would get swapped out with your real online banking password at the moment of encryption. The encrypted packet, containing your real online banking password, would then be returned to the SSL system of the host PC for transmission to the remote server.

From the server's perspective, the request appears like any other regular keyed-in request. The packet was encrypted with the SSL session key negotiated with the client, and so is able to decrypt and process the packet as normal. It cannot tell the difference between a regular SSL transaction and a Dynamic SSL transaction.

The only difference in the transaction was that the sensitive data was never present on the host PC. Any malicious attempt to harvest the data from the host PC would be unable to locate the data.

4. Strengths and Weaknesses

Dynamic SSL is the only known approach to endpoint security that requires no changes to existing server systems, and can therefore be used to transparently retrofit existing systems for endpoint security, while retaining the benefits of using a proven standard like SSL. By offloading cryptographic operations to a secure environment which acts as the point of origin for sensitive data, thereby ensuring the endpoint computer does not have access to said sensitive data, proactive protection from endpoint threats can in theory be achieved.

However, since Dynamic SSL is simply a process that is applied to SSL implementation, rather than a new protocol, it remains vulnerable to protocol vulnerabilities inherent within SSL, namely Man-in-the-Middle attacks.^[6] Sharifimehr has proposed a supplementary solution involving Man-in-the-Middle Protection for Dynamic SSL.^[7] His algorithm uses a combination of redundant cert verification and key tagging to prevent Man-in-the-Middle attacks and Keyjacking. Most known implementations of Dynamic SSL include Sharifimehr's additional process, described below:

4.1. Man-in-the-Middle Protection

Known valid root certificates are digitally signed by an independent third party. When an X509 certificate arrives containing the authentication information for a remote website as part of the SSL authentication phase. Since the root certificate signatures are redundantly verified in a secure environment against a pre-verified list of valid digital signatures for known valid root certificates, this prevents any compromise via tampering of the certificate authentication chain. Phony certificates or certification chains can therefore be detected and the session rejected before it begins.

4.2. Keyjacking Protection

Session and authentication keys are contextually bound to the operations which they are semantically required to perform, and may not be exported. An encryption key may not be exported and used to decrypt the ciphertext which is encrypted. In laymans terms, keys are "tagged" to ensure that they can never be exported for use outside of their intended use.

5. Commercial Applications

A consumer product called SmartSwipe is the first known commercial application of Dynamic SSL. It claims to provide security against malware and other client-side attacks while providing universal support for virtually every eCommerce merchant that uses SSL.^[8] It is currently unknown whether other products are using this technology.