Global Sources
EE Times-India
Stay in touch with EE Times India
 
EE Times-India > Networks
 
 
Networks  

Securing connected devices from Internet outlaws

Posted: 01 Jul 2003     Print Version  Bookmark and Share

Keywords:Embedded 

/ARTICLES/2003JUL/B/2003JUL01_NTEK_CT_TA01.PDF

By Steve Kapp

Chief Technologist

EMRT Consultants Inc.

E-mail: skapp@emrt.com

Internet-enabled devices are

gaining popularity, but not ev-

eryoneontheInternethashon-

orable intentions. Hackers and

crackersdoexistandmayattack

your product. Embedded sys-

tem designers need to be aware

of the existing threats as well as

the technologies that protect

the integrity of their devices.

This article examines the

risks and discusses available

security frameworks. Public-

key infrastructure and digital

signatures will be examined.

We will also focus on encryp-

tion and authentication tech-

nologies,concentratingmainly

on secure sockets layer (SSL)

and transport layer security

(TLS).Implicationsforproduct

development will be explored,

including available open-

source implementations. By

the end of this article, readers

will have a basic understanding

of the security risks of Internet

connectivity as well as the tech-

nologies that mitigate them.

Thisarticleisnotanexhaus-

tive treatise on the subject of

Internet security. It is a high-

level introduction to an ex-

tremely complex subject.

What is Internet security?

Generally speaking, Internet

security refers to a set of ser-

vices that permit data to be

safely transmitted across the

network. Some information

passedoverthenetwork,suchas

financial and legal documenta-

tion,isofasensitivenature.Dif-

ferent products and applica-

tions have different security

needs. Hence, security services

may be limited or broad in

scope.

The available set of Internet

security services may be gener-

alized as providers of an in-

creasing state of trust. When

node A needs to communicate

a credit card number to node B,

it is prudent to verify that node

B is who it says it is. In this

sense, node A must trust node

B or some third party that can

vouchfornodeB'sidentity.The

main focus of Internet security

is to facilitate a trust relation-

ship between various network

nodes.

Of course, this is not a blind

trust. Node A may be autho-

rized to invoke certain services

on node B, but banned from in-

voking others. This depends

upon how much node B trusts

node A.

Each product must deter-

mine what security threats ex-

ist before a set of security ser-

vices may be specified. Each

product must also evaluate

which security protocols are in

use by the other nodes on the

Internet (that is, most HTTP

servers support SSL).

Figure 1 illustrates the lev-

els of trust in the form of a pyra-

mid. The base of the trust pyra-

mid is integrity which ensures

that the stream of messages be-

tween two network nodes have

not been tampered with. A net-

work communications channel

Securing connected devices from Internet outlaws

that guarantees integrity pre-

cludes a malicious third party

from tampering with the con-

tents of individual messages, as

well as the ordering of a stream

of messages, including inser-

tion of extra messages into the

stream or deletion of messages

from the stream.

Integrity also encompasses

authentication. Is node A really

who it claims to be? If the iden-

tityofnodeAcannotbeverified,

then communications should

not be established. Closely re-

lated to authentication is non-

repudiation which ensures that

the sender cannot deny the suc-

cessful transmission of a digi-

tally signed message.

Confidentiality ensures that

the sender and the intended re-

ceiver are the only two network

entities that may decipher the

contents of a stream of mes-

sages (in a reasonable amount

oftime).Itprotectsthecommu-

nication channel from passive

attacks such as packet sniffing.

Confidentiality requires some

type of encryption technology.

In confidentiality's most pro-

tective form, all information

passed between node A and

node B is encrypted.

At the top of the trust pyra-

mid is authorization. Once a

network client's identity has

been established, it may be au-

thorized to invoke various ser-

vices on a server, such as telnet

or FTP. Not every network cli-

ent needs identical authoriza-

tion rights on a server. While

the initial delegation of rights

Increasing

level of

trust

Authorization

Confidentiality

Non-repudiation

Integrity Identity

Figure 1: The base of the trust pyramid is integrity; it ensures that the stream of messages is not tampered.

Encryption

algorithm

Decryption

algorithm

Ciphertext

Plaintext

Original

information

Plaintext

Network node A (Alice)Network node B (Bob)

Original

information

Shared secret key

Figure 2: Symmetric encryption schemes are conceptually simple.

