Funny how I learn something new everytime I visit a new customer. Seeing different environments and how different customers solve the same problems is eye opening. More importantly, the more environments I see the more I begin to understand how misconceptions I had held in the past.

As a little background, I broke into the infosec biz in the opposite way that many of my peers have. My first formal role in infosec was as a security systems engineer for Motorola. My job was to basically look at security standards, product management requirements, and security threats and design security features. Problem is, when you take that direction you miss out on the real world, hands on perspective of infosec and have difficulty understanding exactly how organizations infosec functions (if it even exists!) It’s way too easy to fall into the ivory tower mentality. Add a couple of years of grad school in infosec, and you have the makings of a great infosec philosopher, but not a practitioner. Consulting has really opened my eyes and is helping me understand what I never fully grasped before.

With that out of the way, during my last couple of engagements I’ve learned a ton about enterprise identity management and have corrected a major misconception I had held in the past. Earlier in my career, I was faced with solving the problem of figuring out how to integrate enterprise identity management systems with wireless equipment; so that system administrators could use their existing credentials to log into the management interfaces of the wireless infrastructure. At the time, the solution that struck me was to use a AAA server with RADIUS; after all RADIUS is easily extensible, simple to develop and support, and is flexible. What I completely failed to realize at the time is that a AAA server is in fact not intended to act as an identity management system. Sure, AAA stands for Authentication, Authorization, and Accounting, but the AAA server is generally just a relay and is not the actual identity management system.

As I have since learned, identity management is actually centered around one of the oldest protocols in the book, LDAP or Lightweight Directory Access Protocol. LDAP is a directory service that is designed to provide extremely fast lookups and extensive search capabilities. LDAP gets it speed from the hierarchical design of objects that are stored within the directory. All objects descend from a single root node, with each child node having one or more child nodes and one or more sibling nodes. Here’s a figure of a basic tree structure of an LDAP directory.

Each node in the directory is uniquely identifiable by use of a distinguished name. A distinguished name is made up by simply concatenating the identifiers for each ascendent node to the node being named. In this figure, the DN for me would be CN=Walter,OU=Person,OU=Users,DC=jdt,DC=com. Each node also has a collection of attributes associated with it that contain information such as date of creation, address, member groups, object identifier and any other information that is pertinent to the object itself. Lookups are done by connecting to the directory server and issuing queries. LDAP queries are interesting in that they are written in a reverse polish notation style; e.g. if you wanted to search for my name in the query above quickly, you could search for a person named Walter with the following query: (&(OU=Users)(CN=Walter)).

To make LDAP directories generally useful, they usually provide some information to LDAP clients without requiring the client to authenticate. Examples would be a web based corporate address book that is accessible from a organizations intranet. However, in order to gain access more sensitive information, LDAP clients usually authenticate to a directory via a bind operation. In fact, this is how many network operating systems such as Active Directory, Novell etc. authenticate users; a bind against a corporate LDAP directory is performed using the user’s credentials. Once the bind is successful, the user is granted access to the local system and further authenticated LDAP queries can be performed to obtain additional information needed to grant the user access to resources.

LDAP itself does not provide any integrity or encryption mechanisms to protect information that is transmitted between the directory and LDAP clients. However, bind operations usually use authentication protocols which protect credentials that are transmitted such as NTLM or GSSAPI. To provide integrity and confidentiality for LDAP data, LDAP may also be transmitted over a TLS secured port (LDAPS). Yet another use case for an enterprise PKI that I had absolutely no idea about.

So, to complete the original story, what I’ve since discovered when it comes to centralized user management, enterprise identity management, don’t think of AAA services. Rather, think of LDAP directory services. As a matter of fact, AAA servers usually have plug-ins (such as FreeRADIUS’s rlm_ldap plugin) that let them use LDAP directories as a data source when performing authentication and authorization services.

Looking back at my first job, I realize that some of the same concepts which I used to sell camera equipment in a retail store still apply to my consulting job that I have today. Being responsive to customer needs, explaining the benefits of what they are considering purchasing (or already have purchased), and in general going over and above the minimum requirements for your job are all perfectly valid concepts that apply even to security consultants.

