A standard for transfering Files between airgapped units over a simplex transmission agnostic to the medium, transfer speed and distribution network.
I wanted to find a sleek and secure way to exchange private keys securely and conveniently between devices that only have a cameras and screens.
- Said Keys exceeded the size of a QR Code, so I had to manually split and merge them, which was annoying me into "weapons-grade boredom".
So I started this here...
Not everything can or should be transfered in the open, or at least not in a way that makes it trivial to eavesdrop and/or manipulate data being transfered.
- This includes public and espechally private keys in asymetric encryption systems, like OpenPGP, GnuPG or similar.
To prevent "Juice Jacking" and other methods of attacks onto systems by physically connecting data lines to them.
- This may not prevent an attacker from tampering with the hardware and brute-forcing their way by fuzzing every pin they can find if not blatantly sabotage hardware with tools but it should not be possible to crack a system without violating the physical integrity of it's casing and soldering stuff onto the mainboard.
- Attacks like the Reset Glitch Hack are out-of-scope.
Thus Over-The-Air Updates are just not possible!
It may sometimes not feasible or desireable to transmit on certain bands, as they may suffer from overuseage if not malicious interference of the spectrum as DoS or DDoS attack.
- In many cases, this may even be illegal as per protocol.
- This includes TEMPEST - style shielded systems that should neither be detected in operation nor eavesdropped upon.
Most existing Protocols don't handle simplex transmissions at all or very poorly.
Espechally for Commercial Off-The-Shelf (COTS) Hardware and Software outside the Hamradio Space there is significant lack of solutions that are easy to use even by "Tech Illterates".
- Bluetooth and WiFi can be trivially jammed with vry few countermeasures to prevent deauthentification attacks even being standardized.
- Implementation of said protections is costly and time consuming and not feasible in the field.
- Li-Fi, RONJA, IrDA and other (in)visible light communication systems all are bidirectional protocols and require both handshakes and are not easy to replay even at absurdly low baud rates.
- Consumer Infrared may be sufficient for sending short commands via line of sight where repeating these is not an issue and security is not a concern but at most an annoyance when attacked with Tools like the Flipper Zero.
- USB is unfixably insecure and BadUSB attacks are rampant and basically impossile to prevent or counteract in any meaningful way.
- Thus USB flashdrives and any other removeable media like MicroSD cards cannot be trusted.
- That being said, encrypted Removeable Media are good at storing huge amounts of data, but aside from Linux supporting a eCryptFS and dm-crypt there are hardly any solutions that work closs-platform aside from VeraCrypt.
- These are all great for amounts of data that go into the Megabytes and way beyond, but not for smaller files.
- A solution that works as-easy as QR-Codes yet allows more data to be transfered is not only desireable but necessary.
- These are all great for amounts of data that go into the Megabytes and way beyond, but not for smaller files.
The ATP Standard aims to be easy to implement and use.
The data to be tansmitted is to be collected in a container [this may be a folder or tar archive].
The Container is then to be compressed if desired.
- Compression is optional and can be omnitted.
- Compression should be omnitted if the output is "not smaller" in that it could save any space in the sense of outputting less "splinters".
The optionally compressed Container can also be encrypted.
- Encryption is optional and can be omnitted.
- Encryption can be handled externally by tools like AESCrypt, age, enc, OpenSSL, GnuPG - regardless if Public-Private Keys or symmetric keys are being used.
The Container is then checksummed.
- Checksumming can, but should not be omnitted.
- A secure algorithm like SHA3-512 is recommended.
A Header is being used to communicate the essential parameters, including the following:
- Compression [if used, which type]
- Encryption [if used, which type]
- Checksum [if used]
- Total Size of the Container in bytes
- Number of Splinters [as of now, a maximum of 2¹⁶-1 = 65535 is specified]
- This is considered sufficient for the current use-case, as this allows up to 193.524.855 bytes or ~ 184,56 MB of storage just by using QR Codes of 2.953 bytes each.
- Under ideal constellations [60fps] this yields a gross "transfer rate" of ~173 kB/s
- For comparison: A 2880 kB 3,5" FDD can reach 1.000 kbit/s under ideal conditions and a 1x CD-ROM drive reaches 150 kbit/s.
- It would take 18 minutes and 12,27 seconds to do so.
- Under ideal constellations [60fps] this yields a gross "transfer rate" of ~173 kB/s
- In practical use, it's expected that rarely more than a few dozen or hundred will be needed to transfer said data.
- The first splinter must contain the header.
- This is considered sufficient for the current use-case, as this allows up to 193.524.855 bytes or ~ 184,56 MB of storage just by using QR Codes of 2.953 bytes each.
- Size of the Splits [as of now, a maximum of 2¹⁶-1 = 65535 bytes is specified.]
- Unix Timestamp of Creation [can be omnitted.]
- Checksum of the header [if used, which type]
- Adler-32 is recommended.
Optional Link to a "How To Decode?" - Tutorial if need be.
This should help uninitiated people to actually recieve and decode it.
To fit within the constraints of the medium used to transfer, the [optionally compressed] container is being split-to-size based off the parameters given.
The Splitted Parts [which may be called splinters] will then be stored and if necessary, converted into the format that is desireable for transfer.
Since the System is designed to do Simplex Data Transfers, it can be be retransfered or time-shifted as desired.
Basically the same prcess as Encoding in reverse.
- Can you fit a whole game into a QR code?, MattKC et. al.
- Using a QR Code to distribute a Win32 executeable of Snake which had to fit the 2.953 bytes size limit of it.
In fact, one could just take a file, encode it in as Base64 as per RFC 4648 and spit it out as QR Code.
- This also means one could manually split and merge larger files.
- In fact, automating that away is the reason this was started in the first place.
The name is chosen as a resemblance to FTP as it aims at similar goals.
- AFTP is a closed-source protocol for making FTP faster aimed to circumvent the TCP Slow Start Problem on high-latency links like SATCOM.
- There also was an FTP Client for Android named aFTP.
Since it not only can transfer Files but anything, ATP seemed to be a better naming for it.
Archive Formats like RAR, BZip2 and 7zip's 7z Format among others do natively support splitting of files, something TAR, PAX don't.
- Of course there are multiple ways to do that on the command line, but that's not an easy solution and does require quite a good knowledge on how to do this.
- It's also not trivial to reassemble the split archives unless natively supported by said application.
- It's quite cumbersome for a lot of work and not easy to do by Tech-Illiterates.
- Whilst solutions like PeaZip support cascaded encryption, they are not multi-platform.
- Updates for REINER SCR Authenticator Devices are being distributed via YouTube Videos
- These contain a series of QR Codes being shown multiple times to be scanned by the device and reassebled into a firmware update file.
- This allows for updating the device in a secure manner by denying any opportunity for Juice Jacking and keeping said authenticator as an encapsulated decice and thus not needing to break any anti-tampering seals.
- It is very likely these basically use a proprietary Imprementation of ATP that predates it with integrity checking, digital signatures and potentially even encryption to prevent malicious updates to be distributed and loaded.
- At least that's what I hope for...
- These contain a series of QR Codes being shown multiple times to be scanned by the device and reassebled into a firmware update file.
Which are a patented Secure QR Codes that are encrypted in part or whole.
- These aim at the same, however being a patented and proprietary standard, to avoid infringement the ATP Standard aims to be more general and media-agnostic.
Which is a PSD2-compliant TAN System designed to authenticate Bank Transactions.
- It typically uses a 25x25 pixel grid which has either red, green, blue or no [white] dots and can encode around 100 Bytes od Data.
- It is being used with either Apps or dedicaded devices to Authorize Transactions.