[HN Gopher] How secure is merely discarding (TRIMing) all of a S...
___________________________________________________________________
How secure is merely discarding (TRIMing) all of a SSD's blocks?
Author : goranmoomin
Score : 99 points
Date : 2023-03-08 14:17 UTC (8 hours ago)
(HTM) web link (utcc.utoronto.ca)
(TXT) w3m dump (utcc.utoronto.ca)
| tripdout wrote:
| Unrelated to trim, but for some reason when I used secure erase
| on an SSD with a ZFS pool, the pool was still able to be found by
| ZFS.
|
| That shouldn't be the case, right?
| avianlyric wrote:
| I think ZFS identifies drives by their serial number. So you
| can erase a drive in a pool, and ZFS _on that machine_ will
| still recognise the drive based on its serial number, and know
| its pool membership.
|
| ZFS should then throw all kinds of errors once it notices that
| all the super locks and other FS metadata is missing. But a
| scrub should cause ZFS to simply fix that via normal
| resilvering.
| anecdotal1 wrote:
| No, ZFS identifies by finding superblocks. This drive was not
| securely erased if any superblocks could still be found.
| h506001 wrote:
| Not sure how secure erase works, but I've run into this a few
| times after "erasing". I think it has something to do with boot
| records or partition tables. So there's a piece of some drives
| (usually at the front) that contains this data. You can
| overwrite it properly with the appropriate tools. I always just
| used `dd` on the raw drive ref in Linux to blow it up.
| verall wrote:
| If your bios is not allowing secure ATA functionality ("frozen"
| in hdparm) try doing a pm-suspend and then waking back up. For me
| this unfroze the drive, although I have no idea why. I was then
| able to mess with ata security options, run secure erase, etc.
| calebio wrote:
| IIRC it is often frozen by the BIOS on boot.
|
| I think the pm-suspend/wake 'reinits' (for lack of a better
| word) the drive and doesn't set the magic frozen bit.
|
| I'd love to know from someone who has the actual tech details
| vs. my half-remembering an explanation from a wiki.
| slicktux wrote:
| HDPARM secure-erase uses the OPAL standard which ensures unused
| bad blocks, that the drive normally ignores, are erased too.
| TRIMMING only cleared blocks normally accessible for
| reading/writing. It's not as low level... But as someone has
| mentioned you can just enable encryption and forget the
| keys...most all SSDs are encrypting from new...user and master
| keys just have to be set.
| upofadown wrote:
| Why is this so hard? Why can't we just specify that a particular
| file needs to be actually deleteable and that we don't want the
| system (at any level) to leak copies of any of the data in that
| file? There is no technical reason this is not possible, it is
| just a convention that has caused problems since the dawn of
| computing. There is no point in making a file system that
| supports that filesystem would not be able to specify
| deleteabiliy to the hardware. There is no point in making
| hardware that supports this because there is no file system that
| exists that would have anything to tell the hardware. This
| situation exists simply because of inertia.
|
| Sure there would be performance implications, but who would care?
| You might just want to store a key for some full performance
| encrypted data that you would like to be able to actually remove
| access to. Sometimes performance is not the most important thing
| to optimize for.
| TacticalCoder wrote:
| Full disk encryption that are decrypted using a U2F security keys
| are now here (latest LUKS/systemd allows to do that).
|
| And Yubikey don't leak secrets.
|
| If your system is compromised to the point that someone gets
| access to the full disk decryption key protected by your Yubikey,
| you've got bigger problem than securely erasing the disk.
|
| Need to recommission a disk? _dd_ to the disk because why not.
| Some sectors didn 't get dd'ed? Well, the bad guys need your
| Yubikey too.
|
| So, really, what do we think about Yubikeys?
|
| Are people now going to steal your Yubikey in addition to finding
| the sectors that weren't overwritten by dd?
| calebio wrote:
| is the Yubikey protected by some kind of pin or password or
| something?
|
| and is there something that prevents someone from brute forcing
| that pin/password if they have access to the Yubikey?
|
| I've not used a Yubikey in this way before, sounds really neat.
| avianlyric wrote:
| Somethings not mentioned in the article, but are pretty relevant.
|
| Modern SSD controllers encrypt all data by default. Not to
| increase security, to improve wear levelling. Encrypted data
| should be effectively random data (that's what good encryption
| aims to produce). So encrypting the data ensures that patterns in
| data written to the SSD don't end up creating uneven wear
| patterns in the flash chips.
|
| As a consequence, reading the raw data of an SDD would just
| produce garbage. You would need to also extract the encryption
| key from the SSD controller. Given this encryption isn't meant to
| be secure, it's quite possible to extracting that key is quite
| easy. But I believe that secure erase on SSDs is achieved by
| simply rotating the encryption key used for wear levelling, so
| maybe it's reasonable well protected.
|
| I would expect an SSD to quite aggressively erase TRIMed blocks
| where possible. Erasing a block of flash memory is about 10x
| slower (2ms) than writing to flash memory (200microseconds), so
| there's quite a large performance hit once a drive runs out of
| empty blocks and needs to start erasing blocks in the write path.
|
| Overall I suspect that simply TRIMing most SSD is secure enough
| for most applications. At least secure enough for anyone that
| even asks the question "is TRIMing secure enough". For everyone
| else, you either don't care at all, or your really care, in which
| case you're using multiple layers of security such as full disk
| encryption, secure SSD erase, and shredding drives already.
| timbre1234 wrote:
| The problem with this is that erase-to-program delay is a major
| factor in bad write quality.....you really don't want to erase
| a block and wait a long time before programming it. Where
| "long" is subjective and there are a lot of details here but
| the general rule is that the longer you wait after an erase to
| write, the less accurate your write is (colloquially, your zero
| decays as it sits)......so in practice while you do erase-
| ahead, you don't erase too far ahead of your writing and you
| certainly don't erase at TRIM time in most cases.
| avianlyric wrote:
| Didn't know that. Don't suppose you've got any links that
| describe the physical process that results in the correlation
| between write quality and erase-to-program delay?
| gpderetta wrote:
| But the "encryption" need not be cryptographic strength for
| this, so it might be reversible even without the key. Consider
| an old cypher with a small key for example.
| avianlyric wrote:
| Certainly true, but again, anyone that really cares about
| data destruction is never going to trust TRIM to destroy
| their data. At a minimum they're going to use a mechanism
| that's designed to destroy data (Secure Erase), and more
| likely they're going to use multiple methods to destroy that
| data.
|
| If you're in a situation where you're thinking that TRIM
| _might_ be good enough, then you clearly don't care that much
| about the data potentially being recovered by sophisticated
| attacker. You just don't want it to be trivial to recover
| that data. In that case, even old cyphers and small keys is
| probably good enough.
|
| But once again, if your really care about destroying your
| data, use something's that's explicitly designed to destroy
| data!
| wmf wrote:
| Everyone is using AES now.
| pornel wrote:
| But where's the key?
| LinuxBender wrote:
| As others have mentioned, use encryption. But that has gaps as
| someone can hold onto the drive and wait for _impossible to
| break_ to become _somewhat expensive to break_ to _broke by
| mistake through bad encryption implementation_.
|
| Put the encrypted drive into a hydraulic press and flatten it
| into a thin sheet, then run that sheet through a chop saw, or
| just use tin-snips if your hydraulic press was powerful enough. A
| hydraulic press and a chop saw are a few hundred bucks whereas
| drive shredders can range from $30k to $200k.
| willis936 wrote:
| This is a much more expensive and less effective solution than
| a coffee tin and some gasoline.
| ChoGGi wrote:
| I think an angle grinder would be more accessible than a press.
| fdeee wrote:
| Open them, heat treat the disks in a bonfire, use the magnets
| as fridge magnets (those are quite strong, can fix entire
| books to the fridge instead of just notes).
| chipsa wrote:
| Last I checked, SSDs don't have those (see thread title).
| yourapostasy wrote:
| _> ...hydraulic press was powerful enough._
|
| Can we repurpose a die press to this task and if so, would a
| 100 ton AvE die press [1] be powerful enough?
|
| [1] https://www.youtube.com/watch?v=d_LSPX8cNaE
| LinuxBender wrote:
| I suppose provided that we are not punching and instead
| crushing the SSD chips to dust that would work. Punching
| holes would leave some chips.
| 13of40 wrote:
| Delete all the files then "dd" from the random device until the
| drive is full? Must we always jump straight to the hydraulic
| press?
| throw0101a wrote:
| > _the random device_
|
| /dev/zero would be sufficient.
|
| Also easier to confirm things worked (if desired) since you
| know what to expect on read-back.
| jusssi wrote:
| You're assuming the drive doesn't do something smart when
| it detects it's being filled with zeroes. It could at least
| in theory decide to do the same thing it does when you TRIM
| a sector.
| lazide wrote:
| I suspect it won't be long (if it isn't already the case)
| that defacto run-length encoding is built into SSD
| firmware.
|
| Write 5 gig of zeros? OK! You just got more drive reserve
| capacity!
| bcoates wrote:
| As mentioned in the article, that's not reliable. Drives have
| lots of overprovision blocks and there's no way of
| consistently forcing them to be used; and drives might mark
| blocks as too questionable/worn to reuse and never reset
| them.
|
| Also a standard failure mode of SSDs is refusing to accept
| writes, so you'll have to handle that case.
| georgyo wrote:
| Encryption plus a single rewrite is likely many times more
| sufficient than ever needed.
|
| Even if there is a massive 10% block reserve, you looking
| at a random 10% of an entire encrypted drive.
|
| Figuring out how to just decrypt those blocks is a very
| hard challenge, then figuring out the SSD block mapping is
| going to be very challenging, and then for a chance to
| maybe get something valuable from that 10%.
|
| Multiple very difficult challenges for only a chance of
| maybe recovering something useful.
|
| Related, I just had a hard drive head crash. I was able to
| use dd_rescue to read out 40% of the drive before it fully
| gave out. It's amazing, but at least NTFS stores data
| everywhere. I recovered a few small plain text file, but
| not a single image was recoverable. It was pretty shocking
| to me.
| LinuxBender wrote:
| _Must we always jump straight to the hydraulic press?_
|
| Not always. I suppose it depends on your information security
| case. If your goal is to secure your kids laptop from the
| average thief that is heading to the pawn shop, maybe "secure
| erase" of encrypted drives may be sufficient.
|
| If on the other hand one is protecting intellectual property,
| customer data and so on, then perhaps that average thief was
| hired by someone with significant resources. I would wager
| that a percentage of the people reading this comment are
| using a work laptop and have some IP on their drive that in
| the wrong hands could cost billions. Even some of the emails
| I've seen could do significant damages.
| bombcar wrote:
| Hydraulic press is too obscure, .45 ACP works just as well.
|
| But it depends on your risk profile, for most people a wipe-
| and-reuse is going to be fine, especially if the "reuser" is
| already a trusted entity.
| LinuxBender wrote:
| I suppose if one could obliterate most of the chips with 3
| or 4 well placed shots then your solution is certainly more
| cost effective than mine should one not have a future use
| for a press. This sounds like a video idea for
| DemolitionRanch.
| amalcon wrote:
| A firearm is a silly tool for this. A hammer (optionally
| combined with good nails) can do substantially the same
| thing to all relevant materials (aluminum, glass, ceramic,
| silicon, plastic), but cheaper and more safely.
| 13of40 wrote:
| I think a springloaded center punch to each of the chips
| would do a pretty good job of it.
|
| https://www.harborfreight.com/spring-loaded-center-
| punch-621...
| lazide wrote:
| Silly? Maybe. Fun? You bet!
| adql wrote:
| I guess used microwave would be easiest and cheapest option
| for SSDs
| bombcar wrote:
| A microwave may not even damage the chips internals;
| you'd have to actually test and verify it.
| wkat4242 wrote:
| That's a nice solution in the US I guess, not so much for
| us in Europe :)
| jsiepkes wrote:
| > Flash storage, unlike traditional hard drives, can really be
| completely and irrecoverably erased, with no lingering magnetic
| ghosts that a sufficiently determined person could in theory
| reconstruct.
|
| I think people vastly overestimate the possibility to recover any
| data from a wiped HDD.
|
| See for example this article by SANS [1]. To recover a single bit
| you have a better chance of flipping a coin to see if the bit was
| a zero or a one then you have when you are actually trying to
| reconstruct it with lab equipment.
|
| [1]
| https://web.archive.org/web/20140621130410/https://digital-f...
| germanier wrote:
| This can't be true. Any method must be at least as good as a
| coin toss. If it's worse you can just bit flip the result and
| end up better than the coin.
| mecsred wrote:
| I don't think that follows? Just because a better method
| exists (the inverse) doesn't make the original perform
| better.
|
| Imagine the following method: take whatever the bit was, and
| set it to the opposite of that. 0% < 50%. Of course you can
| invert and get 100%, but that's a different method. It
| doesn't make the original any better.
| DSMan195276 wrote:
| The article isn't super clear, but I think what it's saying
| is that the data recovery method they were testing (when
| looking at recovering a single bit) was as good as 92%, and
| as bad as 32%, depending on how the data was overwritten and
| other factors like the specific drive. Thus you likely can't
| just flip the result to get better odds because in a real
| scenario you wouldn't know which category you fall into
| (whether it's really good, or really bad), and overall if you
| don't know that information then the odds are close to 50%.
|
| Edit: And of course even a high of 92% is abysmal for a
| single bit, since the combined odds of multiple bits quickly
| goes to zero for any sizable amount of data.
| detrites wrote:
| Unbelievably, the paper actually makes that claim:
|
| > That is, if you toss a coin, you have a 50% chance of
| correctly choosing the value. In many instances, using a MFM
| to determine the prior value written to the hard drive was
| less successful than a simple coin toss.
|
| More believably, the paper was written by Dr Craig Wright.
| marginalia_nu wrote:
| Right, if you flip a hundred coins, about half of them land
| heads and the other half tails. The correct coins we'll
| call oracles, and the incorrect ones liars.
|
| Now you perform a hdd recovery that is successful 70% of
| the time. That is still worse than the performance of the
| oracle coins which were correct, and if you invert the
| performance of the liars, they also beat the performance of
| the recovery.
|
| If you have two coins, one which is always correct and one
| which is always incorrect, you can flip one of them to
| decide whether the other one is correct (and pick the
| opposite).
|
| Check mate, statisticians!
| kryps wrote:
| The paper does not make that claim. According to the paper
| the probability of recovering the correct value of a single
| bit is 96% for a pristine drive and 56% for a used drive,
| both better than a coin toss. Of course the probability
| gets worse if one tries to recover more bits (but still
| better than n coin tosses for n bits).
| kmeisthax wrote:
| Bits are correlated: we care about the order of the bits, not
| just their population count.
|
| Furthermore, <50% is only an antipredictor for a single coin
| flip. If you have two bits - two coin flips where you care
| about the order - then there's four values, and you have to
| be <25% to be an antipredictor. Even then, an antipredictor
| only removes one possibility[0], so flipping the bits will
| only slightly improve your terrible chances of recovering the
| data.
|
| [0] https://en.wikipedia.org/wiki/Monty_Hall_problem
| throw0101a wrote:
| > _See for example this article by SANS [1]._
|
| According to NIST 800-88 Rev. 1 a single overwrite is fine:
|
| *
| https://en.wikipedia.org/wiki/Data_remanence#Feasibility_of_...
| Thaxll wrote:
| All those articles are very theoretical, in reality 1 pass of
| dd /dev/zero makes things unrecoverable, for recent SSD since
| trim is enabled by default you can't recover anything, I
| deleted a document by mistake on an SSD and it was impossible
| to get back, the moment I pressed delete on windows the trim
| command was sent and everything was erased on the ssd.
|
| Pro recovery compagny that are not shady know that SSD recovery
| with TRIM is impossible.
| luma wrote:
| So ... you didn't read the article then?
| Thaxll wrote:
| The article is light on details and assume a lot of things.
| he doesn't prove anything, show us that after succesful
| trim you're able to recover anything.
|
| From my experience it's impossible.
| fdeee wrote:
| I think you are right in that it is quite impossible to read
| data that has been overwritten from a sufficiently modern HDD.
|
| But all modern HDDs retire sectors that exhibit a higher
| correctable error rate and replace them by reserve sectors.
| Those retired sectors then still contain readable data (maybe
| with some bit errors) if you know the appropriate factory mode
| commands. Overwriting the entire disk also won't overwrite
| retired sectors, except if the disk has an explicit function
| for it and you trust that function to work properly.
|
| In short, you always need full disk encryption.
| Dalewyn wrote:
| Or a low level format.
| bcoates wrote:
| Also it's not obvious that it works the other way.
|
| The only requirement of the flash reset operation is that it
| consistently causes bits to read as 1 and that the normal write
| operation allows them to read as 0 again; it doesn't actually
| follow from that that an erased-but-not-reprogrammed block will
| have cell charge levels that are indistinguishable from each
| other based on the pre-erasure charge level.
| [deleted]
| h506001 wrote:
| Super interested in this and would love to hear about some
| techniques. Used to work at a HealthTech co. We had an
| "appliance" that we'd send to doctor offices to integrate with
| other diagnostic machines on the network.
|
| Sometimes we would send out new ones to replace the old. When we
| got the old ones back, it was always unclear how to purge and
| recommission SSD/NVME drives.
|
| My best attempt was using GNU shred, but it wasn't recommended
| for flash-based storage back then.
| SirGiggles wrote:
| In addition to the sibling comment, I'm surprised that there
| was no mention of FDE.
| h506001 wrote:
| We did do some encryption with LUKS, and I'd try to write
| over boot records, keys, and headers, but I was pessimistic
| that was enough. Not an encryption expert myself. Always felt
| that any given encryption tech (be it hardware or software)
| has possibility of vulnerability later found or backdoors.
|
| So it made sense to me that a physical erasure prior to
| recommission would be good. There's also
| regulatory/compliance checkboxes (be them effective or not).
| Nursie wrote:
| Buy SSDs with secure erase (many of them!), they encrypt data
| internally. Secure-erase the throws away the key, and all the
| data is now irretrievable.
|
| Job done...
| hedora wrote:
| I take your standard, solder it to a motherboard, and disable
| it with a TPM protected bios.
| beardog wrote:
| If you trust that the secure erase part of the firmware
| functions properly. There was work in the last 5 years to let
| the OS (at least Linux) do most of the SSD controller
| functionality which I think would be helpful if it caught on.
| scns wrote:
| https://news.ycombinator.com/item?id=35069622
| fdeee wrote:
| The only proper way of disposal is physical destruction,
| preferrably on site and under observation of inhouse staff.
| There are contractors you can hire in those:
| https://shredsupply.com/hard-drive-shredding-trucks/ (no
| relation, just arbitrary google hit).
|
| I'm also unsure as to why you are getting drives back at all,
| any of your customers should not have any kinds of storage
| devices leave their site intact. At least that is the standard
| over here in Europe for healthcare and other industries dealing
| with sensitive data.
| bshipp wrote:
| Shredding/sledgehammer is likely the best option for secure
| disposal of mechanical drives, but SSDs are a different
| animal and are likely reusable given some of the suggestions
| in this thread.
| hedora wrote:
| Most hard disks support hardware level encryption and full
| disk erase at this point.
|
| There's very little need to sledgehammer anything given
| realistic attacker models.
| fdeee wrote:
| Both, HDD/SSD encryption in hardware and secure erase
| have been proven untrustworthy numerous times.
| fdeee wrote:
| Not really. HDD recoverability is a myth, anything
| overwritten isn't coming back with modern HDDs. Bits can't
| "bleed out" anymore, density is far too high for that.
|
| The thing you need to guard against is relocated/reserve
| sectors, in HDDs same as in SSDs. The proper way to do this
| is full disk encryption, and if that's not possible,
| physical destruction.
| h506001 wrote:
| Oh, we did stuff like this for disposal. The tricky part is
| drives we desired to recommission.
| Felminor wrote:
| Most relevant ssds are always encrypted.
|
| I don't think it's necessary to delete it.
|
| But if you want, write the disk fully
| katdork wrote:
| The absurdity here that you can't do it because your BIOS won't
| let you, hdparm can do this! You can literally just boot a Live
| USB!
|
| https://wiki.archlinux.org/title/Solid_state_drive/Memory_ce...
|
| And anyone who thought TRIM would be a reliable way to get rid of
| data to begin with didn't have an understanding of TRIM!
| aver4geredditor wrote:
| Also see:
|
| https://wiki.archlinux.org/title/Solid_state_drive/Memory_ce...
|
| https://www.usenix.org/events/fast11/tech/full_papers/Wei.pd...
|
| Edit: see section 3.2.2 in the PDF (and the corresponding table
| 2):
|
| > In most cases, overwriting the entire disk twice was sufficient
| to sanitize the disk, regardless of the previous state of the
| drive. There were three exceptions: about 1% (1 GB) of the data
| remained on Drive A after twenty passes
|
| This is about normal overwriting, however. The fastest random
| overwriting program on Linux I know of is `shred`
| generalizations wrote:
| Or you encrypt the entire drive. Then the secure erasure is a
| matter of throwing away the keys, and you don't have to bother
| with thinking through your threat model.
| wyager wrote:
| Two issues with that - you have to make sure you dispose of the
| key(s), and this doesn't let you securely erase just _part_ of
| the drive.
| buildbot wrote:
| 3. Technically someone could uncover a flaw in whatever
| encryption you used.
| rqtwteye wrote:
| Once you have an attacker with that kind of technical
| skill, you are in a totally different world.
| JosephRedfern wrote:
| Not necessarily -- if the drive was found and decrypted
| after the exploit was leaked and made public (perhaps
| YEARS after it being a 0-day), it wouldn't necessarily be
| a skilled attack.
| cryptonector wrote:
| Throwing away the keys is surprisingly hard to do.
|
| Say you have one root key and you derive per-file or per-block
| keys using various metadata (inode numbers, generation numbers,
| block addresses, whatever). You can't throw away derived keys
| though!
|
| Or say you generate random keys per-file and you store those
| somewhere (it's annoying to have to store them). Now to throw
| those keys away you need to re-write the blocks containing
| them. If there's any behind-the-scenes copy-on-write going on
| then re-writing a block doesn't necessarily lose its old
| contents.
|
| The only thing that's easy to throw away -maybe- is the top-
| level / root keys. But that means deleting the entire
| filesystem.
| generalizations wrote:
| > The only thing that's easy to throw away -maybe- is the
| top-level / root keys. But that means deleting the entire
| filesystem.
|
| Well, yeah, that's why I said you encrypt the _entire_ drive.
| If you do things that make it hard to throw your keys away,
| then it 's gonna be hard to throw your keys away.
| [deleted]
| wkat4242 wrote:
| If you care about security then you'd have full disk encrypted
| the thing anyway. So really, it's not a problem.
| fdeee wrote:
| This is why you always want to use full disk encryption (FDE).
| Then it doesn't really matter whether some blocks are recoverable
| after TRIM. It also doesn't really matter whether the Secure
| Delete function works. It also doesn't matter whether the very
| expensive security-buzzword-compliant secure deletion snakeoil
| software really works.
|
| Also, TRIM is only possible with drives that are still in working
| order. Very often you can't TRIM or secure delete a drive that is
| defective and returned by RMA. In that case you either need a
| very expensive no-disk-return support contract. Or you just use
| FDE.
| tjoff wrote:
| TRIM and FDE isn't perfect though as it leaks information about
| what parts have been written etc.
|
| And if you turn off TRIM you get a massive performance
| decrease.
| vorticalbox wrote:
| Why would someone turn off TRIM?
| danuker wrote:
| To mask the extent to which a drive has been filled, or to
| figure out how many blocks have been deleted since the last
| TRIM. I have yet to discover any use for this minuscule
| "leak", even when considering nation-state adversaries.
| It's much easier to find other channels to leak data
| through.
|
| The disadvantages are massive, such as significant slowdown
| when the drive gets filled. Yet the creators of dm-crypt
| are paranoid about enabling it by default:
|
| https://wiki.archlinux.org/title/Dm-
| crypt/Specialties#Discar...
|
| I couldn't understand ref 3: https://web.archive.org/web/20
| 160709174950/http://www.saout....
|
| Ref 4: "you have an information leak where filesystem-
| discarded blocks (by TRIM) can be identified by an attacker
| with low effort"
|
| https://web.archive.org/web/20160709183108/http://www.saout
| ....
| WirelessGigabit wrote:
| Edit: Below doesn't apply to T2 enabled Macs.
|
| If you erase the volume, regardless of whether you had FileVault
| enabled or not, the key is deleted [0]. If
| FileVault isn't enabled on a Mac with the T2 chip during the
| initial Setup
|
| Assistant process, the volume is still encrypted, but the volume
| key is protected only by the hardware UID in the Secure Enclave.
|
| and When deleting a volume, its volume key is
| securely deleted by Secure Enclave
|
| [0]
| https://www.apple.com/mideast/mac/docs/Apple_T2_Security_Chi...
|
| ----------------------------------------------- Incorrect
| ramblings below: -----------------------------------------------
|
| Apple recommends setting up FileVault on their SSDs. It is
| literally the only way to ensure that the data on the SSD is not
| recoverable.
|
| And you should do this before you put anything ON the Mac.
|
| If you add a file and only later encrypt the drive, you have no
| guarantee that that file still isn't somewhere readable one way
| or another.
|
| This is important when you think about buying a Mac and then
| choose to return it 3 days later.
|
| Apple states [0]: Note: With a solid-state
| drive (SSD), secure erase options are not available in Disk
| Utility. For more security, consider turning on FileVault
| encryption when you start using your SSD drive.
|
| On their dedicated encryption page [1] they do state that devices
| with T2 are encrypted by default: Note: If you
| have an iMac Pro or another Mac with an Apple T2 Security Chip,
| the data on your drive is already encrypted automatically.
| However, turning on FileVault provides further protection by
| requiring your login password to decrypt your data.
|
| However I can't find any reference to see how to reset that
| built-in key.
|
| [0] https://support.apple.com/guide/disk-utility/erase-and-
| refor...
|
| [1] https://support.apple.com/guide/mac-help/encrypt-mac-data-
| wi...
| mharsch wrote:
| The keyword / feature you're looking for is 'sanitization'.
| https://ieeexplore.ieee.org/document/10008943
| adav wrote:
| Take the drive out and smash it to bits.
| tracker1 wrote:
| If security is your biggest concern, and not reuse... then using
| industrial shredding machinery is your best bet.
|
| If you want reuse... then a handful of fill/erase cycles with
| random data is probably your best bet, even then, there will
| still likely be some overprovisioned blocks with prior data.
|
| Encryption and throwing away the key doesn't do more than random
| data to fill said drive.
| h2odragon wrote:
| https://en.wikipedia.org/wiki/Thermite
|
| Securely erases all known forms of electronic data storage.
| Cheap, reliable, fun for the whole family!
| MarkusWandel wrote:
| There was (is?) a type of hard disk where the platters are made
| out of glass. These are easy to dispose of securely... drop
| onto a concrete floor from about six feet up. Shake, feel
| finely pulverized glass rattling around inside. Done.
| wkat4242 wrote:
| That's it. You can't beat maximum entropy :D
| dark-star wrote:
| I'm surprised people actually think TRIMming is in any way a
| "secure delete" operation.
|
| It's basically the "quick format" of SSDs: "hey, all those blocks
| here, I don't care about them anymore, use them as if they were
| free..."
|
| Without OS-side encryption, Secure Erase is the only reliable
| option (SSD encrypts everything with an internal key which then
| gets deleted by the secure erase command, leaving only random
| data behind)
| marcosdumay wrote:
| > It's basically the "quick format" of SSDs: "hey, all those
| blocks here, I don't care about them anymore, use them as if
| they were free..."
|
| Due to implementation details, SSDs can only use a block if it
| is clear. Thus trimming a block and waiting for long enough
| would be sufficient to erase the data if the driver actually
| enforced that the block will be reused.
|
| So, it's not good enough, but this is not obvious at all.
___________________________________________________________________
(page generated 2023-03-08 23:02 UTC)