bill’s blog

In very simple terms jurisdiction deals with the where, what and who of law. It is who has authority over a particular area. Many people equate jurisdiction to a specific locality such that a police officer can’t arrest someone outside of his/her jurisdiction. While this is one of its meanings it is also true that the authority can be with regard to a subject matter or a specific person/s.

Jurisprudence is more nebulous in nature. It deals of the why and how of law. It is the studying/theory of law.  It is determination of whether or not laws are needed in the first place. Are the laws that are created morally sound? In which circumstances laws need to be applied. What kinds of punishment if any need to be apply in those circumstances?

Unfortunately, law and cyberlaw in particular isn’t simple.

With the increase of usage and the daily dependence on the Internet, laws need to be created to deal with the types of crime that can be committed via this new medium. The media seems focused on the really big issues such as virus outbreaks and identity theft but there are less spectacular issues to deal with such as e-commerce, denial of service attacks and corporate espionage.

Laws protect a citizen’s rights. Cyberlaw is extensions of the laws that already exist and protect citizens in the physical world. Additionally, new laws need to be enacted that deal with the technology driven aspects of the Internet.

One of the main problems when dealing with cyberlaw is that different countries have different options on what is right and what is wrong. Many people the world over have a very basic sense of right and wrong. Deciding that every question is where jurisprudence comes into play. Jurisdiction needs to be established. One example that is often citied is the United State’s First Amendment rights to free speech. Many countries do not have this right and have laws that restrict what can be said/published.

Should Americans be able to publish information that is restricted in other parts of the world? Jurisprudence.
Should Americans be put on trail because they published “restricted” information on their web site? Jurisdiction.
What about their First amendment rights? Jurisprudence.
Who considers the information restricted? Jurisdiction.

Complicated? To say the least!

As I mentioned in the last installment, the real problem with PKI is the distribution of keys. This week we’ll explore some of the ways keys are managed. There are several methods to distributing keys. They breakdown into four categories:

1. Public announcement
2. Publicly available directories
3. Public-key authorities
4. Public-key certificates

So let’s take a closer look at the four.

Public announcement

This method requires the user to manage and distribute their own keys. It works well in so far as if I want to communicate securely with an individual all I have to do is ask for their key.  To a certain extent this creates a problem… Are you really ‘communicating’ with the individual you intend? Anyone can create a public key and publish it as someone else. There is no verification that the individual’s key is truly that on the individual. Sure this is a possibility BUT if an individual presents you with their key and you use it to encrypt your data and send it back to the same email address you got it from you can be reasonable sure that you are communicating securely with the individual that sent you the key. It may or may NOT be the individual whose name is attached to the key. I know from past experiences, that the more people consistently ‘publish’ their key (whether it is appended to emails or USENET postings), the more you can trust that the key is for the intended individual. Why? Check your emails and their postings… Is the key always the same? YES? NO? Care is always required when communicating over insecure mediums. Get to know the individuals you are dealing with. This method however doesn’t really do when dealing with an unknown individual. PGP solves this problem through its ‘Web of Trust’. This is where one individual signs the key of other known and trusted individuals. Eventually, as the web grows, individual keys will be signed and trusted by others you trust. Unfortunately, this solution doesn’t scale very well.

Publicly available directories

This solution scales a bit better. It relies on a trusted third party having control over which keys get published to these directories. Individual can publish their keys to a publically available server. Additionally it has the benefit of offering a more secure solution BUT certain requirements are necessary to achieve this!  The question still remains… How are users registered to the directory securely, as well as providing proof they are who they say they are. This would allow users who have never communicated secure before to send encrypted data. One of the problems with public keys is that they can be set to expire after a specific period of time. Additionally, key could be compromised and need to be revoked. Searching USENET posting and old emails could provide expired or revoked keys. Public Directories could eliminate this problem. They would have revocation notices. Users would be able to search for individuals a number of different ways.

Public-key authorities