maybeasystemadministrator's

job, the networking protocol

can provide the framework to

establish identity and transfer

the authorization rights be-

tween network nodes.

Now that the scope of

Internet security has been out-

lined, the building blocks of se-

cure Internet channels will be

described. These building

blocks include:

7 Encryption and decryption;

7 Digital signatures;

7 Message digests;

7 Public-key infrastructure;

7 Certificates.

Encryption and digital signature

Encrypting network com-

munications ensures that con-

fidentiality is maintained over

the wire. Two types of encryp-

tion algorithms, also known as

ciphers, are of interest. The

most fundamental type is sym-

metric encryption. The most

common cipher for symmetric

encryption is the data encryp-

tion standard (DES). Symmet-

ric encryption schemes are

conceptually simple, as illus-

trated in Figure 2.

Inthisscheme,nodeB(here-

after called Bob) sends an en-

crypted message to node A

(hereafter called Alice). In the

parlance of cryptography,

plaintextistheoriginaldataand

ciphertextistheencrypteddata.

Thecipherusessomesharedse-

cret data, also known as the key,

to transform the plaintext into

ciphertext and back. The key is

a piece of data that the encryp-

tion and decryption algorithm

must employ.

ROT13 is one simple ex-

ample of a symmetric cipher. It

works on ASCII text by adding

13 to every character code dur-

ing encryption and subtracting

13 from every character during

decryption. These values are

bounded by the letters of the

alphabet.

To use a symmetric cipher,

Bob and Alice must not only

agree on the algorithm, but

also on the key. Here lies one of

thedisadvantagesofsymmetric

encryption. If Bob and Alice

must have a prior knowledge of

the algorithm and the key to

securely communicate, then

how is the communication

channel created in the first

place? This is a classic chicken

andeggscenario.Therearetwo

solutions:

1. The key (and possibly the al-

gorithm) is sent from Bob to

Alice before the secure com-

munications channel is es-

tablished. The obvious

drawback of this approach is

that anyone sniffing the

packets will see the key and

can decrypt any subsequent

messages.

2. The key (and possibly the al-

gorithm) is distributed in a

different manner. This may

involve hardware devices, a

separate networking proto-

col or a password used as a

key, but it must not be dis-

tributed in an insecure way.

Key distribution is a funda-

mental problem of secure sys-

tems. Whitfield Diffie and

Martin Hellman proposed

some remedies in an article

called New directions in cryp-

tography (IEEE Transactions

on Information Theory, 22,

1976). These ideas have since

become known as public-key

cryptography.

Asymmetric encryption

schemes feature two distinct

keys, one for encryption and

one for decryption. The sender

encrypts the message with the

encryption key, and the re-

ceiver decrypts the message

with the complementary

decryption key.

Public-key cryptography

adds another twist to the mix.

Supposetheencryptionkeywas

public but the decryption key

was private and known only to

the receiver. The sender of the

message (Bob in this case)

wouldencryptthemessagecon-

tents with the public key, and

the receiver (Alice) would de-

crypt the message with the pri-

vatekey.SinceonlyAliceknows

her private key, Bob can rest

assured that Alice is the only

person that can decrypt the

message. This scheme is illus-

trated in Figure 3.

Some asymmetric cryptog-

raphy algorithms also work in

reverse (RSA is the most popu-

lar). With a reversible algo-

rithm, either the private or the

public key may be used to en-

crypt while the other key is

used to decrypt. Reversible al-

gorithms are useful to prove

identity. Imagine that Bob

wishes to prove his identity to

Alice. Bob would encrypt some

well-known data (of which

Alice has a prior knowledge)

Encryption

algorithm

Decryption

algorithm

Ciphertext

Public key repository

Plaintext

Original

information

Plaintext

AliceBob

Original

information

Alice's private key

Alice's public key

Figure 3: Asymmetric encryption using public keys.

Encryption

algorithm

Decryption

algorithm

Ciphertext

Public key repository

Plaintext

Original

information

Plaintext

AliceBob

Original

information

Bob's

public key

Bob's

private key

Figure 4: Digital signatures using public keys.

with his private key and trans-

mit the data to Alice. Alice

would decrypt the data using

Bob's public key and compare

the data. If the data match,

then Bob has proved his iden-

tity, since only Bob could have

sent the original message.

Reversible algorithms may

