Re: [PLUG] USB-attached, hardware-encrypted card reader ... why vaporware?

[brent timothy saner <brent.saner@gmail.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I think you may have sent this to Keith and me directly by accident, as
this didn't seem to get to the list.


On 06/27/2015 05:42 PM, bergman@merctech.com wrote:
> In the message dated: Sat, 27 Jun 2015 16:49:15 -0400,
> The pithy ruminations from "Keith C. Perry" on 
> <Re: [PLUG] USB-attached, hardware-encrypted card reader ... why vaporware?> we
> re:
> 
> While the stuff you each wrote about encrypted USB flash drives and
> software encryption (subjects about which I'm quite familiar) may be
> accurate, aside from the statements:
> 
> 	"personally, i don't trust hardware encryption- it doesn't allow
> 	for tweaking or transparency, and due to the limited hardware
> 	onboard they tend to be fairly limited."
> 
> and 
> 	"I don't trust small hardware to be be durable"
> 
> I don't see anything on-topic in your responses to my query about
> hardware devices to portably encrypt generic SD cards.

Which is why I offered a cross-platform software suggestion, which you
can use to create an encrypted loopback filesystem volume on top of the
SD's base filesystem. Which would be GUARANTEED portable, and have the
benefit of being able to use stronger encryption/new algorithms as time
goes on. What did you think I meant by suggesting it?

> I've got a use case that I think is fairly common 

Let me stop you right there- it isn't really, which is why the specific
solution you're looking for doesn't exist. Unless someone is a
photographer (in which case I'd doubt they'd use encrypted SD media, as
their camera would probably choke on trying to use it) or you're running
a massive sneakernet caravan (I am, of course, being facetious), most
people use maybe one or two SD cards at MOST (aside from their "smart"
mobile device's storage, which they never think about, and Android/iOS
encrypts for you if you so desire it to).

USB killed CF, and ever since all the attempts to bring back
flash-based/cell-based storage in a non-USB form factor have failed with
the exception of niche markets/specialized implementations.

What you're probably instead going to find better luck with is with USB
"flash" storage (which isn't actually flash so much as cheap cell-driven
storage, but whatever). And there are plenty of options for those with
hardware security, but again- it's not ideal. On-device hardware
encryption is weak. Period. It affords no future-proofing, no protection
from zero-day discovered vulnerability, no ability to use newer
algorithms as time progresses. Waste of money, in my opinion.

Additionally, there is no guarantee these hardware solutions will work
with GNU/Linux. I suggested CipherShed because it is more portable-
despite software upgrades (since when does upgrading encryption software
break access to volumes encrypted with earlier versions? This does not
happen in the F/OSS software-level encryption world- if it does, it's a
bug, and shouldn't make it to stable. If this has ever happened, I'd be
surprised if it wasn't reverted/resolved within the next minor release.
Unless you're running Gentoo or Arch, you'd have no reason to worry),
and all the other things you mentioned.

> -- the ownership and
> use of a number of SD cards, particularly during travel. While
> convenient, these are easy to loose, or may be in a bag that's stolen.

See, and I think we disagree entirely on the "convenience" aspect of it.
And yes, they're FAR too easy to lose.

> Hardware encryption of generic flash cards offers security,
> expandability, value, and device independence that none of the
> solutions you suggested can provide, which is why I turned to this list
> to find out if I had overlooked a relevant solution.

Really? LUKS/cryptsetup and CipherShed both have not security,
expandability, value, *or* device independence?

Surely, the claim that SD card storage is more reliable, accessible, has
more value, device independence and a wiser choice than ALL other media
isn't just a *wee* bit unrealistic? Considering that software encryption
allows you to choose how strong you want your encryption, can be applied
to ANY media across (in e.g. CipherShed's example) MULTIPLE platforms,
hell- even across a RAID if you want, and is much more device-agnostic
than a specific form factor can even inherently be, I find that claim a
bit unbelievable. As for "Value", that's largely a pretty subjective
thing and depends entirely on context.

> Frankly, I disagree with your contentions about 'small hardware' not being
> durable or trustworthy -- particularly when that hardware has things like
> FIPS certification, epoxy-potted components, etc. In my personal
> experience, and considering the boxes of failed storage devices at $WORK
> that are awaiting destruction, mechanical hardware (disk drives & fans)
> and their power supplies have a far greater failure rate than flash
> drives. In several years worth of experience with hardware-encrypted
> USB drives & flash drives, we've had zero failures, while I've seen
> problems with LUKS (and other software solutions). Yes, a software-based
> solution offers more of an opportunity to recover after a problem, but
> at the risk of being more fragile and requiring more
> 'maintenance' (think OS upgrades on encrypted devices, driver updates,
> migration from untrusted software [ie., Truecrypt] to other products)
> in the first place.

Hardware dies, whether you've anecdotally experienced it or not. At
least with bitrot you're able to combat it and prevent it.

However, when I say "reliable", I mean in a sense of cross-platform
interaction (hell, *cross host* compatibility, not even necessarily
cross-platform). I mean durable in the sense of security, and
"future-proofing" your storage.

There is also the case of hardware interfaces- how long until SD bays
are deemed obsolete? What value do your SD devices have then, especially
with their added cost of hardware-level encryption (assuming it were to
exist)?

A soft-encrypted volume you can move over to a new device, or run
redundancy against, store in backups, etc- heck, run it as a RW loopback
filesystem image file stored ON an SD for all I care, because at least
then you aren't relying on a hardware mechanism for encryption.

I'd like to hear more about the LUKS failure you said you experienced,
however. I'm not aware of that happening, and I have a sneaking
suspicion it's not actually related to LUKS. Do pardon me for being a
natural skeptic.

> For many people and situations, a low-maintenance applicance (ie.,
> hardware encryption) requires less effort to configure and use.

The number of people interested in actually using encrypted storage is,
I wager to guess, roughly equal to the people who know how to do so on a
software level. Maybe not the cryptsetup commandline, but they sure as
hell can use the various DE's GUI disk utilities to do so. Or CipherShed
if cross-platform compatibility is needed. Which, yes, has a GUI.

If it's so easy to set up that it requires no additional effort from the
user to secure, then chances are likely that it isn't.

> Thanks anyway,
> 
> Mark

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJVjyfPAAoJEIwATC+TSB9rVqwQALHhiLRV6s7xYyRi8eG969/D
Nf9SNVhoJGgTQ5i3WXmD2z0B/nhLN1bWPcVNJ7Nmiu0500C86HlMXYUFoKedgItA
AKoL7lZlaqLflpSUVr6U7J+ZVLF+VfNuN9VQKwe/pZFE5/HFQxyjAmtUnlZSIyKa
lDL9v+PnFfihjg7xIOMbMBEI7dr+QJAcaTXbz7Zmo9uScnJHLzbzPg/mla069feg
mPt9iKp9HhXz3gwmTB1VPyqx5g7kl50SOJSBv9/26+0nqT9F75J5z6K8uR3uSqUW
lq+w3L3/7Q+/5/UMI2poHXekBhmcGSBu68FdYDe3Zzi5ZljyO8jXmAfnxEErgZ6a
zJl4iCJiQscujZCgpaWojJlOjtih4gaJqvi1Ub4H96NT0KErrl3OHIBHnnBhjRbo
nUB3feDTgcBessfIVG1SGqW61r0H9Tb/VeW0TM6aWpcz97o64wuemRcoAmzLgBo+
YgYHlCPxNDKHOjpJTlGEQIQE5jZ40SuvBAJbxTzODGPC41xHD2pHiJsz2EJBUuwb
ie7SzdDbWbAHQ4Gg2hSEAYDB+Z1DxHF6X/OhCRjTNy6EG1B7DEH07qCN9FNLCUn7
86+k/PnvkzFxzEM1hkUph8+jkcHjWQzzxyDeTdOxKzSrYQJm2/xDzOytOumL5ccH
9JiQdwiY29Krd/KN6G2O
=Ndjr
-----END PGP SIGNATURE-----
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug