Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Computer Security > U.S. Gov't to use Full Disk Encryption on All Computers

Reply
Thread Tools

U.S. Gov't to use Full Disk Encryption on All Computers

 
 
Barry Margolin
Guest
Posts: n/a
 
      01-01-2007
In article <Xns98ABB196CD1Williamyourclothes@207.115.17.102 >,
William <starrwarz@g_~-clothes-~_m~more_clothes~ail.com> wrote:

> Does this full-disk encryption protect against most trojan-downloader
> users, though? I mean, if some program like Back Orifice got onto the
> machine, then couldn't the remote cracker get access to the data, even
> though the entire disk is encrypted, via whatever host-kernal's
> encryption/decryption mechanism?


This is not the threat they're attempting to deal with, so why is this
relevant? No single mandate is expected to be a panacea that can solve
all problems. They're trying to deal with the problems that have been
caused by all the highly-publicized losses of laptops.

--
Barry Margolin, http://www.velocityreviews.com/forums/(E-Mail Removed)
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
 
Reply With Quote
 
 
 
 
Ertugrul Soeylemez
Guest
Posts: n/a
 
      01-01-2007
Rick Merrill <(E-Mail Removed)> (06-12-31 20:42:16):

> I would assume that the encryption would also accompany
> compression. It takes about as many cycles to decompress as it does to
> decrypt?


Why? The one has nothing to do with the other (besides some base
theories). Compressed encryption would, however, increase security,
because it would destroy a lot of redundancy. But firstly this is not
possible for online encryption. Secondly it would decrease performance
drastically. And finally today's encryption modes (to mention at least
CBC and LRW; the latter is favorable IMO) successfully scramble that
redundancy.


Happy new year --
Regards,
E.S.
 
Reply With Quote
 
 
 
 
Rick Merrill
Guest
Posts: n/a
 
      01-01-2007
Ertugrul Soeylemez wrote:
> Rick Merrill <(E-Mail Removed)> (06-12-31 20:42:16):
>
>> I would assume that the encryption would also accompany
>> compression. It takes about as many cycles to decompress as it does to
>> decrypt?

>
> Why? The one has nothing to do with the other (besides some base
> theories). Compressed encryption would, however, increase security,
> because it would destroy a lot of redundancy. But firstly this is not
> possible for online encryption. Secondly it would decrease performance
> drastically. And finally today's encryption modes (to mention at least
> CBC and LRW; the latter is favorable IMO) successfully scramble that
> redundancy.


There are tools that compress using a password - think of runlength
encoding with a CRC.
 
Reply With Quote
 
Saqib Ali
Guest
Posts: n/a
 
      01-01-2007
> Does this full-disk encryption protect against most trojan-downloader
> users, though? I mean, if some program like Back Orifice got onto the
> machine, then couldn't the remote cracker get access to the data, even
> though the entire disk is encrypted, via whatever host-kernal's
> encryption/decryption mechanism?


That is not what the objective of this project is. The project is aimed
towards protecting the data while it is "at rest". i.e. in case of the
theft of the mobile device. The intend is to prevent exposure of
confidential data when a Gov't agency loses a laptop.

But having said that, Enova's X-Wall Asic (Hardware based FDE) supports
a "Pass Through Mode". Which makes it possible to configure your
system such that any attempt to download data to an "outside the box"
location (e.g. a Web Site or other IP address) would automatically
invoke the "Pass Though Mode" and all the downloader gets is the
encrypted data.

If you are the owner of that data you can still have access if you have
an X-Wall enabled device using the same key/dongle combination. This
way you can have secure access to you data anywhere you are so long as
you have a network connection.

saqib
http://www.full-disk-encryption.net

 
Reply With Quote
 
Ertugrul Soeylemez
Guest
Posts: n/a
 
      01-01-2007
Rick Merrill <(E-Mail Removed)> (07-01-01 15:34:55):

> > > I would assume that the encryption would also accompany
> > > compression. It takes about as many cycles to decompress as it does
> > > to decrypt?

> >
> > Why? The one has nothing to do with the other (besides some base
> > theories). Compressed encryption would, however, increase security,
> > because it would destroy a lot of redundancy. But firstly this is
> > not possible for online encryption. Secondly it would decrease
> > performance drastically. And finally today's encryption modes (to
> > mention at least CBC and LRW; the latter is favorable IMO)
> > successfully scramble that redundancy.

>
> There are tools that compress using a password - think of runlength
> encoding with a CRC.


Yes, but "compression using a password" is actually "compressing, and
then encrypting with a password". The CRC is something completely
independent of both steps. It only helps spotting transmission errors.
And encoding has nothing (much) to do with encryption.


Regards,
E.S.
 
Reply With Quote
 
WinTerMiNator
Guest
Posts: n/a
 
      01-02-2007
Saqib Ali wrote:
> To address the issue of data leaks from stolen or missing laptops, US
> Government is planning to use Full Disk Encryption (FDE) on all of the
> Government owned computers. On June 23, 2006 a Presidential Mandate
> was put in place requiring all agency laptops to fully encrypt data
> on the HDD. The US Government is currently conducting the largest
> single side-by-side comparison and competition for the selection of a
> Full Disk Encryption product. This implementation will end up being
> the largest single implementation ever, and all of the information
> regarding the competition is in the public domain. The selected
> product will be deployed on Millions of computers in the US federal
> government space. The evaluation will come to a end in 90 days.
>
> ...... Read complete article at:
> http://www.full-disk-encryption.net/fde_govt.html


Hello,

There is an alternative to full disk encryption, providing the same privacy
level, at no cost: to run a virtual machine whose files are stored in an
encrypted container.

Examples:

- Virtual machine software: Virtual PC (on Windows host machine), VMware and
Qemu (on Windows and Linux host machines)
- Guest machines: any X86 machine (DOS, Windows, Linux, FreeBSD...)
- OTFE encryption software: TrueCrypt (Windows, Linux).

The whole solution can be done at no cost.

The guest machine doesn't leak anything; all its files (including temp and
swap files) are in an encrypted container.

Backup of the host machine is unchanged, backup of the guest machine is
simply and securely done by copying the file corresponding to the encrypted
container on a backup media (i.e. USB mass storage disk).

Precautions should be taken to transfer data to the guest machine without
letting "plain" traces on the host machine; for example, a secure ftp client
connects from the guest machine to a secure ftp server on a LAN; encrypted
data get through the host TCPIP stack to the guest machine.

I built such a solution very easily with:
- host machine: Windows XP,
- virtual machine software: VMware Player (yes, you can build a guest
machine with VMware Player, even if VMware says it is not possible; see for
example http://www.easyvmx.com/easyvmx.shtml; you also need to get VMware
tools from a VMware test distribution),
- guest machine: Windows 2000 Professional (with two vmdk disks, one of 4 GB
for system, one of 5 GB for data),
- OTFE software: TrueCrypt (one container, 12 GB contains the two vmdk disks
+ vmx configuration file; this lets room for VMware temporary files and for
enventually copying the ISO image of a CD-ROM to be mounted).

I think this solution less risky to implement than a full disk encrytption
one (newsgroups are full of people having done something wrong and unable to
recover their system). And TrueCrypt is an *OpenSource* software (how could
you rely on an undisclosed source encryption software)?

Just some comments about www.full-disk-encryption.net site:

- In the list of FDE, you could add GBDE and GELI, both FreeBSD modules
allowing full disk encryption, see
http://www.freebsd.org/doc/en_US.ISO...ncrypting.html
and
http://events.ccc.de/congress/2005/f...Encryption.pdf.
GBDE and GELI are OpenSource softwares.

- The site does not mention hardware solutions, for example HP Drivecrypt on
some notebooks, Trust Way RCI (Bull) or Flagstone disks (Hermitage
Solutions).

- Your comparative list should indicate which solutions are OpenSource and
which aren't.

Regards,


--
Michel Nallino aka WinTerMiNator
http://anonapps.samizdat.net (Anonymat sur Internet)
Adresse e-mail invalide; pour me contacter:
http://www.cerbermail.com/?vdU5HHs5WG


 
Reply With Quote
 
