RE: TrueCrypt mount without TrueCrypt ?

"Minh Van Le" <[email protected]> Wed, 24 Mar 2010 20:31:24 +1100
Newsgroups gmane.org.user-groups.slug.chat
Message-ID <[email protected]>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Daniel Pittman
> Sent: Saturday, 20 March 2010 9:26 PM
> To: [email protected]
> Subject: Re: [chat] TrueCrypt mount without TrueCrypt ?
> 
> 
> "Minh Van Le" <[email protected]> writes:
> 
> > Can a TrueCrypt volume be mounted on a PC that does not have TrueCrypt
> > installed ?  I want an encrypted USB flash drive that has its own "auto
> > extractor (or mount)" mechanism.
> 
> I don't know the answer to your question, I fear.  I am 
> interested, though, to
> understand what threat you are going to defend yourself against with this
> arrangement?

Physical theft of my USB stick.

I would like to encrypt all data on the USB stick, and when I put it into a PC (usually with Windows or Linux) that I can double-click some DLL or executable on the USB stick that will then transparantly decrypt the file system contents.

> It seems to me that this, especially from a single vendor source, is an
> invitation to lose your data almost immediately.

Sure. But it's better than nothing.

TrueCrypt to my knowledge is fairly stable and reliable and won't corrupt your data. 

> My attack model is pretty simple; I assume:
> 
> 1. If someone bothers to encrypt the content then they must consider it of
>    some value.

Well, in my specific case most of the data is not necessarily valuable. However I arbitrarily put valuable data on it. 

If somebody pulled my USB stick out of my computer and put it in theirs, I want to prevent them from viewing/accessing its contents until they unencrypt it. 

> 2. At least some of the people will actually be correct in their 
> assessment of
>    value, and won't just be crypto geeks encrypting everything for fun.
> 
> 3. Software from a single, major vendor like TrueCrypt can be 
> identified by
>    the OS, and will be reasonably standard.
> 
> 4. Emulating, violating, or otherwise intercepting authentication to that
>    software should be reasonably possible; certainly, on Win32 
> and Linux this
>    shouldn't be a hugely difficult task as they are generally not secure
>    enough to prevent such attacks.
> 
> 5. Intercepting access to the now-decrypted data should be reasonably
>    possible, and there are a wide range of channels available that can be
>    undetectably exploited to this end.
> 
> 
> At that point I think that it is reasonable to conclude that an 
> attacker who
> can deliver hostile software to the system can capture the authentication
> information, or access the files after authentication, without too much
> trouble.

Yeah but there's also hardware encryption. Eg. a specific disk controller that encrypts data. The disk controller has its own read-only non-"flashable" BIOS. 

> At that stage you only need an attack vector; I suggest that the 
> widespread
> "botnet" infections that have been proved to steal data including address
> books, financial data, and "any data, to hold hostage", would be 
> sufficient.

Yeah but now you're talking about software / application-level security. This 

> Which, in turn, leads me to wonder: how can you trust any system 
> that didn't
> have a pre-installed secure configuration with this data, but 
> most especially
> how can you assume it is safe to install the decryption tools on demand?

My purpose is to find a flexible / portable way to prevent unauthorised initial access to the data on my USB stick if it were plugged into a PC. 

I have a company-issued USB stick that came with its own driver software that 

1. When you plug it into a PC (running Windows) it will not show anything on the drive except a "logon.exe" & "io.dll".

2. When you click on "logon.exe" it will ask you for a password. If the correct password is entered it will then show all data on the drive. 

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html