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

Securing connected devices from Internet outlaws

Posted: 01 Jul 2003     Print Version  Bookmark and Share



By Steve Kapp

Chief Technologist

EMRT Consultants Inc.

E-mail: [email protected]

Internet-enabled devices are

gaining popularity, but not ev-


orable intentions. Hackers and


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-


on secure sockets layer (SSL)

and transport layer security


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.


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


financial and legal documenta-


ferent products and applica-

tions have different security

needs. Hence, security services

may be limited or broad in


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


main focus of Internet security

is to facilitate a trust relation-

ship between various network


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-


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


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


level of





Integrity Identity

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










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



Shared secret key

Figure 2: Symmetric encryption schemes are conceptually simple.


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.


after called Bob) sends an en-

crypted message to node A

(hereafter called Alice). In the

parlance of cryptography,




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


To use a symmetric cipher,

Bob and Alice must not only

agree on the algorithm, but

also on the key. Here lies one of


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



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


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


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.


public but the decryption key

was private and known only to

the receiver. The sender of the

message (Bob in this case)


tents with the public key, and

the receiver (Alice) would de-

crypt the message with the pri-


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)






Public key repository








Alice's private key

Alice's public key

Figure 3: Asymmetric encryption using public keys.






Public key repository









public key


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


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-


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-


two large prime numbers. Sym-

metric encryption is generally

an order of magnitude faster

and places a small burden on

the processor.


tocols such as SSL/TLS provide

mechanisms for secure secret

key exchange. Often, the secret


the use of public-key encryp-


cret key generated by Bob, en-

crypted with Alice's public key

and then transmitted to Alice.


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.


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-


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


A MAC may also be used as a


the sender and receiver share

the same secret key used in the

MAC calculation, consider the

case when the sender includes


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


security services: encryption/

decryption, digital signatures

and key exchange. This article

has not yet addressed the issue






Figure 5: Protocol stack with SSL/ TLS.


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)


Application data


7 7 7














Figure 6: TLS message exchange diagram.

of key management. In particu-

lar, the following questions

should be answered:

7 Who generates these key


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


sions for network nodes to

transmit their public keys upon


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



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


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


7 The digital signature of the



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


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


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.


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


uses this second strategy. When

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


the client (a Web browser) and

the HTTP server.

TLS connections are always

role-based. The initiator of the


ure 6 illustrates a sample TLS


cipher suites; the variations for

other cipher suites are minor.


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


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-


In step 2, the server sends

the TLS version it supports and

selects one of the cipher/MAC


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


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-


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


Figure 8: TLS record format.

Figure 7: TLS record layer.


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


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



basics of Internet security pro-


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-


realizable in software, although

computationally intensive.

Despite the complexity of

the ciphers, most of the frame-

work surrounding an Internet



Key management is a chal-

lenge for all of these protocols,

especially for embedded solu-


exist to protect your devices'

network traffic from Internet-

savvy malefactors.

[Embedded Systems Programming]

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


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