[gentoo-user] [OT] Time-lock USB stick

[gentoo-user] [OT] Time-lock USB stick

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 223 bytes --]

Does anybody know of time lock flash drives?

The scenario I'm looking at is to have a drive that's only accessible
for a certain amount of time after being powered on. It would hold
crypto keys in a server context.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-user] [OT] Time-lock USB stick

[William Kenworthy]

On 20/03/13 10:58, Michael Mol wrote:
> Does anybody know of time lock flash drives?
>
> The scenario I'm looking at is to have a drive that's only accessible
> for a certain amount of time after being powered on. It would hold
> crypto keys in a server context.
>
Something like this?

http://www.tomshardware.com/reviews/USB-Flash-Drives,2003-6.html

It does sound like you want a "dongle" like autocad used (?) to use.

I think the real solution though would be some kind of check with a
remote site that would expire the keys

BillK

Re: [gentoo-user] [OT] Time-lock USB stick

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]

On 03/19/2013 11:18 PM, William Kenworthy wrote:
> On 20/03/13 10:58, Michael Mol wrote:
>> Does anybody know of time lock flash drives?
>>
>> The scenario I'm looking at is to have a drive that's only accessible
>> for a certain amount of time after being powered on. It would hold
>> crypto keys in a server context.
>>
> Something like this?
> 
> http://www.tomshardware.com/reviews/USB-Flash-Drives,2003-6.html
> 
> It does sound like you want a "dongle" like autocad used (?) to use.
> 
> I think the real solution though would be some kind of check with a
> remote site that would expire the keys

Not so much. The idea would be that you could power cycle the device to
get access to it again. The device would be read for the keys at system
bootup, but then would shut itself off after a few minutes to prevent
the keys from being read from disk. (There's still the risk of them
being read from the memory of the process using them, but that's
slightly more difficult, and security is all about raising the bar.)



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-user] [OT] Time-lock USB stick

[Michael Orlitzky]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/19/2013 11:28 PM, Michael Mol wrote:
> 
> Not so much. The idea would be that you could power cycle the
> device to get access to it again. The device would be read for the
> keys at system bootup, but then would shut itself off after a few
> minutes to prevent the keys from being read from disk. (There's
> still the risk of them being read from the memory of the process
> using them, but that's slightly more difficult, and security is all
> about raising the bar.)
> 

Eject the USB drive after five minutes? This raises the bar
significantly, to "has tried to send the 'close CD tray' command to a
USB stick before."

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRSTmpAAoJEBxJck0inpOiKusP/1sVI0A5hbT1pE8yRu+Ydn5W
j+O6o9j+r2Tqzkay0/tXPWs8HJlM7c8yQcaRvQoCiau2mQzitSk+nLxCPh/GLpis
2d49ihFKmVFk7qrIzMkrHoV4XRc2jVfgiEq+n8W5dYpODPCX9N4MQidgiYePnZ52
YEtxijEkfPk73j5jPoJh6SNWtzrdLUC6DH4mmghqgmZcn4glkhWpqIU6U/tj4hJT
iN67F5g0g8YSIQNTBsTO/TLrQmrHdb/iT2v9hTxeL+Ly+xjHKJmSikP+f0rOOrQn
vXbJHGk2IAgajDHcdG3jDJvoQDgA0vl+uJ/i4tj++rwMNNXxX7MmFq9qGqGGjBp4
nwFVJn9QGMHq2boDXISXlz+zNcjLWcaxNrXQiqSB5sqnbvjg27/NCDaQG8+ZgWzX
a/JGLqu3l7LoribH54E51PGdpKiiooDgYjgQkB9ZrSM6/X14JftqWavEALrLQXfM
ud32XTgMGiBVqyjtGQ4VDS2KtQnZAWhORMQJvOx3nwApUiXOlyX8xoyazYetnTaC
pZFgYRgmNYQodweJNrpz28EekEhwr1A/HHYhe5ANqUSO44xZBhsfEhtz0ycVd0ok
2JnCC4WwmQtqifD4S3hEsn4BN1XvxCH8YhXV6S+ApD9bo22ybZFw7f54tMSV0L/d
brkafk2u3Bhnh2yFr+6k
=pX91
-----END PGP SIGNATURE-----

Re: [gentoo-user] [OT] Time-lock USB stick

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

On 03/20/2013 12:23 AM, Michael Orlitzky wrote:
> On 03/19/2013 11:28 PM, Michael Mol wrote:
> 
>> Not so much. The idea would be that you could power cycle the
>> device to get access to it again. The device would be read for the
>> keys at system bootup, but then would shut itself off after a few
>> minutes to prevent the keys from being read from disk. (There's
>> still the risk of them being read from the memory of the process
>> using them, but that's slightly more difficult, and security is all
>> about raising the bar.)
> 
> 
> Eject the USB drive after five minutes? This raises the bar
> significantly, to "has tried to send the 'close CD tray' command to a
> USB stick before."