In this scenario, users must have the public key to the server. In theory, this could provide a much more secure environment because all users need to be allowed access and are considered part of the ‘club’ (directory).  This is because all users in the club ARE trusted! Users can trust they are getting valid keys because they are part of the organization. This may work in corporate environments where keys can be controlled…  In practice, this is no more secured that using the ‘web of trust’. The directory is the trusted third party verses trust you have in others you know ‘personally’ to verify the validity of an unknown users key! The only real difference between this arrangement and a publicly available directory is that the transfer of keys is encrypted as well. The downside to this method is the high overhead!  At minimum seven messages are required in order to encrypt and deliver the data.

Public-key certificates

Now we are talking… This is the most attractive scenario of the lot! In this method… Users are provided keys/certificates that are issued by a trusted third party. In all the previous scenarios, the users themselves can create the keys. Here the user appeals to a certificate Authority of their keys. Very often the CA’s are installed as part of the base OS and thus certificates issues by these third party CA are trusted by default. The downside here is that users need to be a where of the methods that these Certificate Authorities use to establish trusts and to what extent the trust is implied. In actuality, anyone with access to an email account can get a certificate. As long as the ‘owner’ of the account has access to the email address trust can be established. As anyone who has ever set up a gmail account knows…. This doesn’t prove that I am indeed the name on the email address. All it does is establish that the person requesting the certificate is indeed using the email address that is trusted! Practically speaking, we normally establish trust based on the fact the we converse with someone… they give use their email address… we converse some more using said email address… thus the email address MUST belong to that individual. There are a lot of assumptions made here. More times than not this is a valid assumption BUT sometimes it’s not. Due diligence is ALWAYS required on the Internet! 

Just wanted to say… To anyone that’s following my postings… Merry Christmas!

Public-key cryptography or asymmetric cryptography, is a form of cryptography in which one key is used to encrypt your data and a different key is used to decrypt it. The keys set is broken down into a public key and a private key. The private key is always kept a secret and is never distributed. The Public key as its name implies can be freely distributed. The keys are related mathematically, but one can not derived from the private key from the public one and vice versa. Public-key cryptography addresses two real issues:

1.    Confidentiality
2.    Non-repudiation

In the first case, individuals wanting to transmit confidential data can encrypt the data with the recipient’s public key. Data encrypted with this key can only be decrypted with the corresponding private key. Hopefully, the owner has properly secured their key.  The data in this scenario is actually encrypted! The only problem is that you need to have the public key for every individual you wish to send encrypted data to.

In the second case, individuals wanting to prove that the data in question was actually sent by them would sign the message with their private key. Then anyone who is in possession of the sender’s public key can verify that data was sent by the individual claiming to be the owner. In addition, the recipient can verify that the data has not been tampered with (proving authenticity).  It is interesting to note that the data signed by the individual’s private key is NOT encrypted.  The data being sent is hashed and than the hash is signed with the sender’s private key.

The main problem with this form of cryptography is that one needs to get access to the public key.  Additionally, one must trust that the key is truly from the actual individual claiming ownership. Trust is everything here! In practice there are two ways to deal with this:

1.    Public-Key Infrastructure (PKI)
2.    “Web of Trust”

Both methods rely on the use of a trusted third party.

Public-Key Infrastructure (PKI) relies on the use of a more formalized method of a Certificate Authorities (or CA). These certificate authorities guarantee the ownership of the key pairs. Some of the larger well-known CAs are Thawte, Verisign, Entrust, DigiCert and GoDaddy. These Certificate Authorities provide various levels of security and assurances. It is generally believe that these Certificate Authorities can and should be trusted. Many operating systems vendors (Microsoft, Apple, etc) bundle the CA’s Root Certificates along with their offerings. This makes the process much easier on the end user. It should be noted that any organization can become it’s own Certificate Authority.  In this case, all hosts/individuals looking to trust/use certificates created by the CA must have the its root certificates installed.

The other way to ensure authenticity of keys is through PGP’s “Web of Trust”. In this method anyone can generate a key. Again the problem is a matter of trust.  If you know the individual that the key belongs to is easy to trust the key, BUT what if you never met the individual. Well one way to solve this problem is the ‘six degrees for separation’. Six degrees of separation refers to the idea that, if a person is one step away from each person they know and two steps away from each person who is known by one of the people they know, then everyone is an average of six “steps” away from each person on Earth (wikipedia.org, 2008). This being said, surely we can find someone, who knows someone, who knows the person we’re looking for! The Web of Trust consists of individuals that sign the keys of other individuals that they know and trust. For example:

