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 )
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 ﬁnishes, the attacker sets the clock back again. He can repeat
this until the bank balance of the company is exhausted.
Another problem occurs in ﬁnancial 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 ﬁnancial consequences,
and sending out formal paperwork with the wrong date and time on it can
lead to serious complications.
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 ﬁnancial 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 ﬁnancial 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 ﬁnancial
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 ﬁnancial
situation at that point in time. For example, if the slowest system has a ﬁvesecond delay in reporting, he displays the ﬁnancial 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 ﬁnancial 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
speciﬁc time, and made public after that time. In an automated system, setting
the clock forward provides access to the data. If this is a proﬁt warning for a
publicly traded company, quite a bit of proﬁt can be made from accessing this
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 modiﬁed 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 conﬁrm 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  or SNTP . 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 conﬁgured symmetric
key, but manually conﬁguring 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.
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.
The Same-State Problem
This brings us to a serious problem that you ﬁnd 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., ﬂash) to store the program,
some communication channels, and further task-speciﬁc 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 ﬂuctuations, 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 ﬁrst 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 ﬁxed 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