also serve as the basis for digi-

tal signatures. In this case, Bob

wouldencryptdatawithhispri-

vate key and transmit that data

to Alice. Bob cannot later repu-

diate the transmission to Alice,

because only Bob could have

encrypted it with his private

key. This scheme is illustrated

in Figure 4.

Asymmetric encryption

schemes are not inherently

more or less secure than sym-

metric encryption schemes.

They simply put forth a more

feasible model for key distribu-

tion. The strongest deter-

minants for the strength of a

cipher are the length of the key

and the processing power re-

quired to break the cipher. Any

cipher can be broken, given

enough time and money. A

cipher may be considered

computationally secure if:

7 The time to break the cipher

exceeds the useful lifetime of

the encrypted data.

7 The cost to break the cipher

exceeds the perceived value

of the encrypted data.

A major disadvantage of

asymmetric encryption, as

compared to symmetric en-

cryption,istheprocessingtime

encryption requires. For ex-

ample, the RSA encryption al-

gorithm, which is probably the

most widely deployed on the

Internet, is based on the diffi-

cultyinfactoringtheproductof

two large prime numbers. Sym-

metric encryption is generally

an order of magnitude faster

and places a small burden on

the processor.

Forthisreason,securitypro-

tocols such as SSL/TLS provide

mechanisms for secure secret

key exchange. Often, the secret

keysarecommunicatedthrough

the use of public-key encryp-

tion.Acommonexampleisase-

cret key generated by Bob, en-

crypted with Alice's public key

and then transmitted to Alice.

SinceonlyAlicecandecryptthe

message, sending the secret key

over the wire does not compro-

mise the security of that key.

Once Alice receives the mes-

sage, any further communica-

tions may employ a faster

cipher, such as DES or one of

its variants.

Message digests

Message digests are algorithms

that take a sequence of bits of

arbitrary length and a secret

key, and output a fixed-length

sequence of bits. The output se-

quence is representative of the

contents of the input sequence.

Thesealgorithmsguaranteethe

integrity of the message.

Change one input bit and the

output will change as well. Mes-

sage digests may also verify

identity when the input is com-

bined with a secret key known

only to the sender and receiver.

The two most widely used mes-

sage digest algorithms are Mes-

sageDigest5(MD5)andSecure

Hash Algorithm 1 (SHA-1).

SHA-1 uses a longer key length

and is generally considered

more secure than MD5.

Digest algorithms are used

to calculate a message authen-

tication code (MAC) for the

message payload. A MAC acts

like a secure checksum. MACs

are calculated by using one of

the digest algorithms with

some combination of a shared

secret key and the message

payload as the input sequence.

MACs provide protection

against an active network at-

tack, such as modification or

falsification of packets. MACs

can be used to guarantee integ-

rity (but not identity) when en-

cryption is not used. Some pro-

tocols, such as SSL/TLS, use

two MACs (MD5 and SHA-1).

The rationale for using both is

that if one is broken, the mes-

sage is still protected by the

other.

A MAC may also be used as a

digitalsignature.Assumingthat

the sender and receiver share

the same secret key used in the

MAC calculation, consider the

case when the sender includes

theMACalongwiththemessage

payload. The receiver can also

calculate the MAC using the

same shared secret key. If the

two MAC values match, then

only the sender could have

transmitted this message.

Public keys and certificates

Public-key encryption schemes

facilitatethreetypesofnetwork

security services: encryption/

decryption, digital signatures

and key exchange. This article

has not yet addressed the issue

HTTP SMTP

TCP

IP

SSL/TLS

UDP

Figure 5: Protocol stack with SSL/ TLS.

Finished

Client Hello (version, random numbers, supported cipher/MAC/compression suites)

Server Hello (version, random numbers, sessionid, cipher/MAC/compression)

