[mdlug] Disk encryption - once copied its vunerable

[Aaron Kulkis]

gib at juno.com wrote:
>  
> Okay, I understand that having the key makes it a lot easier to
 > decrypt the data. But isn't it possible to decrypt the data by
 > brute force too?   So, encryption is not completely safe, right?
 >
> I was watching the new Knight Rider (talking car) on TV. The
 > inventor's laptop was stolen by the bad guys.  But then a
 > statement  was made that they recovered the laptop and the
 > encryption was not broken.  I think that once the bad guys
 > have a laptop they can make a copy of the data and then they
 > can allow the laptop to be returned.  They can take their
 > time cracking the data.
> 

Correct.

As a communications soldier, I am educated on the impact of
cryptography on communications.

For military systems I've used, or otherwise trained with or
been trained on, the stronger the cryptographic protection,
the more cumbersome it is to use.

Therefore, for practical reasons, (time, weight, etc), the
goal is always to choose the LEAST cryptographic protection
needed for a message -- the reason is best explained in the
following scenario

Suppose I want to arrange a meeting (say, for the transfer
of supplies or food or something).

In the mid-1980's, there were several choices to choose from:

1) a simple, but clever encryption system which could be used
for encrypting primarily times and map-coordinates.
Academic cryptographic literature would refer to this as a
cipher due to the 1-to-1 relationship between the number of
plain-text characters, and the number of encrypted characters.
The entire encrypt/decrypt system fits on a 3" x 4" piece
of paper.
{now made obsolete by a system called "SINCGARS")

2) A true code system, consisting of 3-letter groups,
each of which would represent a words, prefix, suffix,
a common syllable, a letter, a number, or a group of
numerals (such as "000").  Encryption by this method
can be done "in the field", but requires a very tedious
process of looking up each substitution in a book
(about 3" x 5").  Encrypting a 15-word message could
easily take 30 minutes or longer, and decrypting with
the book takes about the same amount of time.
(now made obsolete by SINCGARS)

3) Using a RATT (RAdio TeleType) network.  This
generally required a "RATT-rig" ... a metal container
carried on the back of a truck, which would hold all
of the encryption-decryption electronics, plus the
associated teletype and message-storage equipment.
(for example, messages could be prepared on a
magnetic tape, or even a punch tape... and then
held for transmission at a later time.  If someone
knew that they would send one of two messages, depending
on some event, both of those messages could be prepared
ahead of time, and then the applicable one transmitted
once the decision of which to send had been made).
Advantage -- large messages can be encrypted and
decrypted very quickly, using complex algorithms,
but due to both the expense and bulk of the equipment,
typically available only at Brigade level or higher.
I.e. Battalions and companies typically don't have
this equipment)

By the mide 1990's, another option became available:

So...back to our scenario...to arrange (or order) this
meeting, which system do you choose?

If this is at a brigade/division/corps/army level,
the obvious choice is the RATT rig.
But if it is a battalion or company level thing,
which do you choose?