As an example, in my current engagement I’m deploying a part of a tokenization solution to satisfy PCI requirements that my customer is required to satisfy. The scope of the engagement from my perspective is rather limited, but I’ve taken a deliberate effort to go above and beyond the minimum requirements outlined in the SOW (without increasing my scope, a fine line to walk for sure!) Specifically, while I was in the customer’s data center performing some configuration tasks, I looked around and noticed that there didn’t appear to be any cameras in position to observe the equipment I was configuring. As the customer explained that the equipment was considered ‘in scope’ of the PCI DSS requirements, I pointed out that requirement 9.1.1 of the DSS requires the use of a video camera to monitor equipment (and yes, I know that the requirement is an and/or requirement). The customer contact I was working with was not part of the physical security team and couldn’t confirm whether or not the area was in fact monitored, but he took it as an action item to follow up on.

While in all likelihood this will turn out to be a non-issue, the customer expressed appreciation at my observation. This in turn leads to a stronger sense of trust between us and, in my opinion, enhances the overall value of the engagement. So next time you find yourself in a position where you can offer a little extra advice to your customers, consider going the extra mile. You won’t regret it!

A big part of my job is to advise customers how to protect high value secret keys such as root CA private keys, tokenization key encryption keys, etc. Solutions range from the relatively simple read-only private key file, passphrase protected stored with minimal permissions to storing keys on dedicated, purpose built hardware devices. Purpose built hardware devices used for secure key storage are known as hardware security modules (HSM). A HSM can be thought of as both a secure key storage device and a hardware implementation of crypto algorithms. Unlike purpose built encryption hardware such as SSL accelerators, a HSM is not designed as a high throughput, low latency device designed to convert plaintext to ciphertext at high speeds. Rather, it is designed to limit the exposure of key material stored within it. This is accomplished by performing operations that require access to the key material within the HSM itself (such as digitally signing data). In some cases where necessary, HSMs can also provide the keys to authorized devices/users. Applications which wish to use HSMs typically use a vendor provided driver that integrates with various platforms (for example, Microsoft provides a Cryptographic Service Provider interface that can be used to integrate applications with HSMs).

In general, the design philosophy behind HSMs is that it should fail closed; meaning that if an attacker or unauthorized user attempts to repeatedly gain access to the HSM key material, the HSM will zeroize all stored keys. This design makes sense because if an attacker were to gain physical access to the HSM, it is preferable that the secret keys be destroyed rather than possibly be exposed. However, since the HSM protects high value keys, it is imperative that organizations which make use of HSMs have a robust key backup scheme in place such as sharing the key across multiple HSMs that are physically separated.

HSMs typically have a strong role based authentication mechanism built in that is designed to differentiate between key owners and HSM administrators. This separation of duties between key owners and administrators is crucial as it prevents HSM administrators from gaining access to key material. Authentication can be provided via the use of passphrases, or in some HSMs, via the use of individual hardware keys that are physically presented to the HSM.

Since access to key material and to the HSM itself needs to be carefully audited and tracked, a principle that is implemented in some HSMs is the concept of witness keys. A witness key is a separate set of keys that are distributed to other people (usually from different departments/organizations than HSM administrators or key owners) that must be presented to the HSM before access will be granted to the HSM and/or key material stored within the HSM. Witness key systems are also known as MofN systems, where ‘M’ witness keys out of a total of ‘N’ existing witness keys must be presented before access can be granted.

In summary, proper protection of high value keys is an important role that any security organization should take very seriously. HSMs can be a viable solution to help ensure that key material is stored in a safe, controlled fashion.

I consider myself largely a lurker on most security mail lists that I subscribe to, including the closed SANS Advisory Board mail list. However, a recent discussion on that list prompted me to think about the supposed risks of self signed certificates, especially in an enterprise network.

