[SGVLUG] Does anyone make...

[Tom Emerson]

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

John E. Kreznar wrote:
> "Emerson, Tom (*IC)" <Tom.Emerson at wbconsultant.com> writes:
> 
>> A bluetooth-based flash memory? ...
> 
>> Here's my idea: you would use it to store sensitive/personal
>> information, [...] my idea of a bluetooth-flash memory
>> would allow you to keep it in your pocket separate from the
>> computer, and yet have /easy/ access to it when you need it.
> 
> This way, the thief doesn't even have to take the physical computer.
> He can read the key wirelessly while sitting beside you seemingly
> minding his own business.

only if he can "pair" with the device, which if designed properly would
not allow "pairing" without some physical intervention (i.e, pushing a
button on the device itself)  Though it might limit functionality a bit,
it might also be designed to pair with one and only one other computer
- -- to change the pairing relationship, you would have to remove the
existing pairing ["reset" the device] and go through the
discovery/pairing process again -- if this "process" requires multiple
button pressings on the device, so much the better.

For the truly paranoid, you could set up a form of handshake by
double-encrypting it -- a second key pair where the secret to decrypting
the secret key is on the target computer, so the ONLY way to get your
actual "secret" key would be to have the combination of your laptop AND
this remote device AND know the passphrase for both keys.  (but therein
lies madness... ;) )

[slightly less paranoid, and perhaps infinitely more practical, would be
to use SSH as the actual file-transfer protocol instead of the
"standard" OBEX "pull/push" mechanism]

>> ... -- by encrypting a file/folder/drive-partition with your
>> "public" key, you would need your "secret" key to access it, which
>> of course is in your pocket.  The "thief" would have to remain
>> within 15' of you to access the contents of the file...
> 
> The thief got the key wirelessly.  He can read the encrypted files at
> his leisure.  You've made it easy for him to do a black bag job.

OK, I'm doing some reading on BT security -- some more points to
consider for a "properly designed device" for this particular purpose:

   1) keep the "discovery period" short -- my phone, for instance, can
only be made "discoverable" for a minute at a time -- once my PC has
"captured" it's address, it keeps that address on file and the phone
doesn't have to be "discoverable" anymore (likewise the phone remembers
the PC's address so it can recognize it as a legitimate source)

   2) better still, don't allow the device to be "discoverable" at all
- -- since you would (presumably) have access to the PC that will be
making the connection, it would be fairly trivial to write the comm
program such that you would have to manually enter the address.  Per the
page I'm reading [http://www.securityfocus.com/infocus/1830] it would
take 1165 days to "brute force" the device's address (though he talks
about ways to reduce this, and does manage to get it down to about 4-1/2
days, but that is with a LOT of caveats)

   3) as I noted above, force the use of "pairing" or "level 3
security(*)" -- the article (and second page) talks primarily about
weaknesses in phones, but these are weaknesses "as implemented" by firms
that aren't interested in security vs. "getting a product out the door"
[and/or "that is easy for users to use"]  Theoretically, a BT device
/could/ accept and act upon an unauthorized "OBEX" transfer [think
"anonymous ftp"] but it doesn't /HAVE/ to accept such a transfer.  IN
practice, "many" [per the author] phones and PDA's DO allow unauthorized
transfers, but that is/was "to make it easier for users".

   4) [late thought, this seems to be the best place to put it] in
addition to not making the device "discoverable" at all, don't even
allow "pairing" to occur "wirelessly" either!  Given the nature of this
device, we could allow for a USB connection as well -- in order to
"pair" the device, you would have to physically plug it into the
computer and write the pairing data via a USB connection.  This would
make it physically impossible for a nearby "hacker" to intercept the
initial pairing code as it never goes out into the "ether"

========================
(*) the three levels of security, from
http://www.bluetooth.com/Bluetooth/Learn/Security/, are:

   1) no security [any device that can connect can transfer data]
   2) service level security
   3) link level enforce security
========================

Since we're defining this device as a "secure" repository of data, it
would make sense to design it such that security takes precedence over
"ease of use" [but within reason -- requiring the user to enter a 27
digit "pin" on the device every time they request the "key" would make
using it worse than the problems it solves -- I could see, however,
requiring the user to press a /single/ "confirmation" button on the
device to retrieve the "key" or any other file from the device, but this
actually creates a potential "weakness" -- it would allow a bystander to
"know" that you have and are employing such a device -- remember, if
it's in your pocket or purse and the process of retrieving the data is
automatic (but only between paired-and-authorized devices), nobody would
even know you had such a device

[note: in the first article above, the author mentions that a BT hacker
would be able to determine "visually" who had "active" devices by
looking for a glowing blue LED -- obviously, this is not needed for
actual operation and is only there for "peace of mind" that the device
is "working"...]

OK, I'm over-building this now :)

- --
Top o' the Blog: so, I like puppies...
http://osnut.homelinux.net/mtblog/ya_index.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGXpvmV/YHUqq2SwsRAhWpAKDCGoIlY/A4zA3JY6KIJ8R4zfl9jQCgrQ0S
kRdcXXsUd22U50f2cNKMt5g=
=n0bY
-----END PGP SIGNATURE-----