NTSB report: Decryption of images from the Titan submersible camera [pdf] (2024) (opens in new tab)

The number of stupid decisions that went in the design and construction of the Titan is astonishing. One of my favorites was that, after putting on the carbon fiber around the tube, they would sand imperfections to make the surface perfectly smooth, severing layers in the process! It shouldn't require an engineering degree from MIT to recognize this as ill-advised.

'And the director himself declined'

An anecdotal personal story as it aligns with this exact statement although no one got killed but data breaches certainly occurred.

Many years ago now I was propositioned to be on the board of a financial technology company and they spared no expense in literally rolling out the red carpet for my arrival. I found it all very laughable being solely focused on business and the technical details as I was not being fooled by all the schmoozing. After hearing all the unrealistic business objectives and the promise of having the Philadelphia Flyers involved I then asked to meet the technology team that built the product to see a demo. They bring in one young guy who built it all, the executives are still present mind you, and they allow me to ask any and all questions about the platform that nearly no one in management comprehended. After seeing the demo which involved several blatant security issues I asked only one more question of the sole developer: "Would you put your financial information into this system?"

He provided his answer in front of the companies executive board and I can still see their reactions to this very day. I then stood up and thanked everyone for opportunity and left.

Wow! Man, an insider with these kinds of concerns isn't exactly exonerating or excusing themselves with such a testimony. Whistle-blowing to any relevant authority as hard as possible seems like the bare minimum? And if there's no governing agency to pass the responsibility over to, I think you gotta quietly approach the first customer (or victim) with these concerns if not a newspaper

I read that the pilot was also basically suicidal. His wife had died, and he was completely fine with the danger because he would die doing what he loved, and he didn't really want to live anymore.

Took me forever to find the actual quote - ChatGPT and Gemini kept trying to gaslight me that it’s not a real quote or that Willie said it to Bart until I gave the exact quote (at which point normal search engines were fine):

> A certain agitator, for privacy's sake, let's call her Lisa S. No, that's too obvious, let's say L. Simpson.

Lisa the Vegetarian

Maybe it is policy. If you have three experts in the field and you redact the details for two of the interviews taken, you can’t work it out that Bob was one of the two. Granted, they borked the redaction here.

From the report:

> To conduct the CT scans, the large mass was evaluated by a third-party laboratory under NTSB supervision. This facility had a range of scanners with different power and energy levels and could scan large masses using a rotating table, avoiding the need to rotate the mass itself. Ultimately, the third-party laboratory attempted to image the large mass at a power as high as 320 kilovolts (kV). The scans conducted at 320 kV were not powerful enough to penetrate the object, and as a result, no internal structures or voids were visible, and no memory devices could be identified. The NTSB evaluated using another laboratory with higher power and energy CT scan devices, however, there was concern that increased CT scan energy could damage data stored on any surviving NVM chips. Consequently, higher-energy scans were not pursued.

I'm no expert, but remember reading about neutron imaging ([1]). I'm curious if that was deemed unfeasible, too expensive, or having little chance of success? From Wikipedia:

> X-rays are attenuated based on a material's density. Denser materials will stop more X-rays. With neutrons, a material's likelihood of attenuation of neutrons is not related to its density. Some light materials such as boron will absorb neutrons while hydrogen will generally scatter neutrons, and many commonly used metals allow most neutrons to pass through them.

[1] https://en.wikipedia.org/wiki/Neutron_imaging#Neutron_radiog...

That's a striking image! Thanks for sharing - that really hits home on the pressures involved.

You can just make out the heatsink fins of the three PCs there, stacked atop (and now kind of inside) each other.

That truly is one of those “let God sort them out” situations.

Pretty sure tech exists to recover data from flash memory with cracked dies...

I guess they decided it wasn't worth pursuing.

This is why I always shake my head when the Reddit armchair security experts say "The data wasn't even encrypted!? Amateur hour!" in response to some PII leak.

Sure, sure buddy, I'll encrypt all of my PII data so nobody can access it... including the web application server.

Okay, fine, I'll decrypt it on the fly with a key in some API server... now the web server had unencrypted access to it, which sounds bad, but that's literally the only way that it can process and serve the data to users in a meaningful way! Now if someone hacks the web app server -- the common scenario -- then the attacker has unencrypted access!