Like nearly any other security technology out there, self signed certificates can be evil or perfectly acceptable depending on the context in which they are used. In a nutshell, self signed certificates alone provide confidentiality and integrity to any protocols which use them to establish connections. Self signed certificates alone do not provide authentication in the traditional sense of a PKI, because the certificate has not been issued by another trusted party (such as a centrally managed PKI infrastructure).

So, the question is, does this lack of authentication make self signed certificates evil? I don’t believe that it does. A certificate can be authenticated by other means. For example, if the self signed certificate is installed on a end user system by some other trusted mechanism (such as a centralized directory/management server), the centralized management server is vouching for the self signed certificate. In another extreme example, a user could contact the administrator of a system that is using a self signed certificate and verify the certificate fingerprint being presented by the self signed certificate.

The real risks of self signed certificates are that end users will become accustomed to simply adding self signed certificates to their browser’s trusted certificate store and will ignore the security warnings presented by their browsers over time. The sanctity of browser errors generated by untrusted certificates must be preserved to ensure that users view those errors as exceptional events and respond accordingly.

It’s occured to me, many folks understand that WEP is easy to break, but don’t know all the steps and just how easy it is.  Here I hope to lay down the basic steps in one coherent post.. demonstrating how to crack into a wireless network using WEP, with a client attached to it.

Like always… only do this against your own networks.  The legal grounds are a bit grey here, but the ethical grounds are clear – you shouldn’t pick your neighbor’s doorlock.  Being a security professional also comes with the responsibility to use your skills for good, not evil.

Step 0: get the software.

I assume you’re using linux…. these tools do work on OSX but they require a bit of tweaking i think, and i haven’t done it myself.  so i’ll just write up linux.  you can use a VM of linux but the wireless card support is a bit flakier unless you’re using a USB card.

basically you only will need two packages, kismet, and aircrack-ng

So:
apt-get install kismet
apt-get install aircrack-ng

Step 1: Find a WEP network

Kismet is an amazingly powerful scanning tool and I could write much more about it than we need here.  It takes advantage of the feature in wireless cards to use “monitor mode”, which basically does passive listening for network traffic, and analyzes the traffic into a nice list.  It can do all sorts of other neat stuff like gps logging, etc, but that’s not totally necessary here.

If you don’t know it, you’ll need the interface name for your wireless card.  Check it by typing:

iwconfig
Then, just launch kismet (type ‘kismet‘) and then it will prompt you what your WLAN card is.  It will try and put it into monitor mode and is usually successful, even with built-in wireless.  If not theres some troubleshooting to be done….

Assuming it works, it will give you a list of networks it sees.  It ‘hops’ channels by switching the frequency the card is listening on and collects traffic on that frequency.  If there’s a WEP network in sight, kismet will highlight it in red, and you will need to pay attention to four things:

• Its BSSID – similar to the MAC address of the access point
• The ESSID – the ‘friendly name’ of the network
• The MAC address of a client that is attached to it.
• The channel the AP is broadcasting on

Kismet has a column that shows the amount of traffic it sees for both the AP in general and the client.  You want to target one with a client attached that is passing data… they’re the easiest targets.

An alternate path to WLAN monitor mode:

If kismet has a hard time putting your card into monitor mode, try running ‘airomon-ng start <interfacename>’ and it should attempt to do so.  If that still doesn’t work…. investigate getting a new card.  The Alfa AWUS306Hf is an excellent USB choice.

Step 2: prepare to attack

If it’s not setup yet, enable monitor mode:

airomon-ng start <interfacename>.

Begin a dump session – this logs traffic, sort of like a lightweight Wireshark.  You want to filter it to only the transactions we’re interested in:

airodump-ng –channel <c> –bssid <xx:xx:xx:xx:xx> –write <fileprefixname> <interfacename>

where c: the broadcast channel of the network
xx: BSSID of the network
<interfacename> – self explanatory (i.e. wlan0mon)

Keep this running and launch a new window for the next steps.

Step 3: do an ARP replay attack

This essentially looks for an ARP request from the attached client, and replays it many many times, enough to create a data set large enough to mount a cryptographic attack against WEP.