Rick Merrill
Guest
Posts: n/a
 
      01-02-2007
Ertugrul Soeylemez wrote:
> Rick Merrill <(E-Mail Removed)> (07-01-01 15:34:55):
>
>>>> I would assume that the encryption would also accompany
>>>> compression. It takes about as many cycles to decompress as it does
>>>> to decrypt?
>>> Why? The one has nothing to do with the other (besides some base
>>> theories). Compressed encryption would, however, increase security,
>>> because it would destroy a lot of redundancy. But firstly this is
>>> not possible for online encryption. Secondly it would decrease
>>> performance drastically. And finally today's encryption modes (to
>>> mention at least CBC and LRW; the latter is favorable IMO)
>>> successfully scramble that redundancy.

>> There are tools that compress using a password - think of runlength
>> encoding with a CRC.

>
> Yes, but "compression using a password" is actually "compressing, and
> then encrypting with a password". The CRC is something completely
> independent of both steps. It only helps spotting transmission errors.
> And encoding has nothing (much) to do with encryption.
>
>
> Regards,
> E.S.


Originally true, but the particular CRC pattern is chosen to deal with
the expected noise impact during transmission (e.g. 1 sec bursts). You
can use other CRC patterns to encrypt.
 
Reply With Quote
 
Saqib Ali
Guest
Posts: n/a
 
      01-02-2007
> There is an alternative to full disk encryption, providing the same privacy
> level, at no cost: to run a virtual machine whose files are stored in an
> encrypted container.


All of your suggestion involve quite a bit of overhead, are inelegant
and require user interaction.

One of the requirement for this Government project is that the solution
has to be transparent to the user.

saqib
http://www.full-disk-encryption.net

 
Reply With Quote
 
Ertugrul Soeylemez
Guest
Posts: n/a
 
      01-03-2007
Rick Merrill <(E-Mail Removed)> (07-01-02 12:57:24):

> > > There are tools that compress using a password - think of
> > > runlength encoding with a CRC.

> >
> > Yes, but "compression using a password" is actually "compressing,
> > and then encrypting with a password". The CRC is something
> > completely independent of both steps. It only helps spotting
> > transmission errors. And encoding has nothing (much) to do with
> > encryption.

>
> Originally true, but the particular CRC pattern is chosen to deal with
> the expected noise impact during transmission (e.g. 1 sec bursts). You
> can use other CRC patterns to encrypt.


I really don't know why you relate CRC to encryption in any way. CRC is
just a checksum algorithm. It's not secure, it's not clever, it's just
a checksum.


Regards,
E.S.
 
Reply With Quote
 
Rick Merrill
Guest
Posts: n/a
 
      01-03-2007
Ertugrul Soeylemez wrote:
> Rick Merrill <(E-Mail Removed)> (07-01-02 12:57:24):
>
>>>> There are tools that compress using a password - think of
>>>> runlength encoding with a CRC.
>>> Yes, but "compression using a password" is actually "compressing,
>>> and then encrypting with a password". The CRC is something
>>> completely independent of both steps. It only helps spotting
>>> transmission errors. And encoding has nothing (much) to do with
>>> encryption.

>> Originally true, but the particular CRC pattern is chosen to deal with
>> the expected noise impact during transmission (e.g. 1 sec bursts). You
>> can use other CRC patterns to encrypt.

>
> I really don't know why you relate CRC to encryption in any way. CRC is
> just a checksum algorithm. It's not secure, it's not clever, it's just
> a checksum.
>
>
> Regards,
> E.S.



CRC != checksum in any way shape or form. Check with your professor.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
UEFI and full-disk-encryption feenberg Windows 64bit 4 01-08-2012 01:07 AM
So why don't we use full disk encryption on all mobile devices? Saqib Ali Computer Security 24 12-16-2009 11:30 PM
full disk encryption "Backup" gojlt2 Computer Security 3 08-12-2008 07:12 AM
Full Disk Encryption Survey Saqib Ali Computer Security 22 09-07-2007 04:43 PM
Full Disk Encryption - Anyone Tried These? Tim Weaver Computer Security 6 06-14-2004 02:32 PM



Advertisments