1. Trang chủ >
  2. Công Nghệ Thông Tin >
  3. An ninh - Bảo mật >

2: Using the Real-Time Clock Chip

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (2.78 MB, 385 trang )


Part IV


Key Management

Security Dangers

There are several types of attack that can be mounted against a system with a


16.3.1 Setting the Clock Back

Suppose the attacker can set the clock to some arbitrary time in the past. This

might allow all kinds of mischief. The machine mistakenly believes it lives in

the past. Maybe an attacker once had access to some data because he was a

temporary employee, but that access has now expired. With the wrong time

on the clock, a computer might now allow this ex-employee access to the

sensitive data. This problem has the potential of occurring every time some

access is revoked from a user. Setting the clock back might restore his access,

depending on how the rest of the system was designed.

Another interesting avenue of attack is automated tasks. Suppose an HR

computer makes salary payments automatically at the end of the month, using

direct deposit. Automated tasks like this are initiated by a program that checks

the time and has a list of tasks to perform. Repeatedly setting the clock back

can trigger the tasks repeatedly. If the task is set to start at midnight, the

attacker sets the clock to 23:55 (11:55 pm), and waits for the task to be started.

After the task finishes, the attacker sets the clock back again. He can repeat

this until the bank balance of the company is exhausted.

Another problem occurs in financial systems. It is important to get the

time of a transaction right because interest computations give different results

depending on when a transaction was performed. If you carry a large balance

on your credit card, it would be very advantageous to convince your bank’s

computer that the online payment you just made actually happened six months

ago, and avoid paying six months of interest.

16.3.2 Stopping the Clock

Every designer lives with the instinctive understanding that time does not

stand still. It is an unspoken assumption, too obvious to even document.

The systems they design rely on time behaving normally. But if the clock is

stopped, time appears to stand still. Things might not get done. And many

systems behave in unpredictable ways.

The simple problems are things like getting the wrong time on audit logs and

reports. The exact time of a transaction can have large financial consequences,

and sending out formal paperwork with the wrong date and time on it can

lead to serious complications.

Chapter 16

The Clock

Other problems might occur with real-time displays. Maybe the GUI programmer uses a simple system to display the current situation at the real-time

broker. Every ten seconds, he refreshes the display with the latest data. But

not all reports of financial transactions arrive with the same speed, due to

various delays. Just reporting the latest data that was received is going to give

an inconsistent view of the financial situation. Maybe one part of a transaction

has already been reported, but the other half has not. The money could show

up on the bank balance before the shares move from the stock holdings.

Accountants do not like to get reports where the numbers do not add up.

So the programmer does something clever. Each report of a financial

transaction is time-stamped and stored in a local database. To display a

consistent report, he takes a particular point in time and reports the financial

situation at that point in time. For example, if the slowest system has a fivesecond delay in reporting, he displays the financial situation of seven seconds

ago. It increases the display delay a bit, but it guarantees a consistent report.

That is, until the clock is stopped. Suddenly, the display reports the same

situation over and over again: the situation of seven seconds ago relative to

the (failed) clock. Oops!

16.3.3 Setting the Clock Forward

Setting the clock forward makes the computer think it lives in the future. This

leads to simple denial-of-service attacks. With the clock set four years in the

future, all credit card transactions are suddenly refused because all the cards

have expired. You cannot book online airline tickets either, because there is no

airline schedule out yet for those dates.

Substantial bidding at eBay auctions happens in the last seconds. If you

can move eBay’s clock forward just a little bit, you cut out many of the other

bidders and can obtain the item at a cheaper price.

A friend of ours had a problem of this nature with his billing system. Due to

a software error, the clock jumped ahead by about 30 years. The billing system

started to bill all his customers for 30 years of unpaid bills. In this case, it didn’t

result in a direct financial loss, but it could have been different if he had been

using automatic debits from bank accounts or credit cards. It certainly wasn’t

good customer relations.

There are also direct security risks involved with clocks set to a future time.

There are many situations in which certain data is to be kept secret until a

specific time, and made public after that time. In an automated system, setting

the clock forward provides access to the data. If this is a profit warning for a

publicly traded company, quite a bit of profit can be made from accessing this

data prematurely.



Part IV


Key Management

Creating a Reliable Clock

We don’t have a simple solution to the clock problem. We can suggest some

ideas and techniques, but the details depend too much on the exact working

environment and the risk analysis for us to be able to give universal answers.

Our goal here is therefore multifold. We wish to increase understanding,