aireplay-ng –arpreplay -h <xx:xx:xx:xx:xx:xx> -b <yy:yy:yy:yy:yy:yy:> <interfacename>

where xx: the MAC address of the client
yy: BSSID of the network
<interfacename> – self explanatory (i.e. wlan0mon)

Once this has started, check out the other window.  You should see the data packets starting to increase rapidly.  When you’re at about 40k there is enough to crack a 104-bit WEP key.  The more the better, but no harm in starting early…

Step 4: mount the cryptographic attack

From the same directory you launched the dump process just run this:

aicrcrack-ng <fileprefixname>.cap -0

This will launch a window that shows progress.  if it’s successful, you’ll see the key!  if it’s not… keep waiting for more traffic.  40k+ data packets increases your odds tremendously but if it’s a simple WEP key it requires less.  This tool will actually keep trying as the packet capture increases in size so you can keep it running.  Or quit it (ctrl-c) and wait till you have more.

Step 5: connect!

If all went well you have broken the WEP key via the PTW attack method.  Now you can connect to the network.  Close down the dump sessions, etc etc and bring down your WLAN card – ifconfig wlan0 down

Then you’ve just gotta connect:
ifconfig <interface> up - bring up the wlan card

iwconfig <interface>mode managed key [WEP key]

iwconfig <interface> essid “[ESSID]” (Specify ESSID for the WLAN)

dhclient [interface] (to receive an IP address, netmask, DNS server and default gateway from the Access Point)

If all goes well you’ll get an IP and then you’re good to go, test by pinging or whatever else.

But if it didn’t work, they may have MAC filtering in place…

So change the MAC address of your wireless card to the same one that you just cracked with!  This is a bit messy and could freak out the DHCP server of the access point, but it’s worth a shot.

Bring the card down first:

ifconfig wlan0 down

Then change the MAC:

ifconfig wlan0 hw ether xx:xx:xx:xx:xx:xx

Bring it back up again and repeat.  You should be good to go.

This is a simplified walkthrough of a process that is documented many other places.  It should give you a taste of kismet, and the basics of the aircrack-ng suite, which has many many other great features.  I encourage you to read all about it over on their website.

Additionally, their site also contains a much more in-depth WEP crack tutorial.

Again, this is not ground-breaking, but it is always good to share the fundamentals in case someone hasn’t seen it before.  Good luck!

Wow – I would never have thought that in this day and age, a major vendor like Microsoft wouldn’t fully implement a spec.  However, in the case of WPA2 it looks like that they did exactly that – at least until 2005.

BUT making things more interesting- this was an “optional” update with XP SP2, until it was finally rolled into XP SP3.  There is a hotfix for XP SP2 machines in order to support WPA2 – KB 893357.

WPA2/AES didnt’ really become widely implemented until 2006, but it was in the 802.11i spec that introduced WPA in 2004.  For a major vendor like MS to not implement it is pretty crazy.  But then again I, as a wireless security professional, didn’t setup a WPA2/AES network in my home until last month.  So maybe they were onto something.

Anyways, if you’re using XPSP2 and a WPA2 network – you need the hotfix, or XPSP3+.  Good luck out there!  I really recommend moving to WPA2/AES, especially considering the improvements in the Nvidia CUDA drivers that are allowing TKIP to be broken in an increasingly short amount of time.

Wi-Fi.  Everyone’s got it nowadays.  Your Comcast or Verizon broadband connection at home probably comes with a wireless router.  But do you really know how to set it up??  Better yet – do you really know how yours is set up currently?  Or does it “just work”?

I want to briefly share my thoughts on the subject and give you some advice on making a secure – or perhaps intentionally insecure – wireless network at home.

Let me explain some fundamentals.  The first thing that you need to keep in mind is that all wireless traffic is visible to everybody.  Your XBOX live session.  Your online banking from your laptop.  Your IM sessions.  It’s all out there, just waiting to be listened in on, on a very well-defined and well-understood protocol, 802.11.