Well, that depends on the situation.
A: If the meeting is to occur only a few hours from
now, and the overall message doesn't contain any
reference to what will occur at the meeting, (the
message might say, "for a FOXTROT meeting" (with
the meaning of FOXTROT previously established) or
any other clues about location other than the
grid reference, what would you choose?

B: If the meeting is to occur 6 days from now, and
the person sending the message also says to bring
a number of vehicles for hauling whatever stuff...
which would you choose?

In case A, the simple 3"x4" cipher card would be
most appropriate.

In case B, the 3-letter code-groups would be most
appropriate.

Why?
The major reason is the element of time.

One assumption in military communications is that ALL
your messages are received, RECORDED and even archived
by the opposing forces, and that each message will have
a competent team of cryptographers working on it (because
you never know WHICH message the enemies cryptographers
will actually choose to attack by analysis)

So...since the cipher system on the 3"x4" paper was
estimated to protect a message for 48 hours (once
enough messages were intercepted and recorded, the
entire body of message traffic could be subjected
to meta-analysis).  So, in scenario A, the 3"x4", if
the message is otherwise indirect enough, simply
encrypting the time and location with this cipher
could be "good enough" because by the time the opposing
forces crack your message, your meeting is an event
that already ended at least 24 hours ago.

On the other hand, for scenario B, this is not strong
enough encryption... the opposing forces could crack
the message and still have 48+ hours to react (by
deploying forces to the meeting site. for example,
or conducting ambushes on the roads surrounding
the meeting site, and destroying/capturing both
men and equipment or supplies)..so, because of this,
the code-book with the 3-letter codes is the bare
minimum.  If the meeting was, say, TOP SECRET, but
the 3-letter code book was only rated for SECRET,
then the 3-letter code book could not be used, and
some other method of delivering the message would
have to be used -- such as hand delivery, use of
a "one time pad" message, etc.

So how does this matter for computers?

If your encrypted data were copied, (the equivalent
of the military scenario of interception and recording),
how far into the future would that information still
be damaging if it were revealed only to those who have
the ability and desire (and nobody else) to use that
information in a way which would adversely effect you?

For example... if most of the information you encrypt
is only of usefulness for a few weeks, then gonig to
the trouble of using an encryption method which would
take 10+ years to crack is probably not good.

Why?

Because you probably have OTHER data which even 10 years
from now, you STILL want to be protected.  By encrypting
your "damaging for a week" data with the same system as
your "damaging for a decade" data... you give an attacker
a larger amount of data to work with for meta-analysis
which ultimately lessens the amount of time needed to
attack any individual encrypted item.

By using different systems, depending on how LONG it
needs to be protected... the large mass of short-term
sensitive messages are no longer useful for decrypting
the long-term sensitive data, because they are using
completely different systems.

In terms of something like PGP..a variation on this
could mean using one key for short-term sensitive data,
another for "medium-term" sensitive data, a 3rd key
for long-term sensitive data" and a 4th key for data
so sensitive that you don't want it to be revealed at
any time while you are still alive...and possibly even
a 5th for data which you hope to keep secret even from
members of your grandchildren's generation. (say two
generations after you die)







4) In the mid 1990's, a computer-based system.  Using a
small computer (from a technological standpoint, it
appeared to be a miniaturized Commodore 64 with a
small built-in LCD screen), a message could be typed
in.  The computer had both telephone line jacks and
also a two-piece acoustic modem (the two halves of
which could be temporarily attached, using velcro
straps, to the handset of a typical voice radio), as
well as a parallel port for attaching a printer, and
also a serial port.).  Plastic chassis, appropriate
for use only in a company headquarters or higher.
Perhaps a ruggedized version was produced (more weight,
of course) but I never saw one.



> 
> -- "Jeff Hanson" <jhansonxi at gmail.com> wrote:
> On Fri, Feb 22, 2008 at 10:53 AM, Garry Stahl <tesral at comcast.net> wrote:
>> http://www.networkworld.com/news/2008/022108-disk-encryption-cracked.html?page=1
>>
>>  Network World article pointing out that who controls the physical
>>  computer, controls the data in it.  There is a method to crack disk
>>  encryption.  It ain't easy, and you would have to have it ready, but it
>>  is possible.
> 
> The security implications of loading the decryption keys into DRAM is
> something I though of myself a while ago.  I hadn't realized that the
> data retention was that long without power or that cooling them could
> increase the data lifetime.  My theory was that it would be possible
> to read the memory bus while the system was active and pick up the
> keys that way.  According to the report you can chill the DRAM and
> just put it in another system for reading which makes encryption about
> as useful as a chastity belt.  I disagree with Steven Sprague about
> the effectiveness of hardware-based encryption devices as they also
> have to load the key making them just as vulnerable.  The only
> advantage they offer is a more complicated architecture that would
> have to be reverse engineered first so that an attacker would know
> where to look before attempting to find the key (obfuscation).  I was
> thinking that storing the key in a CPU register would be better as the
> complexity and small feature size would make it a lot harder to
> extract.  OpenBSD, IIRC, randomizes memory locations so theoretically
> it would be more difficult to find a key (again obfuscation).  I think
> the Linux solution is to have the kernel wipe entire memory space
> before halting or suspending.
> _______________________________________________
> mdlug mailing list
> mdlug at mdlug.org
> http://mdlug.org/mailman/listinfo/mdlug
> 
> 
> _____________________________________________________________
> Click for free info on using seach engines to expand your business.
> http://thirdpartyoffers.juno.com/TGL2111/fc/Ioyw6iifVr4L6N73yOzTImEQJlllblPjibWxajC7Lp2ebNLBWDxzFq/
> _______________________________________________
> mdlug mailing list
> mdlug at mdlug.org
> http://mdlug.org/mailman/listinfo/mdlug
>