[HN Gopher] I'm building a self-destructing USB drive (2022)
       ___________________________________________________________________
        
       I'm building a self-destructing USB drive (2022)
        
       Author : thunderbong
       Score  : 90 points
       Date   : 2023-12-06 09:33 UTC (3 days ago)
        
 (HTM) web link (interruptlabs.ca)
 (TXT) w3m dump (interruptlabs.ca)
        
       | dang wrote:
       | The submitted URL was https://github.com/o7-machinehum/ovrdrive,
       | but it looks like the blog posts have more information, so we
       | changed to the first of those.
       | 
       | Part 2 is https://interruptlabs.ca/2022/08/31/I-m-Building-a-
       | Self-Dest... and was discussed a year ago here:
       | 
       |  _I 'm Building a Self-Destructing USB Drive Part 2_ -
       | https://news.ycombinator.com/item?id=32900787 - Sept 2022 (51
       | comments)
        
       | RcouF1uZ4gsC wrote:
       | > A finger is around 1.5MO, but wet fingers are around 500kO.
       | When the device boots, the drive will appear blank if the
       | resistance between the electrode pair is higher than a threshold.
       | It's not the prettiest system, but I think it strikes a nice
       | balance of ridiculousness and functionality. The germaphobes
       | among us can run their fingers under the tap.
       | 
       | This may backfire for the hacker.
       | 
       | Authority: Give me the drive
       | 
       | Hacker: Ok. (hands drive)
       | 
       | Authority takes with dry hands and tries it. It doesn't work.
       | 
       | Authority gets upset and starts beating the person.
       | 
       | Authority works up a sweat during the beating
       | 
       | Authority tries drive again - it works
       | 
       | Authority concludes that Hacker's drive only works if Hacker is
       | beaten.
        
         | jvm___ wrote:
         | https://xkcd.com/538/
        
           | 0xdeadbeefbabe wrote:
           | $5 for a wrench really dates that joke
        
             | binarymax wrote:
             | https://www.harborfreight.com/hand-
             | tools/wrenches/adjustable...
             | 
             | Granted it's only 6" long, but hey it's a $5 wrench.
        
               | RcouF1uZ4gsC wrote:
               | You know what they say about "it's not the size of the
               | tool, it's the skill of the interrogator."
        
               | philomath_mn wrote:
               | Everyone knows that the Snap-on wrench delivers a better
               | beat-down.
        
               | jvm___ wrote:
               | https://shopgoodwill.com/item/185825793
               | 
               | This would do. $.99 over budget though
        
             | ace2358 wrote:
             | Even the alt text on that comic agrees that $5 for a wrench
             | is possible impossibly low
        
       | datadrivenangel wrote:
       | Would be better to have a false volume that contains boring but
       | realistic files without the correct password or trick to unlock.
        
         | oigursh wrote:
         | https://en.wikipedia.org/wiki/Rubberhose_(file_system)
        
           | mike_hock wrote:
           | Unfortunately, it doesn't protect against Rubberhose
           | cryptanalysis.
        
             | simbolit wrote:
             | I think that is a wrong take.
             | 
             | Rubberhose FS does protect you from rubberhose
             | cryptanalysis. That is the point.
             | 
             | You can argue, that it over-protects you, which might be
             | just as or even more dangerous, and that is a fair
             | criticism.
             | 
             | But I don't see how you can argue that it "doesn't protect"
             | you.
        
               | mike_hock wrote:
               | It doesn't protect you from rubberhose cryptanalysis
               | being performed on you. It might protect the data if you
               | can resist revealing the ultimate secret until death.
        
               | simbolit wrote:
               | I now see how you can argue that it doesn't protect you,
               | in a very personal meaning of you.
               | 
               | Then, is there anything that can protect __you__ from
               | rubber hose cryptanalysis in this sense?
               | 
               | If not, what does my parent comment even mean?
        
               | mike_hock wrote:
               | Well, rubberhose cryptanalysis isn't cryptanalysis. Once
               | you start discussing it, you're not discussing
               | cryptography anymore. There's no cryptosystem that can
               | protect you from it.
        
               | toast0 wrote:
               | If you want your life protected from the rubber hose, you
               | need to be able to allow access to the data. But, that
               | doesn't necessarily protect your life: if they don't like
               | the data they see, then they'll keep trying to extract
               | more keys.
               | 
               | If you want your data to be safe from the rubber hose,
               | you need to have inconvenient access requirements. If
               | your laptop can only be unlocked when 5 keys are turned
               | 'simultaneously', and the keys are held by the
               | ambassadors to the UN with security council vetos, that's
               | going to be hard to accomplish for you, and likely
               | difficult for any one else. Any one of the ambassadors
               | could plausibly lose their key, and then the data is
               | gone, etc.
        
         | waynesonfire wrote:
         | Veracrypt supports this, called hidden volume.
        
         | rblatz wrote:
         | I was thinking along the lines of setting the highest bit on
         | the address line to either 1 or 0 based on the resistance, and
         | programming the device to report half the capacity of the nand
         | chip.
        
       | neilv wrote:
       | What if a banana republic journalist suddenly trying to stop the
       | rogue official from deploying a suitcase nuke... has sweaty hands
       | from the stress, while racing to access the USB flash drive with
       | the documents that would locate the nuke in time?
        
         | HideousKojima wrote:
         | I dunno man, but I can think of at least two whole scenarios
         | more likely than your hypothetical
        
       | neilv wrote:
       | I don't need self-destructing USB drive, but a USB flash stick
       | with a _hard write-protect switch_ (that can 't be overridden by
       | the USB host) would be great for purposes like immutable
       | installation and boot media.
       | 
       | (Also, like any USB device should, but even more here, you have
       | to ensure that the device controller can't be modified by the USB
       | host.)
        
         | oconnore wrote:
         | That would be very useful. We sadly stopped innovating on
         | optical media, but haven't really made the alternatives usable
         | as a replacement. You used to have CDs / DVDs that were:
         | 
         | 1. Completely immutable
         | 
         | 2. Could not be maliciously altered by the reader
         | 
         | 3. Could not masquerade as a keyboard or a mouse
        
           | ace2358 wrote:
           | I miss physical media, optical or magnetic. Or something
           | new!! Flash drivers are just computers these days.
        
             | simbolit wrote:
             | In what sense is a nand chip, a memory controller, and a
             | usb plug, a "computer these days"?
        
               | toast0 wrote:
               | The flash memory controller is most likely a embedded
               | stored program computer. Likely an arm, maybe dual core.
               | 
               | A modern computer is really a distributed system, but not
               | a lot of people frame the discussion that way.
        
               | yencabulator wrote:
               | https://www.bunniestudios.com/blog/?page_id=3592
               | 
               | > The embedded microcontroller is typically a heavily
               | modified 8051 or ARM CPU. In modern implementations, the
               | microcontroller will approach 100 MHz performance levels,
               | and also have several hardware accelerators on-die.
        
           | Syonyk wrote:
           | You still do. I can't be the only person who burns install
           | DVDs, finalized, verifies the hash on a few different
           | systems, and then keeps them in a safe place for possible
           | future use...
           | 
           | I've got some external USB readers/burners that excel for
           | exactly this sort of thing, and just about anything that will
           | run a modern OS will boot from them.
        
             | JohnFen wrote:
             | You're not the only one. I still do this, and use CDs/DVDs
             | for all sorts of other longer-term storage as well. I'm
             | unaware of any other media that works well for those sorts
             | of use cases.
        
               | superb_dev wrote:
               | What is the shelf life of a modern CD/DVD? I might
               | consider using them more
        
               | JohnFen wrote:
               | At room temperature, about 25 years -- but there are a
               | lot of variables that can affect this in both directions.
               | 
               | https://www.clir.org/pubs/reports/pub121/sec4/
        
               | dml2135 wrote:
               | Maybe for commercial-grade optical media, but last time I
               | burned a lot of consumer media , I found a decent amount
               | of failures even just a few years out.
               | 
               | Admittedly this was almost 20 years ago at this point so
               | maybe some things have improved since then but my
               | understanding is that consumer media uses a different,
               | ink-based technology to write data to disk, and that ink
               | can degrade pretty quickly. This is in contrast to
               | commercial optical media in which the data is stamped
               | into the disk in a manner more akin to a vinyl record.
        
               | JohnFen wrote:
               | All CD-Rs use a dye layer, yes. The life expectancy the
               | link I provided is talking about is for writeable media,
               | not for read-only media that is stamped.
               | 
               | Some forms of writeable disc media don't use dyes and can
               | last for over 100 years. Check out the link.
               | 
               | But, to your point, one of the variables that affect
               | longevity is the quality of the manufacturing. If you're
               | buying the least expensive media you can find, then the
               | lifespan is indeed shorter. For my cheapo CD-Rs, I've
               | found that they last 5-10 years. You can also make them
               | last longer by storing them in better conditions
               | (vertically, not laying flat, in an airtight container in
               | the freezer).
               | 
               | I tend to go with cheap media, so my personal habit is to
               | burn new copies of my storage discs every 5 years.
        
               | jstarfish wrote:
               | Yeah they sell archival-grade CD-Rs. CD-RWs are way more
               | unstable; would not recommend.
               | 
               | One variable I'm recently able to validate (wow, 20 years
               | later!) is write speed. Discs written (for archival) at
               | slower speeds still work. Discs I wrote as fast as
               | possible on my way out the door have mostly failed by
               | now.
        
               | dml2135 wrote:
               | Ah interesting, I will check it out. Yea I was definitely
               | buying relatively-cheap media back in the day -- I
               | remember getting large spindles of Verbatim DVD-Rs for
               | about $1/disc.
        
               | kevin_thibedeau wrote:
               | BD-R and Mdisc DVD-R are not dye based.
        
               | waynesonfire wrote:
               | They make archival grade dvds, I just got some,
               | 
               | Verbatim DVD-R UltraLife Gold Archival Grade 95355
        
             | oconnore wrote:
             | I still use BluRays, but the cost/GB has not kept up with
             | everything else.
        
               | waynesonfire wrote:
               | Really? What alternative is there for archival quality
               | backups with better $/gb?
        
               | NavinF wrote:
               | https://diskprices.com/
               | 
               | Of course you need Reed Solomon across drives (Eg raidz)
               | regardless of media
        
               | userbinator wrote:
               | Tape.
        
               | rowanG077 wrote:
               | Only the amortized cost is better for tape if you can
               | fill up lots of tapes. Amazing if you are a data center.
               | But if you don't archive a huge amount of data it's not
               | even close to competitive.
        
           | mike_hock wrote:
           | > Completely immutable
           | 
           | Wouldn't the laser of a CD/DVD writer be powerful enough to
           | alter the data after the fact? Not to overwrite it with
           | completely arbitrary data, but flipping a few well-chosen
           | bits should in principle be able to create a backdoor that
           | wasn't there before (if it's a live or install disk, for
           | example).
        
             | JohnFen wrote:
             | You can change things, yes, but not in a way that keeps the
             | disc usable.
             | 
             | The issue here is that you can't "unburn" a bit that has
             | been burned. Since you burn 0s, not 1s, all you can do is
             | make more bits 0 -- which would then be corrected by the
             | error correction mechanism. You could alter the EC codes,
             | but that would render them useless and eliminate the
             | ability to correct errors, causing the data to be
             | unreadable by a normal drive due to EC failure.
             | 
             | So, in practice, they're pretty safe. The worst thing that
             | an attacker could do is to render the media unusable.
        
               | calamari4065 wrote:
               | That's not _completely_ true either. I used to use some
               | sketchy utility back in the day that could mark one
               | recording session as inaccessible and let you add data to
               | any remaining space on the disc. You would only see the
               | new session. Hypothetically you can also manipulate the
               | file table to make it look exactly like the real thing.
               | 
               | I don't remember if it required the disc to be un-
               | finalized or not. It probably did.
               | 
               | But this is really an edge case
        
               | JohnFen wrote:
               | True, I was assuming the disc wasn't written as a multi-
               | session one (most people never use multi-session). Multi-
               | session discs are a bit different. But, afaik, if the
               | disc has been finalized then the result is as "immutable"
               | as a non-multisession one. I'm not completely certain
               | about that, though.
        
               | mike_hock wrote:
               | Are the EC codes such that any alteration from 1 to 0 in
               | the message results in at least one flip from 0 to 1 in
               | the (correct) EC code?
               | 
               | If not, then you "just" have to find the right spots
               | where such a simultaneous alteration of the payload and
               | the EC code is possible, and which also happens to result
               | in a desirable behavior change.
        
               | adhesive_wombat wrote:
               | No, the Reed Solomon codes used in the CD have one EC
               | byte for every 3 data bytes. But there's a interleaving
               | system where the data is encoded with error correction
               | (adding 4 bytes to every 24) interleaved so that burst
               | errors (that affect nearby disk surface) are distributed
               | in the data stream, then encoded again (adding 4 bytes to
               | 24 + 4 to give 32, with 8 EC bytes).
               | 
               | So you'd have to find mutations that are big enough to
               | not be automatically corrected (more than 2 bits, you
               | can't change, say a single 0x30 to 0x31), and _also_
               | happen have the right signature so they don 't flag as
               | erasures, so you can't freely change bytes to just
               | anything. And _then_ you have to also satisfy the outer
               | code that your modified byte after interleaving is
               | correct. And do it all by only bring able to bit-flip in
               | one direction. The only upside is that you can also flip
               | bits in the correction bytes if you need.
               | 
               | Also, if the data you're modifying has any coding or
               | compression (ZIP, Word documents, videos, most images),
               | or there are checksums, you have to not upset _that_. And
               | if it 's encrypted, you won't know what to change in the
               | first place.
               | 
               | So it's theoretically possible, but it would be very
               | tricky and highly unlikely that you could change a useful
               | piece of data unless you were extremely lucky with what
               | the data was, what you wanted it to be, and where it was
               | on the disk.
               | 
               | If you're concerned about people modifying your CD-R:
               | encrypt and SHA-256 the whole thing and you'll be fine. I
               | assume this threat model mostly targets governments, so
               | they should first do both of those things and maybe also
               | stop leaving them on trains.
        
         | 1970-01-01 wrote:
         | Have it, love it: https://www.kanguru.com/products/kanguru-
         | flashblu30-usb3-fla...
        
           | neilv wrote:
           | Cool. Any idea how well-secured that one is, for use with USB
           | hosts that potentially have adversary tech active on them?
           | 
           | (Threats to modify data on the drive or the code of its
           | controller; not concerned with threats that fry the device
           | with power.)
        
             | 1970-01-01 wrote:
             | It will work just fine for this. You can superglue the
             | switch if you need to keep it read only.
        
               | Luc wrote:
               | But is the switch just an input that is read by the
               | software on the device, or does it actually interrupt
               | e.g. a data line, making it impossible for even hacked
               | software on the USB device to write to memory?
               | 
               | I can't really find a conclusive answer.
        
               | 1970-01-01 wrote:
               | It physically switches some circuit to disable the
               | ability for data to be written onto the device. Why not
               | contact them and get the details?
        
               | Luc wrote:
               | I was just attempting to restate neilv's question in a
               | different way. If you don't know that's fine.
        
               | neilv wrote:
               | Thanks, I should've been more clear.
               | 
               | Maybe someone can put in an epic weekend, to determine
               | technical and market and logistics feasibility for a
               | trustworthy USB flash drive product, in time to apply for
               | the YC W24 extended deadline. From there, maybe
               | Kickstarter to enthusiasts to fund the Mk. I
               | manufacturing run. With Mk. I for experience and
               | credibility, do enterprise marketing&sales, and/or SBIR
               | to develop solution for possible sale to Federal gov't
               | and contractors. :)
        
               | 1970-01-01 wrote:
               | Add AI and blockchain, so I know I can safely invest
               | millions into it.
        
               | neilv wrote:
               | "It's Uber _for bytes_. "
        
               | transpute wrote:
               | _> making it impossible for even hacked software on the
               | USB device to write to memory?_
               | 
               | Signed firmware to prevent BadUSB-style attacks, price
               | starts at $40 for 16GB,
               | https://www.kanguru.com/products/kanguru-flashtrust-
               | secure-f...
               | 
               | They have other models with signed firmware + FIPS 140
               | certified encryption + tamper resistance + physical
               | write-protect switch.
               | 
               | They also sell an SSD enclosure with write-protect
               | switch.
        
               | yencabulator wrote:
               | Signing firmware might help prevent replacing the
               | firmware, but it doesn't do anything to protect against
               | exploiting a security vulnerability in the current
               | firmware.
               | 
               | The marketing is a little too breathless to assure me
               | that they did _anything_ to actually make the firmware
               | trustworthy:  "Digitally Signed, Trusted Secure Firmware
               | (RSA-2048 Bit)".
               | 
               | Signing something doesn't make it secure against
               | exploits.
        
               | helsinkiandrew wrote:
               | Most USB media control chips have hardware write protect
               | pins that will physically prevent writing to memory, for
               | example:
               | 
               | https://eu.mouser.com/datasheet/2/268/MCHP_S_A0001038949_
               | 1-2...
               | 
               | Obviously if someone has physical access they could take
               | the unit apart and circumvent this (but then they could
               | flip the switch too)
        
               | yencabulator wrote:
               | Which, as far as I know, is only an input read by the
               | firmware. If there's an exploitable bug in the firmware,
               | that signal means nothing.
               | 
               | Here's some exploits against flash controllers:
               | https://www.bunniestudios.com/blog/?page_id=3592
        
               | light_cone wrote:
               | I have some of these usb keys, and I remember having
               | remounted the device rw on linux, and the device failed
               | with an io error when I attempted to write. So if I'm
               | correct, the driver was configured as if the key was rw,
               | but it failed because the hardware switch was ro.
               | 
               | So I believe that it is an actual hardware lock, in
               | addition to the os having the ro/rw status info.
               | 
               | If someone is interested, Kanguru have faster models than
               | the one linked (which I have too), which is a little slow
               | by today's standard.
        
         | sowbug wrote:
         | Not exactly what you describe, but for the installation and
         | boot use cases you're describing, have you tried Ventoy? It's
         | still all software, but it's an extra layer of protection
         | against the disk images being modified.
        
           | mike_hock wrote:
           | It's exactly zero protection against anything being modified,
           | including the chainloader itself.
        
         | wolpoli wrote:
         | SD Cards do have a write protect switch. Does anyone know if
         | that's enforced on the card itself?
        
           | anonymousiam wrote:
           | It's not enforced by the card. It's just a plastic tab that
           | slides so as to tell the reader that the card should not be
           | written. There is nothing to stop a malicious reader from
           | writing to a write-protected card.
        
             | IAmLiterallyAB wrote:
             | Wow really? That's annoying. Why go to all the trouble to
             | add the switch if they won't implement it correctly
        
               | AussieWog93 wrote:
               | Because engineering consumer media to be robust to a
               | Stuxnet-level attack vector is ridiculous?
               | 
               | The switch as-is prevents the file system from becoming
               | corrupt when you don't "safely remove" the device, and
               | that's plenty enough for the average photographer.
        
               | JohnFen wrote:
               | I think the purpose of the switch is the same as the
               | write-protect notches on old floppy disks: it's not
               | really a security measure, it's meant to prevent the
               | owner from accidentally formatting/erasing/overwriting
               | things.
        
               | userbinator wrote:
               | Or to go even further, the write-protect tabs on cassette
               | tapes.
        
             | calamari4065 wrote:
             | No, it is electrically connected, but only to the
             | connector. That's why one of the edge contacts is split in
             | two. It's still up to the host to enforce.
        
         | kevin_thibedeau wrote:
         | Use an SD card adapter.
        
         | RalfWausE wrote:
         | "Why not simply" use an USB DVD / Blueray drive? I mean... more
         | security / write protection is not possible as far as i know...
        
         | ravenstine wrote:
         | I would even want that for a non-stick full size USB drive like
         | one of those Sandisk 2 TB drives. I know that an FS can be made
         | read-only, but it would be great if it were possible to protect
         | from writes at the hardware level without making it too easy
         | for someone (could be a family member or whomever) to turn off
         | the protection.
        
         | sonicanatidae wrote:
         | I have 2 of them. An ancient 2 GB Sandisk and more recent and
         | available Kanguru SS3 with Write Protect.
         | 
         | Great little tool.
        
       | toss1 wrote:
       | Clever , but seems insufficient protection on which to bet one's
       | life.
       | 
       | At a minimum, there should be an always-available partition to
       | contain plausibly-deniable files. Just having an empty USB drive
       | is already suspicious, especially in any stressful situation (why
       | would anyone go to the trouble of carrying something empty?)
       | 
       | The decoy partition should report full capacity even tho it may
       | be small (just like the bogus "large" Chinese knock-off drives
       | that report huge available space but are actually only small
       | memory chips that will fail only when you actually try to load it
       | fully).
       | 
       | Should probably also ship them with a wide variety of bogus off-
       | brand labels. If some authorities figure it out, we don't want
       | bulletins to look for one particular marking set to work.
        
         | denton-scratch wrote:
         | > why would anyone go to the trouble of carrying something
         | empty?
         | 
         | 1. It's new.
         | 
         | 2. You're going to load data onto it at your destination.
         | 
         | 3. You carry it _in case_ you need to copy data.
         | 
         | I often carry an empty messenger-bag; a USB drive is a lot less
         | trouble to carry. In fact you can easily lose one in the corner
         | of a pocket, and carry it inadvertently.
         | 
         |  _Provided it had never been written_ , I would regard an empty
         | USB drive as unremarkable, and not grounds for suspicion. But
         | you can't buy a new USB drive with a hidden partition.
        
       | anonymousiam wrote:
       | Using skin resistance is not a fool-proof method. The resistance
       | of wet fingers can vary widely from person to person. Mine has
       | always been lower than most others that I've measured, and my dry
       | measurement is well below the 500KO threshold described.
        
       | Kwpolska wrote:
       | How is "files not visible unless you lick your fingers" a "self-
       | destructing USB drive"?
        
         | p1mrx wrote:
         | The magic smoke is in Part 3. Click "Next Post" twice.
        
           | Kwpolska wrote:
           | Part 1 doesn't even mention the destruction, that's a bad way
           | to write a series of blog posts.
        
       | junto wrote:
       | Relevant XKCD: https://xkcd.com/538/
        
       | lnxg33k1 wrote:
       | Its nice to create a usb drive that protects people in danger and
       | then publishing on the web how to undo all its benefits, i'd
       | argue that having something with a common universal method of
       | unlocking is almost useless imho, maybe even dangerous, but
       | probably is a nice exercise
       | 
       | But also the cost for you would be the time to call law
       | enforcement, for them is the time to verify the validity of a
       | document, so its just nonsense
        
         | lnxg33k1 wrote:
         | The last paragraph is a edit in the wrong place sorry
        
       ___________________________________________________________________
       (page generated 2023-12-09 23:02 UTC)