Before you panic, you need to remember the second important thing – nearly all wireless traffic can be well-protected.  Walter has been doing a nice series on encryption, and even if you don’t follow all the details, the major takeaway can be that data can be wrapped up pretty tightly if you set it up correctly.

For most people, I am going to advocate running a closed network – encrypting your traffic and only allowing authorized users to use your home access point (AP).  This is the subject of some debate among the security community, most notably from Bruce Schneier (who advocates for keeping your wireless network open), but I’ll say that for the “average user” it’s better to close it off.

Your network can be secured through a combination of obscurity, exclusions, and encryption.  Obscurity is not openly advertising the name of the AP.  Exclusions are preventing unauthorized network cards from joining your network.  Encryption is wrapping the traffic in a difficult-to-break code that can only be understood by your wireless devices and your wireless router.  The first two methods are relatively trivial to subvert – any ‘serious’ attacker could get themselves onto your network if they were the only two barriers to entry.  But the third is the most important, and here your choice is pretty clear – definitely encrypt!

But which encryption and authentication method to choose?  Home APs commonly come with a couple varieties of encryption options – WEP, WPA-PSK, and WPA2-PSK.  WEP has had known vulnerabilities since almost its inception, and is now easily broken in less than 10 minutes of work.  So don’t use it. Use WPA or WPA2, although WPA2 is relatively new and supported by less devices than WPA.

PortForward.com has an excellent guide to the details of setting up security on many wireless routers.  I would personally recommend against masking the SSID (the “name” of the wireless network) and implementing MAC address filtering, just because they’re easily compromised anyways, and make the network a hassle to administer.  The slight tradeoff in security is worth it for the increased usability.  As long as you’re using WPA or WPA2 with a relatively long pre-shared key – at least 15 characters – you’re better off than many networks.

Finally, if you choose to run an “open network” – a network that freely allows any client to associate with it, with no encryption – there are a few ways to still be safe.  First, keep in mind, that while the wireless traffic may be easily ‘sniffed’, if the data itself has already been encrypted via SSL (look for the ‘lock’ icon displayed in your browser) or a VPN tunnel, it’s a moot point – it’ll be garbage to an attacker.  So even though I menacingly mentioned that your bank traffic is visible earlier in this post – it’s only visible as encrypted gobbledygook, so no reason to panic just yet.

Summary – use WPA or WPA2.  Don’t bother with MAC filtering or SSID masking.  Don’t use WEP unless you really have to.  And you probably don’t want to run a wide-open network, but if you do so, don’t panic too much – most ‘important’ traffic is probably encrypted anyways.

In another post I’ll go into some ideas for running a secure, yet open home wireless network.  But until then, keep my simple recommendations in mind and you’ll be just fine!

Consider the problem where you need to know for sure that information you are looking at has not been altered since it was first created. A simple example that kids can relate to is a report card from school. The model for report cards is that the school gives a kid his/her report card, they bring it home and their parents sign it to show that they read the report card. An obvious problem that the school has is to be certain that the report card isn’t changed while the kid has it.

In cryptography, this problem is referred to as ‘data integrity.’ Cryptographic systems solve this problem by creating a representation of the information that is unique. This representation is referred to as a ‘hash’ (or checksum). A good way to think of a hash is as a digital fingerprint that looks totally different for each set of data that it represents. Functions that are used to create hashes from information are called hash functions. There are a couple of important points about hash functions:

• The result of the hash function MUST be unique for each message that it processes. That is, you should never be able to get the same result from a hash function if you feed in two different messages.
• The result of the hash function MUST not look anything like the message that it processed.
• It MUST be impossible, given the result of a hash function, to determine what the original message was.
• The result of the hash function is usually smaller than the message that it processed.

If you wanted to exchange a message with another person and be sure that the message hasn’t been changed along the way, you could use a hash function as follows:

1. Create a message.
2. Feed that message into a hash function.
3. Send the message to the recipient along with the hash.
4. The recipient feeds the message into the same hash function used by the sender.
5. The recipient compares their hash with the sender’s hash. If they are identical, the recipient is sure that the message wasn’t changed.

