Here’s a puzzler for you: how do you securely send data from one airgapped computer to another? Sending it over a network is right out, because that’s the entire point of an airgap. A sneakernet is inherently insecure, and you shouldn’t overestimate the security of a station wagon filled with tapes. For his Hackaday Prize entry, [Nick Sayer] has a possible solution. It’s the Sankara Stones from Indiana Jones and the Temple of Doom, or a USB card reader that requires two cards. Either way, it’s an interesting experiment in physical security for data.
The idea behind the Orthrus, a secure RAID USB storage device for two SD cards, is to pair two SD cards. With both cards, you can read and write to this RAID drive without restriction. With only one, the data is irretrievable so they are safe during transit if shipped separately.
The design for this device is based around the ATXMega32A4U. It’s pretty much what you would expect from an ATMega, but this has a built-in full speed USB interface and hardware AES support. The USB is great for presenting two SD cards as a single drive, and the AES port is used to encrypt the data with a key that is stored in a key storage block on each card.
For the intended use case, it’s a good design. You can only get the data off of these SD cards if you have both of them. However, [Nick] is well aware of Schneier’s Law — anyone can design a cryptosystem that they themselves can’t break. That’s why he’s looking for volunteers to crack the Orthrus. It’s an interesting challenge, and one we’d love to see broken.
Nope the idea is naive as both cards can be intercepted. There are better ways of doing this that are far more secure, assuming the device itself was not interfered with during it’s original transit, and that by the way was a huge clue.
Well, this CAN be made, if not completely secure, at least secure enough that only people with very deep pockets can manage it.
Send each card via a separate carrier. For example, FedEx and UPS. In order for somebody to intercept both would be very difficult without government help.
“without government help” oh right just eliminate the most likely interceptor of the data and you are good to go, hmmmm….
Again, it depends entirely on your use case and threat model, as does anything to do with security and cryptography.
It’s not necessary to prevent interception, just to detect it. If the first one has been intercepted, don’t send the second one. Instead, send the first of a new pair that is encoded differently.
Just a funny thought: both FedEx and UPS will subcontract USPS to complete deliveries. Heh.
If both cards are intercepted, yes, the game is up. The problem of making sure that doesn’t happen is outside the scope of Orthrus itself. If you *can* keep the cards separated, then Orthrus does solve the problem of making them useless independently.
How you do that depends on your usage needs and your threat model, and role-playing it here in the comments section isn’t a fruitful exercise, frankly.
It doesn’t matter how you spin it is is still a form of security through obscurity that normally would be mocked on HAD.
Well, opinions are like assholes. Everyone has one and they usually stink.
Then there was that guy on Reddit who had two….
>Then there was that guy on Reddit who had two….
Are you seriously suggesting there are two differing opinions on Reddit?
I disagree. If the encryption key for one card is on the other then it’s multi-factor authentication at the least.
If you still believe that ‘hiding the key’ is security by obscurity then you would have to believe that of the whole internet SSL layer.
The way it works is that the volume key is created with a key derivation operation (AES-CMAC-PRF) that takes in 3 chunks of key derivation material. One portion is on one card, one portion is on the other card and the third portion is common to both. That key derivation yields the volume AES-128 key. In addition to that, a portion of the nonce used for each block (the remainder of the nonce is the block number) is stored on opposite physical card from the data.
This means that having one card doesn’t give you even “half” of the volume key. It gives you part of the material used in a key derivation function that denies you the ability to predict anything about the resulting key from the material you do possess. In addition, you’d be missing the nonce used in the per-block crypto for the card you do have. In order to get anything from the card, I believe you’d have to brute-force a total of 224 bits of key material: the volume AES key (since the volume AES key is 128 bits, it’d be faster to directly brute-force that than to brute-force the 256 bits of missing key derivation material) and the missing 12 byte nonce.
All of this is outlined in the code for the Orthrus Challenge (see the link in the article). In there is Java code to perform a decryption of an Orthrus volume if you have the images of two paired cards. The Java code is a lot easier to read than the firmware source, IMHO, but it’s trivial to demonstrate that the two implementations perfectly interoperate.
That is not how RAID works, so no you are comparing apples with bananas, and they don’t even have the same shape.
Well, it’s RAID-0 in the sense that the data is striped across the two cards. The crypto layer on top of that is something else.
Physical separation is not obscurity.
Temporary physical separation is obscurity. It is a dumb as hiding your password under your keyboard and as others have also pointed out there are easier and far more secure ways to do the same job, but even then it will not do you any good if you are noticed.
@ ???? ???? It’s not. It’s more line hiding two of three clues to the password under two different keyboards while you also know the third clue. And it’s only possible to get the password by knowing all three clues. So it’s not even remotely as dumb as hiding the password under the keyboard.
The point of the device is not that you only do physical separation. There’s also encryption going on that relies on having both cards, the third derivate and the nonce at the same time.
I’m going to point out what I thought would be obvious, but did it occur to you that obscurity and physical risk might be a required part of a particular task? I don’t believe this or any project here is meant to fulfill every possible security need. But there are use cases that this would/could be perfect for.
Besides, not everyone here is dealing with government buildings or international borders. Those are some very extreme scenarios that few would ever run into. SD cards are everyday items that 99.9% of the population wouldn’t think twice about.
As for your high-risk scenarios, if you can’t offer a better solution, or constructive improvements, you’re simply an armchair critic. It doesn’t make you look good, or smart. You just come off as jerk.
Actually if you had looked at the rest of the comments you would see clearly what a complete jerk you are. LOL, you idiot, a far better method was described, several times.
Also, you don’t need to trust an individual Orthrus device. Since it’s open source firmware and open hardware, you’re more than welcome to build your own, examine the firmware for flaws, compile it, and program the chip yourself.
You need to buy two for it to be useful, unless you transport the card reader separately.
This does bring to mind something worth mentioning: for all of the border-crossing talk in the comments here, one aspect that hasn’t yet been mentioned is that the ATXmega32A4U is export controlled in the U.S. So folks outside the US need to source the parts for one from elsewhere and build it themselves. This is one of the big reasons I made it an open hardware / open firmware project – I can’t export them without getting a license.
so send three cards
#hackTheHack
You only need to send one card, that is XORed with a block of random data that the destination already has a copy of. Outputting XORed data to USB from two paired cards, the message card and the random card you already have, can be done with a $2 MCU, it is that easy. But as I keep pointing out, getting noticed with that randomised card is going to get you all sorts of unpleasant attention and your name permanently on a list or two.
You idiot. You complain many times about transporting the 2 separate (original) cards being “security through obscurity” (which its not), and then you suggest – gasp – transporting the data using 2 separate cards! Cause guess what? “a block of random data that the destination already has a copy of” <– this means its no longer random data. You've made a copy, transported that copy, and rely on the patterns in it to reconstruct your data. Its no longer random.
I had a similar thought, it would be easier for an attacker to intercept both cards in transit than to crack a good encryption system.
Quoth
> …There are better ways[…] *assuming* the device itself was not interfered with …
(Emphasis mine)
Ah, this harmless word “assuming”. It must be the most important word in security research…
While it’s true that the XMega doesn’t have any facilities like a secure boot loader to prevent someone from loading replacement firmware, there are ways to seal the device in an enclosure that would make accessing the programming interface very difficult.
What’s left is trying to leverage any bugs in code that would allow you to use the USB or SD interfaces to get code in. If there are bugs in the firmware that facilitate this, then the fact that it’s all open source ought to facilitate getting them discovered and fixed.
Another option is to simply program known-good firmware into it before any critical use.
Yeah well that is the reality of any communications system, no point sending messages to a compromised node if it has the keys because you have already lost the game.
Keep in mind that, provided that you use sufficient encryption, you no longer need the air-gap. Use this strictly for the key sharing, and the encrypted data block can be shared via more conventional means.
Putting a device in the middle opens up a LARGE number of other security opportunities, rather than just having it be (essentially) a pass-through controller.
For example, we can create single use / self destructing keys. With such a system, synchronizing the two cards can also prevent copying, because if they haven’t been used in the same manner they’ll be destroyed by the controller. Also incorporate some physical layer, even as simple as a PIN entry.
Cards also have serial numbers and other unique read-only properties which can be cross referenced between the two, further complicating any decryption efforts. Way back in the day you could get read timings from cards that were unique-ish, for example. One card may repeatably read the block in 7us and the other in 9us. Incorporate as many things such as this (which are provably reliable to determine).
You’re correct about potentially just using Orthrus to share a key to a larger encrypted store kept elsewhere. It turns out, though, that the smallest microSD cards you can get from Amazon these days are 8 GB – which makes a 16 GB Orthrus volume. The only reason not to just store the whole thing on Orthrus is that (today, at least) Orthrus is kinda slow.
I didn’t want to open up the trust to include properties of the cards themselves, since there’s no guarantee that the card manufacturers (*ALL* of them) take pains to make those properties truly trustworthy. However, it’s certainly an opportunity for enhancement if any such properties can be demonstrably trustworthy.
So far as I know, there’s no way to detect if an SD card has been imaged between uses by Orthrus, so I’m not sure your copy prevention idea is something that can be made reliable.
I specifically did not want to add PIN or password protection to Orthrus, as doing so either requires a user interface on the device itself (costly in dollars and space), or requires it to be more than (or not) a USB Mass Storage device, bringing up the spectre of special drivers or software or what not. Adding further protections on top of Orthrus could be done easily at the filesystem or file level.
Copy protection could be done by finding some unique identifier of the cards and embedding that in the formatting. That data wouldn’t match on a copy of the card and your dual card device could refuse to read it.
If the person who made a copy of the cards left the copies, you’d know they’d been copied because your dual card device would refuse to read them. It should have some way of indicating if only one card is a copy.
There’s a spy novel plot point. The spy was supposed to copy both cards and take the originals, then return them before anyone attempted to access the data again. But oops, the spy fumbled and took one original and one copy.
Now two agencies are after both original cards.
“That data wouldn’t match on a copy of the card and your dual card device could refuse to read it.”
The problem there is that the firmware is open-source. There’s no reason that whoever makes the copy couldn’t also copy the meta-data, because the firmware would show them exactly what they’d need to grab. And there’s no reason to suppose that whoever copies it would copy it to another card, so they could preserve the meta data alongside the card content out-of-band.
>>>Orthrus is kinda slow.
Check ISOSTICK project there is AVR32 MCU. it’s a much much more powerfill MCU with USB support including MASS STORAGE stack.
A more powerful controller is definitely the next step – it would preferably need to have SDv2 support, hardware AES (maybe even AES-256) and high-speed USB.
At the moment, the AVR candidate (and since it’s a whole new toolchain, I might as well also look into ARM and PIC32) is the AT32UC3A4128S, but going there will mean a whole series of “firsts” for me. I need to get an AVR32 toolchain up and running, learn how to do hobbyist BGA as well as BGA PCB design, programming via JTAG, 4 bit SD (without the NDA documentation), High speed USB… It’s a whole pile of new stuff to digest all at once. It’s giving me the feeling of being on the 30 meter dive platform for the first time. That’s not to say I won’t do it… The idea of being able to be within an order of magnitude of native SD performance is definitely tempting.
Doesnt stand SD for secure digital? IIRC a card can be locked and made inacccessable by sending some commands to it controller.
Although that IS what SD stands for, I am not sure how universally that portion of the spec has been actually been implemented. I also don’t believe that those commands are available over the SPI interface, which is the only way I can (currently) talk to the cards, as I haven’t obtained the NDA spec from the SD mafia (and if I did, I don’t think I could open-source the resulting firmware).
The full spec is out there if you Google hard enough. Though you’re right, you wouldn’t be able to use it legally.
And I believe you’re right about needing SD mode commands to do security. I know for eMMC you can’t do boot or RPMB partition access in SPI mode.
And as Bunnie has proven, you can’t be certain about the integrity of the SD controller on a given card, so I wouldn’t trust that a card’s built in security features aren’t backdoored or are easily compromised.
Yeah, and you can write back to the same registers to unlock again, if I’m not mistaken. More like a software defined write-protect switch.
I kinda like the idea. Might be naieve of me, but I could have seen a use for this on a previous job. We had to deal with getting firmware for a 20,000+ GBP analyser from head office, to a client in a country, whose customs team had shown a great deal of interest in the product during shipping. We’re talking all the screws out, full mechanical disassembly, and we are pretty sure some attempts to poke around with the code (a “desktop.ini” file on a card that previously had none…).
We would have been uncomfortable mailing a storage device with the code, and equally unhappy to travel with it. Yet more fool on us; the units were programmed from source; the system lacked ability to be programmed from a standalone tool, let alone with an encrypted image!
A pretty niche use case, but it would have been just the tool for this unfortunate job…
Secure data border crossing was exactly one scenario I envisioned as part of the design. As long as you send the cards through the border individually, it’s immune from rubber-hose cryptanalysis. And if you send them through the border on different days, then if they image the card on the first day, you just start over again with a new pair.
Border crossing was what sprang to mind with me, sure, if the authorities know you have something they will find it, if they stop your first mule you now know not to send a second with the other half of the data, make a new pair and start again, whereas if everything is on one card and “they” know what they’re looking for, consider it lost and your op over.
Could you perhaps image one of the cards, pad it with some junk, encrypt that again with a password you know, and store it as a .dat (or something) obscure, hidden away on a machine?
That’s part a, part b gets FedEx’d…. Un-junk at the other end and write card a…
No, I think I’m just back to security through obscurity here. Dang.
If they image the card on the first day and promptly send it on its way, you have no way of knowing they did it. Then when they get the second card it’s game over.
Orthrus is still neat, it just doesn’t solve this problem.
You can assume they didn’t image the card unless they took it away from you and then gave it back. If they did that, then you obviously must assume that they *totally* imaged it.
Oh, you mean taking it across the border in person. I assumed you meant mail.
… In the instant story, we’re talking about walking across a border with a card, not sending it through the mail. For sending it through the mail, there are such things as tamper-evident bags, but – again – your threat model has to account for whether your adversary is capable of evading whatever tamper-evident mechanism you use.
(Damnit, hit report. I’m joining the movement for sort the damn layout already!)
I was thinking one card in the mail, one (physically, or imaged and obfuscated onto some other storage medium) that is escorted by a human. Either card, in either scenario is pretty useless, and there is potentially less to link the two cards together by choosing different modes of transport.
I really think the key aspect to making this device work, is never really acknowledging any link between the two cards? Without this clue, the system would be fairly robust, so I guess the strength lies in keeping the two cards as separate as possible, and ultimately, having the data contained on each indistinguishable (from an analysis viewpoint) when compared to a single volume that has been encrypted via other means.
I’m no crypto guy, but would there be a way for the system to generate two cards that looked like any other encrypted SD card image?
I think what Tom is mentioning (assuming this comment lines up correctly) is the potential for steganography – that is, making the card look innocuous in addition to having it be what Orthrus is already. At present, there’s nothing in Orthrus to hide what it is. If you dump an individual card out, you get a header block and the rest of the card is all ciphertext. For my own use case, there was no need for the cards to look “innocent,” so I didn’t design that in. But that’s certainly something someone could add to the firmware if they wanted to fork it.
Indeed, that’s the concept that I believe makes this a viable approach, though had forgotten the name, thanks!
Is the key header also encryptped? It didn’t read that way? If not, it’s a pretty clear indication of what’s going on, now it’s published? Even without disclosure, it would still be a common… fingerprint (?) after a few samples?
The first 16 bytes of the key block are literally “OrthrusVolumeV01” So… no, I’m not trying to hide anything. :)
So exactly what are you trying to carry across the border???? I mean really, this is a fun mental exercise but it is getting to the delusional paranoid level. If the government is watching you then they will intercept anything you are sending. If they are not then it doesn’t matter. BTW if they image the card on the first day what makes you think you would know it was imaged? Are you going to keep going across the border until you get through? Or must maybe they will just arrest you and go to your home and grab everything?
Hoa about this as a way to get something across the border. Two Pi zero+ connected over wifi. The first person goes across and when they are on the other side they hit a button and the other Pi transmits it’s data while you are waiting in line and erases the file securely. A data forward pass if you will.
My actual example was source code for an analytical instrument, with significant IP value, while travelling to a country, whose border security agents had already made attempts to gain an understanding of the inner workings of said instrument.
Again, if the physical card leaves you at border control, you must assume it’s been imaged. I can’t really see the logic of the WiFi… We’re talking about the border on the other end of the trip, though admittedly, that wasn’t specified.
https://imgs.xkcd.com/comics/security.png
Rubber-hose cryptanalysis doesn’t work if you only have one card and it’s unnecessary if you have both.
Email/some file server?
There are times you don’t want to/can’t really trust the connection that you are using… I had to do a service call in China once. I didn’t even consider the impact of the Great Firewall before leaving. Not so much a trust issue, just access blocked for most of what I needed… Oops.
A while ago someone stored data on .. FTP Raid.
Confirmed! https://tahoe-lafs.org/trac/tahoe-lafs
LAFS stands for Least-Authority File Store, but they may have done it for the lafs too.
However it still has the same fundamental problem, it is just a redundant dicing and distribution method, there is no encrypting. But you could add a true encryption layer to it, then it would be very robust.
To me this is overly complex. I’d store OTP on one SD device and data XOR’ed with the OTP on the 2nd SD device. And the data is future protected even from quantum computing as long as the source of the OTP is from a true source of randomness (e.g. Shot noise, nuclear decay, … https://en.wikipedia.org/wiki/Hardware_random_number_generator#Quantum_random_properties ).
That would be neat too, but you would get half the storage space. Also, since it’s a message encrypted with a one-time pad, wouldn’t you have to completely rewrite both SD cards every time you change even one bit(!)?
Using one card as a one time pad, you’d have to update the matching sectors on both cards as a pair. Each bit on the OTP decrypts a matching bit in the message.
Talk is cheap. Orthrus is an appliance you can buy or build *today*.
You can do what “Truth” said today, and it is more secure.
Then he, or you, should stop wasting time here in the comments and go build one.
What, why would I want another one?
Then point us all to the hackaday.io project (or equivalent) of your obviously superior solution.
I apologise profusely for making a simple suggestion for a software change. I’ll get right on redesigning the hardware from scratch just for you.
You don’t need to. As I explained to… hieroglyph troll horse guy… the hardware has an RNG on it and two microSD card slots on it. If you don’t like AES XEX, you can write your own firmware for it.
The way you’re acting here says to me that you see what he’s saying, and on some level you agree. You don’t want to feel like you made a mistake by making a system that’s more complicated than necessary (or maybe you just take criticism poorly), so you started attacking the people who made the suggestion for not having actually done it. As an outsider looking in to this particular part of the comments, you’re coming across as very immature.
It’s a thing you see everywhere. It predates even the Internet, and probably goes back to the dawn of man. It’s been called Monday-morning-quarterbacking, but it’s just plain trolling. Someone builds something. Someone else looks at it and says, “That’s nothing. I could do better” seemingly for no purpose other than to try to take the wind out of the first person’s sail.
I built it because it solves an actual problem that I needed to solve. I shared it because I envisioned other problems that people might have that it could also solve.
If it’s cryptographically weak, then I invite criticism. If you can do it another way, then I invite you to share your method with the rest of us because that’s WHY WE’RE HERE. If it doesn’t solve a problem for you, then you need to realize that your set of problems are not the same as everyone else’s. If you just want to rile other people up by insulting their work, then you’re a terrible human being.
Yep, I wondered how long it would take for somebody to point that out, you can have a card already full of random numbers and replace it with data as it is transferred then XOR decoded with the same blocks. Then you are just sending noise, but as I already pointed out, it is still only secure so long as the data on the receiving device did not get copied at some point when it was originally sent to it’s destination. It is just a one time pad method, a very old idea.
If you want to create such a device, you can use the Orthrus hardware as a platform. It has an avalanche transistor RNG on it and two microSD card slots and the whole thing is open hardware. Go for it.
I don’t need the RNG on the device, that just give the crackers clues as to potential weaknesses. The rest can be done with an ATTiny and an SD card.
What’s stopping you, then? Tick tock.
XOR FS implemented under fuse is a very old thing. FFS try more X and less spurt in your posts.
FUSE implies that you’re using a *nix machine to do the job. It’s a lot harder to insure the security of such a system than the single small microcontroller and 10K of code it runs.
Nope, the XOR system lets the two functions be completely separate. I just used that as an example of how old and easy it is to do, something you can look up and confirm. Get over it.
You know, I am absolutely positive that one of your ancestors sat on his ass outside Gutenberg’s workshop telling passers-by how much *nicer* the books looked when they were copied out by hand by monks.
This conversation ends now.
You are pathetic, an adult would accept that they were getting around in a fog of naivety and then thank the people that helped them get in touch with reality. You are the one with the insecure and backward ideas.
Furthermore no matter how secure a system is if it gets the attention of certain parties (at border crossings) you are going to have to give them access or be punished for refusing to do so, that is yet another facet of your naivety.
As I mentioned above, filling one card with a OTP is just as secure/insecure as the current solution (which is effectively storing half of the OTP on each card with the opposite half of the data on the other). You still have 2 cards to transfer somehow, and once you use a OTP to encrypt your data, its no longer “noise”, it becomes data itself… also if you’re saying its more secure because it “looks like noise” to an attacker, let me remind you that a good encryption implementation will make the cyphertext indistinguishable from random noise.
No I’m saying it is noise, that is the magic of XOR, and I am saying that you only need to move one card as both ends have the other “pad”. Old-school and unbreakable, but they still can break your arms if you don’t help them get the data off the card if you get noticed with it.
Aaaand, now I gotta write a linux filesystem driver for this to do it with a pair, or triple, of usb sticks!
Chaos, panic, disorder. My job here is done….
The problem with using *nix is that it’s a lot harder to insure the security of your *nix host than it is a microcontroller running a relatively small firmware load. Not impossible, certainly, but it’s a bigger job.
Or perhaps even a C-17 full of SD drives, perhaps it has already been done.
A station wagon full of encrypted tapes is quite secure. This is a standard feature of almost any commercial backup program and drives have hardware encryption acceleration built in.
You store the encryption key on an HSM.
Done.
A HSM is the same as any other pie shared key. All of the data is in the station wagon, so there’s a non zero chance that an attack on the crypto protecting the tapes will succeed in liberating all the data.
nsayer’s project insures that the interception of only one card yields no useful data.
And if that station wagon is a 2007 Mercedes Benz R63 (with the fragile head bolts replaced) and traffic laws are ignored, that can amount to some really high bandwidth data transfer.
And then there’s this method. https://www.youtube.com/watch?v=EEUKUvEU1N8
For the border crossing use case, I’d be concerned that a card in an unrecognized format would stick out.
What if both cards were initialized with a bunch of photos in a typical digital camera filesystem and structure, and the data encoded across all the files steganographically? You could have a hash function that maps block addresses of the encrypted volume to a particular JPEG in the filesystem. That way a cursory search of the card would be less likely to result in $5 wrench cryptanalysis.
Adding steganographic qualities to Orthrus is certainly something someone could do. I didn’t need it for my particular use case, so I didn’t code for it, that’s all. My use case is more about two-man control over a data set, so it’s not like those involved don’t *know* what’s going on.
Dual partition a pair of cards so that when plugged into any computer they appear as normal 8 gig cards. Ordinary software partitioning wouldn’t work for anyone bright enough to have a look at the cards with the disk utilities in Windows, OSX or Linux.
To really hide the second partition would involve reprogramming the cards’ controllers to show less than real capacity – a reverse of how cheap cards get reprogrammed to show more than real capacity.
To read the striped data the reader would need to be programmed to look for the first block in a different location and would ignore the partition full of vacation snaps and pics of the grandkids.
Of course the label on the card would need changed to the fake capacity.
Again, everything depends on the sophistication of your threat model, but you probably don’t need to go to that much trouble. It’s probably enough for border guards to create a hidden file on an ordinary volume and have Orthrus create its virtual volume from that file.
Heck, I strongly suspect it’s enough for most border guards to just have the Orthrus card (as it is today) be one of two dozen cards, the rest of which *are* filled with vacation snaps.
But, as I’ve consistently said, everything depends entirely on your use case and threat model.
Hide the code in the firmware of the camera, Its microcontroller can be used to encrypt and decrypt.
or just code a version of Orthrus to use the available free space not already take up by photos. Include a checksum and you’ll know if someone stuck it in a PC along the way because that hidden ini file or any other innocent and automatic Windoze write to the disk will corrupt the free space and break the checksum.
A better solution would be to write a little program to encrypt the data and than interleave it between multiple devices. The interleave need not be one here and one there. That could be skewed. Also junk data could be interjected every so often. Even if both devices are intercepted it would be a nearly impossible to resurrect the original encrypted file. Than you still need to deal with whatever encryption you used on top of it.
Now, for the mathematically inclined propeller heads out there. If you took the file and encrypted it multiple times, I know that you could decrypt it with the correct keys in the proper order and get the original file back, but given the resources, would there also be a method of one decryption breaking all the underlying layers at once?
It is not clear what situation is to be covered. Is it for when you have data in location A where you can be sure it is safe and the issue is to get it to location B, where it can be kept safe (and used), via a route which may not be safe? If location A or B are not safe, then all bets are off. For bounded amounts of data, a one time pad is very safe for sending data so long as you can safely transmit the OTP. Spies have used OTPs for a long time. Of course, there is always some scenario in which the OTP is intercepted but there are options to significantly reduce that risk. The main thing is to be able to identify that it has been intercepted. If you physically carries the OTP, you should at least be able to determine whether anyone else has had access to it. You can use multiple separate OTPs and multiple tries until you can be sure one OTP not been compromised. The real data is then encrypted with the safe OTP and transmitted using any convenient means, even publically broadcast. For this to work, you need to either be able to store the OTP safely at location B while you return to send the data or you need a trusted partner either to transport the OTP or to encrypt the data based on a preassigned coded message from you to say which version to use. The nice thing is that the software to OTP encrypt is simple and even without true random data for the OTP you can be quite safe. In the past people used randomly chosen passages from books but images which are statistically reasonably random would work quite well and not be suspicious when examined. No method is perfect, though.
The actual use case for me is two-man control. The two cards are stored in tamper-evident bags in two safes. Whenever they come out of the safes, they’re always in the custody of two different people. The concept allows us to be able to declare that the data on the drive is only ever available in contexts where multiple people can attest to exactly how it was used. Our threat model is such that the tamper-evident bags and separate storage are sufficient. If one tamper-evident bag shows signs of tampering, then we start over, but as long as the other bag is intact, we know no one has the data.
There are trivial methods for splitting an encryption key into pieces so both pieces are needed to decode a message. Or a bit more complex, N subkeys from a set on M are needed to recover the message.
Yeah. I’m using one. :)
I’m familiar with key sharding, but didn’t/don’t need it for my use case. There’s kind of a corollary to Occam’s Razor – there are always more complicated solutions to a problem, but that doesn’t necessarily make them better suited to your needs.
* two gpg smart cards with seperate keys
* tar your data
* encrypt it with pgp/gpg key of the airgapped machine
* sign it with your own
* ??? (transport over insecure sneakernet)
* check signature on the airgapped machine
* decrypt it
* profit
For the use case for which I designed Orthrus, it’s unacceptable for one person to have sole custody of the data “in transit” (in our case to and from long-term storage). And the air-gapped machine is not capable of storing a secret. If it were, then we’d have to treat it carefully. Instead, we insure that it has no storage medium on it at all – it boots from a live CD with the tools we need and has nothing but RAM installed. We used to use a barcode reader to reconstitute the secret stuff from paper shards, with procedures in place so that nobody ever saw more than one of the pieces of paper, but that process, while secure, is cumbersome.
“The design for this device is based around the ATXMega32A4U. It’s pretty much what you would expect from an ATMega”
I beg to differ. The peripherals in the ‘xmega32A4U are very advanced compared to the popular ‘mega328. This actually puts them in a weird market position, as you can get an ARM micro with same peripherals and probably faster for about the same money or a bit less.
I concur. This project was my introduction to the XMega, and it’s quite nice. It’s too bad that the original crypto design that used AES Counter mode wasn’t sufficiently strong, as I got the DMA and AES systems to work together to precalculate the crypto stream for each block. The result of that was that the crypto had literally no performance impact on throughput. Unfortunately, that design had some cryptographic weaknesses and so I had to make a hard choice between performance and cryptographic rigor, and the latter won.
So, software AES?
The xmegas do indeed have some flaws. I never got to the AES, but the ADC….that was fun. I moved on to the SAMD21 now where I haven’t found any issues yet. It is missing some things from the xmega, but it fits better for me.
No, it’s still hardware AES. It’s just upload-wait-download rather than being done with DMA in the background. The unfortunate part is that the wait in there is largely unavoidable because unlike the Counter mode version, you need the plaintext before you can crank the organ.
this is right out of the movies, “Listen here commander Bond, you must honey trap the courier’s and copy the keys without them knowing”
I was going to say “Mission: Impossible,” but yeah. The takeaway from that TV/movie series is to always correctly estimate your threat model.
@nsayer
I do not have an account with hackaday thus I cannot comment on your IO project page.
I had a look at your cracking challenge and it looks strong. However Bruce Schneier had wriiten about crypto contests and he had mentioned that they are unreliable for testing security. “https://www.schneier.com/crypto-gram/archives/1998/1215.html#contests”
Is the Java code in the challenge actually used in Orthrus firmware? If not, the challenge is useless as your actual code may have a security flaw.
Do you have protection against side-channel attacks and EMF leaks? No proper EMF shielding may allow a sniffer nearby to eavesdrop on your secret information bypassing your encryption and air gap.
Although you have written about how you encrypt the data in the 2 SD cards, you do not have details about how another computer can read and write data from Orthrus.
I assume the PC will treat Orthrus as a removeable drive and Orthrus act as raid-0 controller for the SD cards. A bug in the raid code may cause the SD cards to be corrupted making it is useless as a data store.
Overall the idea sounds good but I feel the implementation details can make or break your project. A risk I find unacceptable is that if the bad guys get hold of both cards, they have access to the information. I fell you discount the ability of nation states to intercept both cards.
It may be better to have a third courier which carries the password in his head to unlock both cards. If all three couriers are caught, we hope that the third courier can “forget” the password under duress.