encourage minimal reliance on a clock, identify key issues to consider, and

provide an example for how to think about building a reliable clock.

Most computers have, or can implement, a counter of some sort that starts

when the computer is booted. This might be a count of the number of CPU

clock cycles, a refresh counter, or something similar. This counter can be used

to keep track of the time since the last reboot. It is not a clock, as it provides

no information about what the actual time is, but it can be used to measure

elapsed time between events as long as both events happened since the last


The main use for this type of counter, at least in relation to our clock problem,

is to check for accidental errors in the real-time clock. If the real-time clock

doesn’t run properly, it will show discrepancies with the clock counter. This

is simple to test for, and provides some warning for certain error modes of

the clock chip. Note that the correspondence between clock time and counter

value has to be modified if the clock time is changed by an authorized user.

A second simple check is to keep track of the time of the last shutdown, or

the last time data was written to disk. The clock should not jump backwards.

If your machine suddenly boots in the year 1980, it is obvious that something

is wrong. It is also possible to stop the clock jumping forward too much. Most

computers are booted at least once a week. Perhaps you should get the user

to confirm the correct date if the machine hasn’t been booted for a week.1

That would catch the case of the clock jumping more than a week forward. Of

course, we’re assuming here that the user is not the adversary.

There are other methods of checking the time. You could ask a time server

on the Internet or an intranet. There are widely used time synchronization

protocols such as NTP [92] or SNTP [91]. Some of these protocols even provide

for authentication of the time data so an attacker cannot spoof the machine.

Of course, the authentication requires some kind of keying infrastructure. The

shared key with the time server could be a manually configured symmetric

key, but manually configuring keys is a hassle. It can also be done using a PKI,

but as we will see in Chapter 18, most PKI systems need a clock, which results

in a chicken-and-egg problem. Be careful if you rely on the cryptographic

protection offered by a clock synchronization protocol. The security of your

entire system could hinge on the security of the protocol.

1 As

most users will hit the OK button without bothering to look at the message, it is probably

better to ask the user to enter the current date, without showing him what the clock-date is.

Chapter 16


The Clock

The Same-State Problem

This brings us to a serious problem that you find on some hardware platforms.

We’re talking here about small embedded computers—something like a door

lock or a remote smart card reader. These typically consist of a small CPU, a

small amount of RAM, nonvolatile memory (e.g., flash) to store the program,

some communication channels, and further task-specific hardware.

You will notice that a real-time clock is often not included. Adding a realtime clock requires an extra chip, an oscillator crystal, and most importantly, a

battery. Apart from the extra cost, adding a battery complicates the device. You

now have to worry about the battery running out. Batteries can be sensitive to

temperature fluctuations, and the toxic chemicals in some batteries can even

lead to problems with shipping the hardware. For all of these reasons, many

small computers do not have a real-time clock.

Every time such a small computer is booted, it starts in exactly the same state.

It reads the same program from the same nonvolatile memory, initializes the

hardware, and starts operations. As this is a book about cryptography, we will

assume that some kind of cryptographic protocol is used in the communication

with other pieces of the system. But here is the problem: without a clock or

hardware random number generator, the embedded system will always repeat

the exact same behavior. Suppose the attacker waits until the gate computer

needs to open the gate because a truck needs to pass through. She reboots

the gate computer just before the gate needs to open (e.g., by interrupting

the power supply momentarily). After some initialization procedures, the

central system will command the gate computer to open the gate via the

communication channel. The next day, the attacker reboots the gate computer

again, and sends exactly the same messages as were sent the first time. As the

gate computer starts in the same state and sees the same inputs, it behaves the

same and opens the gate. This is bad. Note that it doesn’t matter if the gate

computer uses a time synchronization protocol. The protocol messages can be

replayed from yesterday, and the gate computer has no way of detecting this.

The same-state problem is not solved by any protocol.

A real-time clock chip solves this problem. The small embedded computer

can encrypt the current time with a fixed secret key to generate highly random

data. This data can in turn be used as a nonce in a cryptographic protocol. As

the real-time clock never repeats its state, the embedded computer can avoid

falling into the same-state trap.

A hardware random number generator has the same effect. It allows the

embedded computer to behave differently each time it is rebooted.

But if you don’t have a real-time clock or a random number generator, you

have a big problem. Sometimes you can fudge a bit and try to extract randomness from the clock skew between the local clock oscillator and the network


Xem Thêm
Tải bản đầy đủ (.pdf) (385 trang)