Of course this exchange isn’t secure as the hash could be changed in transit as well, but it illustrates how such a system works. I’ll explain how to make this exchange secure in a future post. To find out more about the basics of hash functions, read more.

So, how exactly do hash algorithms work? They work by mixing and mashing the messages being hashed. The mixing and mashing is done by dividing a message into a set of chunks. These chunks are then mixed together using math operations (this step varies greatly depending on the hash function being used).

Here’s an example of a very simple hash function. In this function, note that letters are represented using numbers (ASCII codes, so A=65, B=66, C=67 … Z=90). Note that when using ASCII characters to represent numeric values, you have to have numeric values in the range of 65 to 90 in order to be able to print them as characters.

• Divide your message into sets of 8 letters. If the number of letters in your message is not evenly divisible by 8, add as many ‘i’s to your message as needed to make it divisible by 8 (this is called ‘padding’).
• Replace the letters with numbers (ASCII values which can be found here).
• Now, arrange the sets of 8 numbers in a vertical column; ex. if your message has 24 letters, you should have 3 rows of 8 numbers arranged in a column.
• Starting at the top row, add the first number in the first 2 rows together. Since this number is going to be larger than 90, we need to do a little more math to make it fall in the range of 65 – 90. So we will take this sum and divide it by 26. This will ensure that the number is in the range of 0 – 26. Next, we’ll take this remainder value and add 65 to it. This way, we can be sure the final value will be in the range of 65 – 90. This final value then becomes the first value in a new row. Repeat this step for all of the characters in the first two rows.  (For readers of my previous post on clock arithmetic, this calculation is just modular arithmetic, specifically we are calculating the value mod 26).
• The new row that you’ve created now replaces the first 2 rows. Repeat the previous step until you’ve added all the rows together.
• The final row that results from doing these operations represents the hash value for the message.

Here’s an example where I calculate the hash of the value “walter goulet is here”

The message “WALTER GOULET IS HERE” looks like this encoded in ASCII (the value 32 is a space character.)

87 65 76 84 69 82 32 71 79 85 76 69 84 32 73 83 32 72 69 82 69

Note that there are only 21 characters in this message, so we need to add 3 “I”s to the end for padding. The ASCII code for ‘I’ is 73. So, the padded message looks like this:

87 65 76 84 69 82 32 71 79 85 76 69 84 32 73 83 32 72 69 82 69 73 73 73

Next, we break the message into sets of 8 numbers:

1. 87 65 76 84 69 82 32 71
2. 79 85 76 69 84 32 73 83
3. 32 72 69 82 69 73 73 73

Now, we add rows 1 and 2 together by adding each number in the same position together, dividing it by 26 to get the remainder, and add the value ’65′ to the result. Let’s perform this operation on rows 1 and 2:

87 + 79 = 166; 166 / 26 = 6 remainder 10; 10 + 65 = 75

65 + 85 = 150; 150 / 26 = 5 remainder 20; 20 + 65 = 85

and so on for each number in rows 1 and 2. The new row, after repeating this for each number, becomes

75 85 87 88 88 75 66 89

The new row is then added to row number 3 above using the same process.

1. 75 85 87 88 88 75 66 89
2. 32 72 69 82 69 73 73 73

After repeating this operation, the new row is:
68 66 65 79 66 83 74 71

After replacing these numeric values with their letter values, the final result is:
D  B  A  O  B  S  J  G
This value is our hash value for the message “WALTER GOULET IS HERE”.

As an exercise, try changing a letter in the original message. You’ll see that when you do, the final hash output will change as well. Note that this toy hash function isn’t nearly as strong as real hash functions used in security technologies, but the basic ideas are the same

For interested readers, here’s a Ruby program implementing the hash function described above. Play around with different messages to see how the hashing works and to spot potential problems from this simplistic hash function.

#!/usr/bin/ruby -w

msgstr = String.new(ARGV[0])

msgarr = Array.new

arrindex = 0

msgstr.upcase!

# Pad the input message string if it's length is not divisible by 8

