Posts Tagged ‘symmetric cryptography
TLS (Transport Layer Security) was released in response to the Internet community’s demands for a standardized protocol. The IETF provided a venue for the new protocol to be openly discussed, and encouraged developers to provide their input to the protocol.
The TLS protocol was released in January 1999 to create a standard for private communications. The protocol “allows client/server applications to communicate in a way that is designed to prevent eavesdropping,tampering or message forgery.” According to the protocol’s creators, the goals of the TLS protocol are cryptographic security, interoperability, extensibility, and relative efficiency.These goals are achieved through implementation of the TLS protocol on two levels: the TLS Record protocol and the TLS Handshake protocol.
TLS Record Protocol
The TLS Record protocol negotiates a private, reliable connection between the client and the server. Though the Record protocol can be used without encryption, it uses symmetric cryptography keys, to ensure a private connection. This connection is secured through the use of hash functions generated by using a Message Authentication Code.
TLS Handshake Protocol
The TLS Handshake protocol allows authenticated communication to commence between the server and client. This protocol allows the client and server to speak the same language, allowing them to agree upon an encryption algorithm and encryption keys before the selected application protocol begins to send data. Using the same handshake protocol procedure as SSL, TLS provides for authentication of the server, and optionally, the client.
a. Stolen Assertion
Threat: If an eavesdropper can copy the real user’s SAML (Security Assertion Markup Language) response and included assertions, then the eavesdropper could construct an appropriate POST body and be able to impersonate the user at the destination site.
Countermeasures: Confidentiality MUST be provided whenever a response is communicated between a site and the user’s browser. This provides protection against an eavesdropper obtaining a real user’s SAML response and assertions.
If an eavesdropper defeats the measures used to ensure confidentiality, additional countermeasures are available:
- The Identity Provider and Service Provider sites SHOULD make some reasonable effort to ensure that clock settings at both sites differ by at most a few minutes. Many forms of time synchronization service are available, both over the Internet and from proprietary sources.
- When a non-SSO SAML profile uses the POST binding it must ensure that the receiver can perform timely subject confirmation. To this end, a SAML authentication assertion for the principal MUST be included in the POSTed form response.
- Values for NotBefore and NotOnOrAfter attributes of SSO (Single Sign-On) assertions SHOULD have the shortest possible validity period consistent with successful communication of the assertion from Identity Provider to Service Provider site. This is typically on the order of a few minutes. This ensures that a stolen assertion can only be used successfully within a small time window.
- The Service Provider site MUST check the validity period of all assertions obtained from the Identity Provider site and reject expired assertions. A Service Provider site MAY choose to implement a stricter test of validity for SSO assertions, such as requiring the assertion’s IssueInstant or AuthnInstant attribute value to be within a few minutes of the time at which the assertion is received at the Service Provider site.
- If a received authentication statement includes a <saml:SubjectLocality> element with the IP address of the user, the Service Provider site MAY check the browser IP address against the IP address contained in the authentication statement.
b. Man In the Middle Attack
Threat: Since the Service Provider site obtains bearer SAML assertions from the user by means of an HTML form, a malicious site could impersonate the user at some new Service Provider site. The new Service Provider site would believe the malicious site to be the subject of the assertion.
Countermeasures: The Service Provider site MUST check the Recipient attribute of the SAML response to ensure that its value matches the https://<assertion consumer host name and path>. As the response is digitally signed, the Recipient value cannot be altered by the malicious site.
c. Forged Assertion
Threat: A malicious user, or the browser user, could forge or alter a SAML assertion.
Countermeasures: The browser/POST profile requires the SAML response carrying SAML assertions to be signed, thus providing both message integrity and authentication. The Service Provider site MUST verify the signature and authenticate the issuer.
d. Browser State Exposure
Threat: The browser/POST profile involves uploading of assertions from the web browser to a Service Provider site. This information is available as part of the web browser state and is usually stored in persistent storage on the user system in a completely unsecured fashion. The threat here is that the assertion may be “reused” at some later point in time.
Countermeasures: Assertions communicated using this profile must always have short lifetimes and should have a <OneTimeUse> SAML assertion <Conditions> element. Service Provider sites are expected to ensure that the assertions are not re-used.
Threat: Replay attacks amount to re-submission of the form in order to access a protected resource fraudulently.
Countermeasures: The profile mandates that the assertions transferred have the one-use property at the Service Provider site, preventing replay attacks from succeeding.
f. Modification or Exposure of state information
Threat: Relay state tampering or fabrication, Some of the messages may carry a <RelayState> element, which is recommended to be integrity protected by the producer and optionally confidentiality- protected. If these practices are not followed, an adversary could trigger unwanted side effects. In addition, by not confidentiality-protecting the value of this element, a legitimate system entity could inadvertently expose information to the identity provider or a passive attacker.
Countermeasure: Follow the recommended practice of confidentiality and integrity protecting the RelayState data. Note: Because the value of this element is both produced and consumed by the same system entity, symmetric cryptographic primitives could be utilized.
The DARPA Quantum Network aims to strengthen QKD’s performance in these weaker areas. In some instances, this involves the introduction of newer QKD technologies; for example, we hope to achieve rapid delivery of keys by introducing a new, high-speed source of entangled photons. In other instances, we rely on an improved system architecture to achieve these goals; thus, we tackle distance- and location independence by introducing a network of trusted relays. Whereas most work to date has focused on the physical layer of quantum cryptography – e.g. the modulation, transmission, and detection of single photons – our own research effort aims to build QKD networks. As such, it is oriented to a large extent towards novel protocols and architectures for highly-secure communications across a heterogenous variety of under lying kinds of QKD links.
Figure 1. A Virtual Private Network (VPN) based on Quantum Key Distribution
Our security model is the cryptographic Virtual Private Network (VPN). Conventional VPNs use both public-key and symmetric cryptography to achieve confidentiality and authentication/integrity. Public-key mechanisms support key exchange or agreement, and authenticate the endpoints. Symmetric mechanisms (e.g. 3DES, SHA1) provide traffic confidentiality and integrity. Thus VPN systems can provide confidentiality and authentication / integrity without trusting the public network interconnecting the VPN sites. In our work, existing VPN key agreement primitives are augmented or completely replaced by keys provided by quantum cryptography. The remainder of the VPN construct is left unchanged; see Fig. 1. Thus our QKD-secured network isfully compatible with conventional Internet hosts, routers, firewalls, and so forth.
At time of writing, we are slightly over one year into a projected five-year effort to build the full DARPA Quantum Network. In our first year, we have built a complete quantum cryptographic link, and a QKD protocol engine and working suite of QKD protocols, and have integrated this cryptographic substrate into an IPsec-based Virtual Private Network. This entire system has been continuously operational since December 2002, and we are now in the process of characterizing its behavior and tuning it. In coming years, we plan to build a second link based on two photon entanglement, and to build various forms of end-to-end networks for QKD across a variety of kinds of links. We expect the majority of our links to be implemented in dark fiber but some may also be implemented in free space, either in the labor outdoors.