* 11 *

Internet security

Fact of the week

In 2000, RSA securities web site was defaced by crackers, in what could have been a serious embarrassment for the well known security company. The crackers did not crack RSA's systems, however, but performed a spoof by attacking a DNS server "upstream" of RSA's domain. This shows how critical the problem of dependency is in security, and that security is not just the concern of those who have secrets to keep. It is a problem for society at large,

See Stallings chapters 6 & 7

Diffie-Hellman key exchange

One of the most secure ways of sending information is to use a one-time session key, i.e. a random encryption key which is unique to the session. To use a session key, one must first agree on that key, or inform both parties as to the value of the key. This problem of key distribution was difficult to make secure before the Diffie-Hellman algorithm.

Using the same prime number methods used by RSA, the Diffie-Hellmann key exchange algorithm offers a way of constructing a key at two separated locations, without actually sending the key over the network. This key exchange algorithm is central to many high security schemes.

Secure mail and S/MIME

Several mail transfer agents (MTA) such as sendmail v8.11 now support application level, point to point, encryption to prevent eavesdropping of mail: this is called START TLS and AUTH SMTP in which the entire SMTP session is encrypted.

The problem with the SMTP E-mail protocol, as implemented on many systems, is that it cannot handle non-ASCII data. This makes encryption or transmission of multi-media data files difficult. This is the reason for MIME (multi-purpose internet mail extension) attachments, which reencode data in ASCII symbols (like Unix uuencode/uudecode). Encryption systems for E-mail must therefore convert the data into an ASCII printable format.

Email content can be encrypted manually with PGP. A secure version of MIME (for transport of multimedia extensions), called S/MIME allows encryption and use of digital signatures.

SSL/TLS

The secure socket layer (SSL) was originally introduced by Netscape communications in order to allow secure web transactions. (HTTPS is SSL encoded HTTP). Version 3 of the protocol was extended with experiences and suggestions from other companies in the industry and was published as an Internet draft document standard. Transport layer security (TLS) is essentially an outgrowth of SSLv3, and it is intended that this will become a network industry standard.

SSL and TLS use public/private key methods to establish communications, security capabilities, and establish a session key. The protocol then authenticates both parties and negotiates a cheaper encryption algorithm and message digest to sign the message. Thereafter the cheaper encryption scheme is used, (e.g. 3DES,IDEA,RC4 etc).

SSL is designed to be a drop-in replacement for standard socket communication, easily implemented, with minimal investment on the part of the programmer. Roughly speaking, one simple replaces some system calls with library functions from SSL and the encryption should be transparent.

SET - secure electronic transactions

The Secure Electronic Transaction system was devised in response to the needs of VISA and MASTERCARD credit card companies in 1996. Several companies, including Microsoft, Netscape, IBM, RSA, Terisa and Verisgn contributed to the design. Whereas SSL/TLS is a system for generic stream transfer, SET is based on a specific transaction model, for payment of goods by credit card. The system is designed to ensure privacy, integrity and authenticity to all parties in a transaction (customer,merchant,bank).

SET makes use of a trusted third party certificate organization, who keep a database of user certificates for verification, similar to the registration of SSL sites by Verisign.

The SET model uses a system of dual signatures to maximize privacy. The merchant does not need to know a customer's credit card details; the bank does not need to know the details of the goods ordered from the merchant. Separate hashes are used for each part of the message. These signatures need to be combined, so that payment and goods-transaction are connected. However, they are combined in such a way that only the bank can verify its part of the signature and only the merchant can verify its part of the signature.

VPNs and S/WAN

The TCP/IP protocols were invented at a time when it was an unusual privilege to have access to the root/Administrator account, or own one's own network connection. The security of network communication was based on the assumption that ordinary users would not have access to the network traffic. Today everyone has access.

One of the problems with TCP/IP security is that passwords and other information are often sent in clear text (unencrypted) so that eavesdroppers could `sniff' the net and pick up the data.

A secure virtual private network (VPN) is an encrypted link between hosts, which acts as a tunnel or `armoured pipe' between a remote location and a service provider. There are many technical solutions to this problem, most are based on RSA style encryption, like ssh.

IPSec

Many problems in network communication would be easily solved if there were transport layer encryption of internet traffic. IPSec is a security system developed for use with IPv6, but it can also be implemented for IPv4 (RFC1636). It offers encryption at the IP level. This means that common TCP attacks, such as sequence guessing or spoofing attacks cannot occur, since attackers could never see the contents of travelling packets.

DNSSec

Solving the problem of secure communication allows us to have private and verifiable conversations between remote parties, but it does not prevent the possibility that we might be tricked into talking to the wrong person! In DNS cache attacks, crackers have been able to plant incorrect IP addresses, diverting a conversation to a host which then impersonates the host at the intended address. The problem with DNS database lookup is that DNS is a trusted database, but it trusted on very little evidence. Secure DNS (DNSSEC) attempts to cure this problem by using message digests and (public/provate key) digital signatures to verify the content of information.

Secure DNS attempts to guarantee the authenticity of the DNS records, to avoid the problem of spoofing. RFC 2535. It does not attempt to provide privacy for lookups (after all, the database is public knowledge), only integrity. It is a design principle that all users should obtain the same information when making the same lookup, i.e. that spoofing should be impossible.

DNS is probably the largest distributed database in existence. The problem of implementing a secure service, with updates and distribution all around the world, is a formidable one and the system is still being tested.

Computer warfare

Worms, viruses etc..