That's sick, wrong and beautiful. I love it. :)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-user] [OT] Time-lock USB stick

[J. Roeleveld]

Michael Orlitzky <michael@orlitzky.com> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 03/19/2013 11:28 PM, Michael Mol wrote:
>> 
>> Not so much. The idea would be that you could power cycle the
>> device to get access to it again. The device would be read for the
>> keys at system bootup, but then would shut itself off after a few
>> minutes to prevent the keys from being read from disk. (There's
>> still the risk of them being read from the memory of the process
>> using them, but that's slightly more difficult, and security is all
>> about raising the bar.)
>> 
>
>Eject the USB drive after five minutes? This raises the bar
>significantly, to "has tried to send the 'close CD tray' command to a
>USB stick before."
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v2.0.19 (GNU/Linux)
>
>iQIcBAEBAgAGBQJRSTmpAAoJEBxJck0inpOiKusP/1sVI0A5hbT1pE8yRu+Ydn5W
>j+O6o9j+r2Tqzkay0/tXPWs8HJlM7c8yQcaRvQoCiau2mQzitSk+nLxCPh/GLpis
>2d49ihFKmVFk7qrIzMkrHoV4XRc2jVfgiEq+n8W5dYpODPCX9N4MQidgiYePnZ52
>YEtxijEkfPk73j5jPoJh6SNWtzrdLUC6DH4mmghqgmZcn4glkhWpqIU6U/tj4hJT
>iN67F5g0g8YSIQNTBsTO/TLrQmrHdb/iT2v9hTxeL+Ly+xjHKJmSikP+f0rOOrQn
>vXbJHGk2IAgajDHcdG3jDJvoQDgA0vl+uJ/i4tj++rwMNNXxX7MmFq9qGqGGjBp4
>nwFVJn9QGMHq2boDXISXlz+zNcjLWcaxNrXQiqSB5sqnbvjg27/NCDaQG8+ZgWzX
>a/JGLqu3l7LoribH54E51PGdpKiiooDgYjgQkB9ZrSM6/X14JftqWavEALrLQXfM
>ud32XTgMGiBVqyjtGQ4VDS2KtQnZAWhORMQJvOx3nwApUiXOlyX8xoyazYetnTaC
>pZFgYRgmNYQodweJNrpz28EekEhwr1A/HHYhe5ANqUSO44xZBhsfEhtz0ycVd0ok
>2JnCC4WwmQtqifD4S3hEsn4BN1XvxCH8YhXV6S+ApD9bo22ybZFw7f54tMSV0L/d
>brkafk2u3Bhnh2yFr+6k
>=pX91
>-----END PGP SIGNATURE-----

I don't think it is possible to un-eject a usb-drive without powercycling it.

And why wait 5 minutes to eject it? Simply do that as soon as the keys are read?

Extra option:
Stick the usbdisk driver as a module in a ramdisk and then rmmod it.
Remove the module from disk
And use module signing. From what I understand. The keys for that are generated at compile time? And you can delete them from the kernel sources after compiling.

--
Joost
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] [OT] Time-lock USB stick

[J. Roeleveld]

"J. Roeleveld" <joost@antarean.org> wrote:

