So, Who are You Anyway?
So, Who are You Anyway?
By: Bill Ray
Jul. 16, 2001 12:00 AM
Wireless and mobile networks have the potential to provide new levels of security and confidence, as long as we design them that way. With open networks, the responsibility for creating a secure environment must fall to whoever deploys the application, not the network itself.
Every day, we're using cryptography that would have been unthinkable, not to mention illegal in many countries, five years ago. We recognize that e-commerce Web sites and transaction servers use massively complex mathematics to protect our data, even if we don't understand the details of how it actually works (and very few of us do). This shouldn't come as too much of a surprise. After all, the first computers were developed and designed to work with cryptography (actually, they were designed to break it, but the process is similar). The abilities of desktop computers in this area have led to the creation and everyday use of codes even major governments can't break.
In the days when most information was transferred in analog form, encrypting things was a tricky process. Anyone who has built a cable television descrambler (or even seen the advertisements for them) knows that such encoding would resist only the most impatient attacker. Analog mobile telephones provided entertainment for many a bored teenager with a radio scanner. But we live in a world of digital convergence, and when everything is digital, it can be properly encoded using standardized techniques, and made secure against the most determined attack.
If our information is in digital form, and computers are so good at encrypting things, why do we have so many problems with encryption? Reading news headlines from the past year, you might think every 15-year old and his brother were spending their evenings breaking codes and reading your secrets, but this would be misleading. Cryptography is very rarely broken. By using a known algorithm with a decent length key, it should be possible to secure any information from anyone, even a 15-year-old kid (and his brother!). The problems come in the way the cryptography is used. But to understand that, you first need to know a little about how we use cryptography, and what the limitations are.
Two Kinds of Cryptography
Dual-key systems are a little more complex. Each party has two keys - a private key and a public one - and information encrypted with one key can only be decrypted with the other. The idea is that a party (me) can make a public key publicly available (put it on my Web site, business cards, etc.), and someone wishing to send me a message can encrypt it using my public key. Then only I can decrypt it using my private key. Conversely, I can encrypt something with my private key and anyone can decrypt it, with the knowledge that only I could have encrypted it (as only I have access to my private key).
The problem with dual-key systems is that they take much more processing time, and are less secure. Using larger keys deals with the security issue, but makes them even slower to operate. Getting a handheld device, such as a PalmPilot, to perform decent strength dual-key cryptography, is almost impossible for anyone but the most patient user with a lot of time to kill.
To deal with the problem of processing load using dual-key systems, we generally use them only to exchange a single key, which is then used for all further communications (often known as a "session" key, as it's generally discarded at the end of a communication session). Certainly the most common implementation of this type of system is TLS (formally SSL), used to secure Web communications.
There are plenty of well-established ciphers for both dual- and single-key cryptography, the most famous ones probably being DES (often done three times, and therefore known as Triple DES), BlowFish, and IDEA for single key, and RSA and ECC for dual-key. These are all good, reliable ciphers that are very difficult to break with decent- length keys. We tend to judge a cipher by who has attacked it, and how hard they tried. It's important to understand that a cipher can never be proved secure, only insecure (you can fail to break it, which proves you aren't clever enough, or you succeed, in which case it's not secure). Some of these ciphers are protected by patents in places that recognize such things, such as the U.S. (but not, currently, Europe).
There's an important aspect to understand here. Just because you know the cipher someone is using doesn't make their security any less secure. Keeping your chosen cipher secret, in the hope no one will ever notice that it's not secure, is not good security, as the creators of the GSM protocol found out.
While cryptography is certainly useful for keeping our secrets, it's also used for a couple of other things worth mentioning. Confidentiality is the process of keeping the content of your communications secret, but is often less important than authentication, to be certain who you're talking to. Proving who you are is often more important than concealing your meaning.
If you place an order with Amazon for a book and I listen in, it's really not very important, but if I can pretend to be you and order more books, then that's a problem. Only through authentication can Amazon be certain that you really are you. Third comes nonrepudiation, the ability for Amazon to prove that you really ordered that book, no matter how much you deny it. Nonrepudiation may seem unimportant, and when you're ordering a book it probably is, but if you think about it, every time you use a pen to write your signature, you're actually providing nonrepudiation material.
Listening in on Wireless Conversations
So even if we have devices capable of performing decent dual-key cryptography, there remains the question of how we go about exchanging keys. While the public part of a dual-key system can be sent over an insecure network, you still need to know who sent it, and be certain it really is their key. These are the problems that tax the minds of security specialists, and provide opportunities for attackers.
Smart Cards Used by Some
Some of the digital phone networks take one further step, including GSM and PCN, where each subscriber is issued a pair of keys, and the network operator keeps a copy of the public key of every subscriber. Digital satellite TV broadcasters also use this model. Every subscriber has a different key pair, and the network operator keeps records of who has paid their bills and can continue using the service.
Remember that the dual-key system will be used only to exchange a session key. Once that exchange has occurred, the dual-key system won't be used until the next session. The advantages of having different keys for every subscriber are obvious: should a key be compromised, the operator can quickly shut down recognition of that subscriber, making the process too expensive for most attackers.
What these two systems have in common is that the keys are exchanged "out of band," that is to say, the actual exchange of keys does not happen on the network being protected. Where a network operator can issue identities to every subscriber, they can send every subscriber a Smart Card with keys already embedded on it. The problem comes when a network has no managing body or central point of control, such as the Internet. With TLS the keys are built into the Web browser, and installed onto a PC when the browser is installed.
This is not ideal, given the reliance on the Internet to download the browser, with its various security problems. TLS can be made secure, by issuing keys out-of-band (posting them on floppy discs to customers or handing them to employees), with the associated cost in complexity and ease of use.
When we think about securing wireless Ethernet or Bluetooth communications, things get more complicated and key exchange becomes more important.
Both wireless Ethernet and Bluetooth provide complex security mechanisms with encryption standards and decent-length keys, but both suffer massively from problems of key exchange. Wireless Ethernet requires each device in a secure network to be programmed with the same pass-phrase, which must be manually entered on every device. Bluetooth uses PIN numbers that must be entered on every device whenever a secure connection is to be used, not ideal in an ad hoc network.
Both of these approaches have definite problems. Discovery of the pass-phrase or PIN number being used would mean that an attacker, sitting in his coffee shop, could eavesdrop on all communications, and as most attacks are performed by ex-employees, they are likely to have access to this information. In future articles we'll look at the actual processes used by wireless Ethernet and Bluetooth in much more detail, but it's the key exchange that shows the greatest and most obvious vulnerability.
By using a dual-key system it becomes unnecessary to protect the key on every device, but the question remains whose key is used, and how does it get onto every device? If a company decides to issue devices to every employee, then they become the network operator, and can issue keys to each device (and employee) to build a secure networking environment. But with different types of devices and different demands and priorities, it will be important not to impose unnecessary processing load onto devices that don't need it.
It should be clear that as we move to a more flexible networking paradigm, and expect our devices to identify themselves securely to whatever network they happen to be near, new models of secure communication and key exchange are going to be needed. The security models built into current wireless networking protocols might provide a basis to build from, but they're still a long way from offering the kind of functionality we're going to need every day.
Reader Feedback: Page 1 of 1
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week