Certificate (X.509, including server's public key)

Server Hello done

Client key exchange (encrypted premaster secret)

Change cipher spec

Application data

Change cipher spec

Alert (warning, close notify)

Finished

Application data

Client

7 7 7

Server

1

2

3

4

5

6

7

10

8

9

11

12

Figure 6: TLS message exchange diagram.

of key management. In particu-

lar, the following questions

should be answered:

7 Who generates these key

pairs?

7 Where are they stored?

7 Who is trustworthy enough

to guarantee that the genera-

tor of these keys is who it as-

serts it is?

The first question is easily

answered. The computer that

wants to assert its identity gen-

erates keys. For example, Web

browsers and some e-mail pro-

grams contain software that al-

lows these key pairs to be gen-

erated. These keys are then

stored on the local computer.

Once generated, the public key

may be advertised. Protocols

suchasSSL/TLScontainprovi-

sions for network nodes to

transmit their public keys upon

request.

This scheme is not particu-

larly secure. If any computer

can generate key pairs, then

authentication is not possible.

Malicious users could easily

generate key pairs to masquer-

ade as a third party.

Certificate authorities

(CAs) are the solution to this

problem. When key pairs are

created, the public key is sub-

mitted to a CA. This authority

is responsible for validating the

identity and credentials of the

person or organization that

submits the key pairs. Levels of

validation range from verifying

nameande-mailaddressonlyto

verifyingtheidentityofthesub-

mitter through a credit card or

credit report. Verisign is the

most well known CA.

Once a CA has validated the

identity of the submitter, it is-

sues a certificate. Certificates

enable a trust relationship by

establishing the identities of

oneorbothpartiesinanetwork

transaction. The certificate is

digitally signed by the CA. It

follows that if the CA is trusted,

then the certificate may be

trusted, and the public key con-

tained within the certificate

may be trusted. Digital certifi-

cates come in many formats,

but the one of interest to major

Internet security protocols de-

scribed in this article is X.509,

an ITU specification. An X.509

certificate contains:

7 The submitter's public key;

7 The name of the issuer (CA);

7 The certificate's lifetime;

7 The digital signing

algorithm;

7 The digital signature of the

issuer.

SSL and TLS

The SSL protocol was devel-

oped by Netscape and first used

in its Navigator product in

1995. The Internet Engineer-

ing Task Force assumed stew-

ardship of the protocol and

eventually published RFC

2246. While SSL and TLS are

nearly identical as networking

protocols, some of the encryp-

tion and MAC algorithms are

slightly different. This article

willconcentrateontheprotocol

aspects and, for simplicity, call

them by the name TLS.

TLS contains provisions for:

7 Algorithm negotiation;

7 Encryption/decryption;

7 Message authentication

(via MACs);

7 Key exchange;

7 Digital signatures.

As shown in Figure 5 , TLS

must be layered on top of some

reliableconnectionprotocol.In

practice, this reliable connec-

tion protocol is TCP. (The WAP

protocol suite has a version

named wireless transport layer

security (WTLS), that runs

over datagrams.) Higher-level

protocols, such as HTTP and

SMTP, which are normally run

directly over TCP, may also be

run over TLS. Internet drafts

are now available for using TLS

with telnet, FTP, Kerberos and

a few other protocols.

TLS toolkits generally at-

tempt to closely mimic a sock-

ets programming interface.

The sockets-like API eases the

programming issues for the

implementers of the higher-

level protocols.

Inpractice,twoscenariosex-

ist for securing a protocol over

TLS: First, a different port is

used for secure traffic. The

higher-level protocol must lis-

ten on its normal port and its

secure port for network mes-

sages; Second, the higher-level

protocol must differentiate be-

tween normal traffic and secure

trafficonitsregularport.HTTP

uses this second strategy. When

a URL begins with "https://," a

securechannelissetupbetween

the client (a Web browser) and

the HTTP server.

TLS connections are always

role-based. The initiator of the

sessionisalwaystheclient.Fig-

ure 6 illustrates a sample TLS

sessionthatisbasedontheRSA

cipher suites; the variations for

other cipher suites are minor.

Instep1,theclientopensthe

TLS connection by sending a

"hello" message. This message

contains the protocol version

number (3.0 for SSL and 3.1 for

TLS) and the client-supported

typesofciphers,MACsandcom-

pression. (Currently, no stan-

dard defined compression

schemes exist.) The client also

sends a sequence of random

numbers that are used to gener-

ate the master secret. The mas-

tersecretwillbeexaminedlater.

In step 2, the server sends

the TLS version it supports and

selects one of the cipher/MAC

optionspresentedinstep1.The

server also sends a sequence of

random numbers that is used to

generate the master secret. In

step 3, the server sends its cer-

tificate, which includes the

public key of the server. In step

4, the server informs the client

that secret key generation may

begin.

As discussed earlier, asym-

metric encryption entails a

larger computational load than

symmetric encryption. That is

why protocols such as SSL/TLS

and IPSec use symmetric en-

cryption for the application

data. The next step for the cli-

entistogeneratethepremaster

secret, yet another sequence of

random data. The premaster

secret is encrypted with the

server's public key and sent

over the wire in step 5.

At this point, the server and

the client generate the master

secret which is a sequence of

data that is partitioned to pro-

vide the secret keys for client

and server encryption as well

as the secret keys used for cli-

ent and server MAC calcula-

tions. The master secret never

travels over the wire. The mas-

ter secret is generated both cli-

ent and server random values,

as well as the premaster secret.

Once the master secret is cal-

culated, secure communica-

tions may begin.

In step 6, the client informs

the server that all outgoing

traffic from the client will be

encrypted using the agreed-

upon encryption suite and in-

dependently generated keying

material. In step 7, the client

informs the server that the

client's portion of the initial

connection handshake is com-

plete. As forewarned in step 6,

the finished message in step 7

is encrypted.

Step 8 permits the server to

inform the client that all out-

going traffic originating from

Handshake Change cipher specAlert

Record layer

Application

Figure 8: TLS record format.

Figure 7: TLS record layer.

Protocol

Payload length

0 7 8 15 16 23 24 31

Minor version # Payload lengthMajor version #

Payload (up to 214 bytes)

the server will now be en-

crypted. In step 9, the server

sends an encrypted finished

message to the client to indi-

cate that the server's portion

of the initial connection hand-

shake is complete.

Steps 10 and 11 contain the

encrypted application layer

traffic passing between the cli-

ent and server. At some point,

either the client or server may

wish to end the connection. If

so, an explicit alert message is

transmitted.

The format of TLS mes-

sages is rather simple. As illus-

trated in Figure 7, four types

of messages are possible: hand-

shake, alert, change cipher

specification and application

data. Each transmission across

the wire is broken into a series

of one or more TLS records.

The format of a TLS record is

shown in Figure 8.

The U.S. government has

traditionally restricted the

strength of some of the ciphers

for exported products. These

restrictions were substantially

relaxed in January 2000, al-

though some restrictions still

exist for products exported to

embargoed nations such as

Cuba and Iraq.

Several commercial and

open-source implementations

exist for TLS solutions. Com-

mercial C-language implemen-

tations are available from

RSA Security, Certicom and

SPYRUS. The most popular

C-language open-source ver-

sion is OpenSSL, but others

exist as well. The open-source

versions are usually tailored

towards integration with the

Apache Web server.

Many network protocols

have existing or proposed se-

curity extensions. HTTP has

two methods of authentica-

tion: basic and digest. In both,

the server refuses to serve a re-

quest until the client authenti-

cates itself through a name/

password pair. When acting as

the HTTP client, a Web

browser will display a dialog

box to allow the user to type a

name/password combination.

The request is then resubmit-

ted to the server.

Basic authentication does

not encrypt the name/pass-

word pair as it goes over the

wire, although it does encode

it in the base64 encoding sys-

tem. In digest authentication,

when the server refuses to

serve a request, it provides a

nonce to the client. A nonce is

a one-time-use piece of data.

Once the client has obtained

the name/password pair, it

performs a hash of the

username, password, nonce,

HTTP method and the re-

quested URL. The client re-

turns only the hash value to the

server. In this way, the pass-

word is never sent in clear text.

Though defined for several

years, digest authentication is

only now being more widely

implemented.

Thisarticlehasdescribedthe

basics of Internet security pro-

tocolsandprovidedanexamina-

tion of TLS, one of the most

widely deployed protocols.

While we did not examine the

mathematics that forms the ba-

sis of cryptography, the algo-

rithmsarewell-documentedand

realizable in software, although

computationally intensive.

Despite the complexity of

the ciphers, most of the frame-

work surrounding an Internet

securityprotocoldealswithkey

management.

Key management is a chal-

lenge for all of these protocols,

especially for embedded solu-

tions.Evenso,thetechnologies

exist to protect your devices'

network traffic from Internet-

savvy malefactors.

[Embedded Systems Programming]





Comment on "Securing connected devices from Inte..."
Comments:  
*  You can enter [0] more charecters.
*Verify code:
 
 
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

 

Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

 
Back to Top