Bill trusts Joe AND Joe trusts Lucas THEN Bill can trust Lucas.

This may is a bit over exaggerated but the idea is that if I know and trust someone then I can trust the people they know and trust. Extreme care is needed not to turn the ‘Web of Trust’ into a modern day version of Facebook were casual acquaintances are simply accepted at face value. Individuals need to be scrutinized and vetted out.

Resources:

Various, (2008, November 22), Six degrees of separation, Retrieved on December 3, 2008 from http://en.wikipedia.org/wiki/six_degrees_of_separation

KDC or Key Distribution Centers is a service that runs to help with the distribution of cryptographic keys. One on the major drawbacks to encryption keys is the distribution of the keys. In order to facilitate a more manageable infrastructure, KDCs are set up as a trusted source for retrieving keys. Symmetrical keys are use in the establishing of encrypted links between locations. The hardest part of symmetrical keys is the initial exchange of the 1st key. Once the initial exchange has happen the encrypted link can pass additional keys a required. To a certain extent asymmetrical keys have solved this problem as users can freely publish their public keys. The downside to asymmetrical keys (other than they serve a different purpose) is that the encryption takes place between two individuals.

One implementation of a KDC can be found in the Kerberos protocol. It was designed to provide secure authentication over insecure networks. The Kerberos process can be broken down into 3 steps:

1. AS Exchange (User Authentication) – This is where the client machine begins the process of getting a ticket to be used to access network resources. The initial request (or AS_REQ) is actually made in clear-text. This request is made to the authentication server (hence AS) on the KDC. The reply back from the server is the encrypted TGT. The ticket contains a time stamp encrypted with the hash of the user’s password. When the ticket is returned to the client, in theory only the intended user who enters their password correctly can decrypt the ticket. This ticket is then cached for later service requests. At this point a trust has been set up between the KDC and the client machine.

2. TGS Exchange (Service Request – Part 1) – The client then submits the TGT (or Ticket Granting Ticket) it received from the KDC and presents it back to the TGS (or Ticket Granting Server). It does so in order to get a Service Ticket and session key for the service the client is trying to use. This Service Ticket is comprised of the secret key from the host/service providing the resource and a service session key generated by the TGS. This sets the stage for the last part of the process. One thing to realize is that at each stage of the process the previous session key is being used. This is important, as only the authenticated user would have access to these keys.

3. Client/Server Exchange (Request – Part 2) – This is where the Service Session Ticket is used to request access on behalf of the client to a Kerberized service. Examples of these services include POP, IMAP, SMB, AFP, NFS but are not limited to the above. Because the Service Session Ticket was encrypted with the service’s ‘long-term’ key and it decrypt the ticket that was encoded using it’s key. The service trusts that the AS has done it’s job and the allows the client access to the requested service.

Everything is based on a trusted third party… the KDC! An interesting thing to note is that a users password is never sent over the wire. Since the KDC is all ‘knowing’ it can encrypt tickets using either the client’s password hash or the services service key. The key known only to the principle receiving the ticket can only decrypt their tickets. In Kerberos there are a number of types of principles, a user, a host and/or a service.

Kerberos 4 implemented DES as it encryption algorithm. DES only uses a 56 bit and is considered insecure. Kerberos 5 implements a number of different encryption algorithms. Unfortunately, today many networks are heterogeneous supporting many OSs and they all need to operate seamlessly. Active Directory commands the lion’s share of installed directories. This means other OSs need to be able to ‘speak’ with Microsoft’s ‘version’ of Kerberos (encryption) in order to insurance a smooth implementation.

Kerberos has enjoyed larger popularity mainly because it is implemented as part of Windows’ Active Directory. This is not to say that it is not as popular on other platforms. Apple included Kerberos as a major part of its directory implementation, Open Directory.