>Michael Orlitzky <michael@orlitzky.com> wrote:
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>On 03/19/2013 11:28 PM, Michael Mol wrote:
>>> 
>>> Not so much. The idea would be that you could power cycle the
>>> device to get access to it again. The device would be read for the
>>> keys at system bootup, but then would shut itself off after a few
>>> minutes to prevent the keys from being read from disk. (There's
>>> still the risk of them being read from the memory of the process
>>> using them, but that's slightly more difficult, and security is all
>>> about raising the bar.)
>>> 
>>
>>Eject the USB drive after five minutes? This raises the bar
>>significantly, to "has tried to send the 'close CD tray' command to a
>>USB stick before."
>>
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v2.0.19 (GNU/Linux)
>>
>>iQIcBAEBAgAGBQJRSTmpAAoJEBxJck0inpOiKusP/1sVI0A5hbT1pE8yRu+Ydn5W
>>j+O6o9j+r2Tqzkay0/tXPWs8HJlM7c8yQcaRvQoCiau2mQzitSk+nLxCPh/GLpis
>>2d49ihFKmVFk7qrIzMkrHoV4XRc2jVfgiEq+n8W5dYpODPCX9N4MQidgiYePnZ52
>>YEtxijEkfPk73j5jPoJh6SNWtzrdLUC6DH4mmghqgmZcn4glkhWpqIU6U/tj4hJT
>>iN67F5g0g8YSIQNTBsTO/TLrQmrHdb/iT2v9hTxeL+Ly+xjHKJmSikP+f0rOOrQn
>>vXbJHGk2IAgajDHcdG3jDJvoQDgA0vl+uJ/i4tj++rwMNNXxX7MmFq9qGqGGjBp4
>>nwFVJn9QGMHq2boDXISXlz+zNcjLWcaxNrXQiqSB5sqnbvjg27/NCDaQG8+ZgWzX
>>a/JGLqu3l7LoribH54E51PGdpKiiooDgYjgQkB9ZrSM6/X14JftqWavEALrLQXfM
>>ud32XTgMGiBVqyjtGQ4VDS2KtQnZAWhORMQJvOx3nwApUiXOlyX8xoyazYetnTaC
>>pZFgYRgmNYQodweJNrpz28EekEhwr1A/HHYhe5ANqUSO44xZBhsfEhtz0ycVd0ok
>>2JnCC4WwmQtqifD4S3hEsn4BN1XvxCH8YhXV6S+ApD9bo22ybZFw7f54tMSV0L/d
>>brkafk2u3Bhnh2yFr+6k
>>=pX91
>>-----END PGP SIGNATURE-----
>
>I don't think it is possible to un-eject a usb-drive without
>powercycling it.
>
>And why wait 5 minutes to eject it? Simply do that as soon as the keys
>are read?
>
>Extra option:
>Stick the usbdisk driver as a module in a ramdisk and then rmmod it.
>Remove the module from disk
>And use module signing. From what I understand. The keys for that are
>generated at compile time? And you can delete them from the kernel
>sources after compiling.
>
>--
>Joost
>-- 
>Sent from my Android phone with K-9 Mail. Please excuse my brevity.

One more idea:
Boot from the same usbdisk.
This moves the kernel and ramdisk away from the disk and into a location where, after rmmodding the drivers, the system no longer knows how to read from even if someone did figure out how to uneject a usbdisk. 

--
Joost
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] [OT] Time-lock USB stick

[Helmut Jarausch]

On 03/20/2013 03:58:11 AM, Michael Mol wrote:
> Does anybody know of time lock flash drives?
> 
> The scenario I'm looking at is to have a drive that's only accessible
> for a certain amount of time after being powered on. It would hold
> crypto keys in a server context.
> 

You might use encfs. It has an option (-i idle[minutes]) which makes an  
encrypted
directory unaccessible after some minutes of idling unless one  
re-enters the key.

Helmut.

Re: [gentoo-user] [OT] Time-lock USB stick

[Michael Hampicke]

Am 20.03.2013 03:58, schrieb Michael Mol:
> Does anybody know of time lock flash drives?
> 
> The scenario I'm looking at is to have a drive that's only accessible
> for a certain amount of time after being powered on. It would hold
> crypto keys in a server context.
> 

I am no expert on embedded systems, but couldn't you achieve something
like this by using a small dev board with like an Atmel controller?
Which you then program to act like an USB stick?

Re: [gentoo-user] [OT] Time-lock USB stick

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 889 bytes --]

On 03/20/2013 04:47 AM, Michael Hampicke wrote:
> Am 20.03.2013 03:58, schrieb Michael Mol:
>> Does anybody know of time lock flash drives?
>>
>> The scenario I'm looking at is to have a drive that's only accessible
>> for a certain amount of time after being powered on. It would hold
>> crypto keys in a server context.
>>
> 
> I am no expert on embedded systems, but couldn't you achieve something
> like this by using a small dev board with like an Atmel controller?
> Which you then program to act like an USB stick?
> 

We discussed using a simple RC timer to cut power to the device after a
certain amount of uptime, but if I pointed out that if we were spend the
time going to that trouble, we may as well go whole-hog and add built-in
encryption and make money off the thing.

I think the grab-data-and-eject solution is probably the best for our
purposes.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-user] [OT] Time-lock USB stick

[Kevin Chadwick]

> We discussed using a simple RC timer to cut power to the device after a
> certain amount of uptime, but if I pointed out that if we were spend the
> time going to that trouble, we may as well go whole-hog and add built-in
> encryption and make money off the thing.
> 
> I think the grab-data-and-eject solution is probably the best for our
> purposes.

What about wiping the key.

I would investigate if a hdparm reset negates that security.

A long shot that all systems especially likely small ones will have
floppies (though there may be a usb one) but using a floppy eject would
certainly be one way (ignoring any buffers) as it is 100% mechanical
on the enable direction.

However why not just use a usb with perms set to root. If an attacker
can get root which should be the biggest barrier and you are not worried
about physical access then even SELINUX/RBAC may not save you.


-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________