if((numchar = msgstr.length.modulo(8)) != 0)

        padchars = 8 - numchar

        padchars.times do

                msgstr = msgstr + "I"

        end

end

# Break the message into 8 character (or byte) words

strsize = msgstr.length

while(strsize > 0)

        if(strsize.modulo(8) == 0)

                msgarr[arrindex] = msgstr.slice!(0..7)

                arrindex = arrindex + 1

        end

        strsize = strsize  - 1

end

# Add the rows

while(msgarr.length > 1)

        row1 = msgarr.shift

        row2 = msgarr.first

        0.upto(7) do |x|

                row2[x] = ((row1[x] + row2[x]) % 26) + 65

        end

end

print msgarr.first

print "n"

Quick quiz, what do the following sequence of numbers have in common: 19, 3763, 31, and 67? The answer is, they are all the same! Ok, well obviously that’s not strictly true. More correctly, these numbers all represent the same value in modular arithmetic (7 modulo 12). When you take each of these numbers and divide them by 12, you end up with a remainder of 7 (19 / 12 = 1 remainder 7, 3763 / 12 = 313 remainder 7, 31 / 12 = 2 remainder 7, and 67 / 12 = 5 remainder 7).

Another simple way to think of modular arithmetic is clock arithmetic. Consider the problem when you are looking at an analog 12 hour clock. You need to figure out what time it is going to be 7 hours from now. If the current time is 3 o’clock PM, you add 7 hours and end up with 10 o’clock PM. But, what if it’s 8pm? You don’t simply add 7 hours as there is no such thing as 15 o’clock pm. Instead, when you pass 12 o’clock AM, you restart your counting. So 8 o’clock PM + 7 hours = 12 o’clock AM + 3hrs = 3 o’clock AM.

So what does clock arithmetic have to do with security? Going back to our original sequence of numbers, notice that you cannot possibly determine that these numbers all represent the same mathematical value without having a key piece of information, the modulo value (which in this case is 12). When you think about it, this property is useful from a secrecy perspective because you have 2 pieces of information that have a common value, but you can’t tell what that common value is unless you know some other information. This basic property of modular arithmetic forms the basis of many of the key negotiation and encryption algorithms in use today.

So, for fun, here’s a simple cryptosystem (secure enough to keep your 10 year old little sister from reading your journal) that uses this property. Note this cryptosystem doesn’t authenticate the two parties, but it at least allows them to exchange a pair of secret keys no matter who is listening.

• Alice and Bob want to exchange a secret message, but they can only talk to each other over an open communication channel.
• Beforehand, Alice and Bob agree to use the current time as the modulo value for determining the secret value. For example, if the current time is 4pm and Alice and Bob want to agree on a secret key, they will divide their values by 4. Note that the method they are using for choosing a modulo value must remain secret for this system to work.
• Alice sends her value to Bob in an open channel. Bob calculates the value she sent modulo the current time. The result is Alice’s encryption key.
• Bob sends his value to Alice again in an open channel.
• Alice calculates the value she got from Bob modulo the current time. The result is Bob’s encryption key.
• Now, Alice and Bob can communicate securely using each other’s encryption key to encrypt messages being sent back and forth (using some pre-determined encryption algorithm).

To see the system in action:

1. The current time is 9pm.
2. Alice picks a value of 84.
3. Bob picks a value of 1156.
4. Alice and Bob send a message to each other via a open channel (normal phone call, ads in the newspaper, or even yelling at each other in a park!).
5. Alice get’s Bob’s value of 1156 and calculates 1156 / 9 = 128 remainder 4. 4 is Bob’s encryption key.
6. Bob get’s Alice’s value of 84 and calculates 84 / 9 = 9 remainder 3. 3 is Alice’s encryption key.
7. Now Bob and Alice can encrypt their messages using their respective encryption keys.

The real beauty of this type of system is that no matter who learns the values that Alice and Bob selected in steps 2 & 3, they will never be able to figure out how they are related without knowing what the modulo value is. In a future post, I’ll expand on this a bit more to show how modular arithmetic is used in non-toy cryptosystems.