I can encrypt the database, but at what layer? Storage? Cloud storage is already encrypted! Backups? Yeah, sure, but then what happens in a disaster? Who's got the keys? Are they contactable at 3am?

Etc, etc...

It's not only not as simple as ticking an "encrypted: yes" checkbox, it's maximally difficult, with a very direct tradeoff between accessibility and protection. The sole purpose of encrypting data is to prevent access!

This has already happened to Windows users when BitLocker disk encryption is enabled by default and they do something that causes the encryption key to be lost.

You can have the key saved in your Microsoft account.

Scrambling and encryption are two different things. Scrambling is very easy to do at line rates. Encryption not so much.

Ethernet is a good example. It has the same problem where long strings of 0's or 1's can cause clock recovery problems. The solution as clock rates have increased is to just run all the data through a scrambler driven by a simple Linear Feedback Shifter.

If you're talking about SED feature, no, it isn't widespread since it's regarded as an "enterprise" feature and only available in minority of drives (regardless of HDD or SSD). Client or OEM variants of same drives (otherwise identical) lack SED option most of the time and doesn't encrypt data by default.

To my knowledge, encoding avoids runs to avoid desynchronization in a way that isn’t encrypted.

> What would you say is the threat model that leads one to auto-encrypt sdcards?

Jumping off of daemonologist's point, the most convincing model I could think of is one where you are consistently removing the SD Card, likely because you are swapping multiple SD cards back and forth. But this still seems bad! In that case your multiple SD cards all share the same decryption key (or I guess less egregiously all at least share the same physical vulnerability of that device's nonvolatile memory).

> For a machine that needs to boot unattended, what would you do with disk decryption keys?

This depends entirely on what you mean by unattended. Here's some candidates:

1. The machine has a network connection and you would like to boot it over the network. In that case you have a small unencrypted bit that handles the boot sequence and then pass the decryption key over the wire, store in volatile memory, and wipe on shutdown or logout.

2. The machine is regularly serviced/booted by an in-person operator. You give the decryption key or passphrase to the operator to decrypt and boot the machine.

3. The machine is meant to autonomously reboot itself due to e.g. error conditions. In extreme cases when the machine detects that there is a large probability of physical compromise, it shuts down. In this case for the former I would imagine some power supply, e.g. a backup battery, that keeps the volatile memory up when rebooting and in case of large probability of physical compromise there is a forced shutdown and/or wipe of the volatile memory.

4. An operator needs to periodically boot up the machine, but the operator should not be able to access any previous data the machine has recorded (data from the moment operator arrives forward is assumed leaked to the operator because e.g. the operator can just position their own sensor in front of the machine and collect data). In that case asymmetric encryption should be used and the encryption keys should be stored on the machine, but the decryption keys should not, effectively turning the machine into a write-only device from the operator's perspective.

The only case I could imagine where you want the machine to boot unattended and you'd keep the decryption keys in nonvolatile memory on the device is if you want an operator to be able to boot the device without knowledge of the decryption key and also to be able to view historical data previously recorded by the device. But in that case there is no functional difference between that and a device that is unencrypted! In both cases you boot up the device without a password and voila all the data is in front of you ready to be read! And indeed that's basically what happened here (modulo the difficulties associated with the device being damaged). And in that case encryption seems like pure overhead for no real security benefit.

It honestly makes sense. You are paying for the pressure engineering, and can take advantage of an off the shelf camera system. Maybe use a special lens or filter or something but why bother customizing the software/hardware of the camera much.

They probably should still know what it's doing though...

I came here to say "that's definitely a Teensy 3.2"

The black cable goes dangerously close to the pushbutton of death. ;-)

> It’s faster than having to route your MCU

Common misconception. A handful of capacitors, SPI NOR flash, an inductor, and a crystal is way easier to place and route than a restrictive module that completely disables your ability to use SWD/JTAG on an otherwise excellent MCU.

Yup, if it works in your testing, why bother changing it?

Well, I'll be darned! I wonder if Paul Stoffregen knows about that!

edit: probably? It was posted at the Teensy forum about a month ago.

https://forum.pjrc.com/index.php?threads/the-deepest-teensy....