Setting up PGP

[Karl]

Hey, Stefan =)  Confused novel below.

On 10/12/20, Stefan Claas <sac at 300baud.de> wrote:
>> The next step after getting a reasonable airgapped device, maybe a pi
>> zero, and ideally keeping it isolated, would be to install gnupg on
>> it.  Maybe in a forthcoming email!
>
> GnuPG should be already installed with Linux (Raspberian OS etc.). The

What Stefan implies here is the best way, and he sounds more with it
than me a little.  If you can find Linux already installed it reduces
how much you need to transfer data in and out of the device, which is
a huge win because as I said anything you put in it could have digital
coronavirus, the one that takes over the system and puts somebody else
secretly in control.  It's not always possible to get linux
presupplied, and I haven't been to "microcenter" myself, but if your
store sells linux media this helps your situation.

Downloading linux over the internet is more dangerous, because as we
said your internet-connected device is likely compromised; for example
debian had a system-wide packaging compromise some years ago that they
did not handle well, and has had mysterious disappearing of their
tools for verifying system integrity after install; windows doesn't
even let its own users legitimately look inside the hood of the system
let alone demonstrating that it could be hard for others to.

> thing I would like ask you, how would you communicate securely with your
> air-gapped device?

Let's talk about that a bit.  I hadn't quite worried about talking
about it yet, because [s/I'm only free to do this stuff now if I talk
about in public/I hadn't figured out what to say yet/].  But like you,
I've pursued this in the past, and have some things to work off of.

> What I did in the past was to install on the online device and offline
> device the free (cross-platform) software CoolTerm and I connected both
> devices with an FTDI USB to USB cable, so that I could do serial
> communications
> and was also able to see how many bytes (from a PGP message) was
> transfered.
>
> Another approach I am currently playing with is to play with NFC tags and
> a reader/writer device, which can be used offline as well.

I don't know why you would ever consider an NFC radio secure, where
did you get this idea?  I'm probably getting into a state of mind
where I assume I know more than you (when I might not) because you
mentioned plugging a radio into an airgapped device and using it to
communicate.  Really, it's possible to make that very secure, but with
the radio chip likely being closed source, it doesn't sound easy to my
kinda limited mind.

I'm inferring by FTDI USB to USB cable, you mean a serial cable with
FTDI USB serial converters (which I've had occasion to run into but
don't know well) at both ends.  That sounds pretty reasonable and
shows you have a clue; i don't know whether people still consider
systems to be airgapped when they are networked with a serial cable,
or not.  If we fast forward to emissions a bit, a serial cable is a
long wire, so it's going to broadcast the stuff transmitted over it
like an antenna, and pick up electromagnetic effects like one too.

I don't know a lot about FTDI converters, but I know that most things
you buy from a corporation are not secure by default.  My biggest
poorly-informed worry is that voltage glitching from the connected
device could be used to compromise the 'airgapped' device in some
obscure way.  Additionally it can be hard to find FTDI converters
locally.  Sounds pretty airgapped in this day and age, though.

While tumbling through this ordeal I once made this software, which is
a small program to communicate ascii text by bit-banging one or two
wire connections:
https://github.com/xloem/openemissions/tree/master/tincanterm

One of the best solutions for low-latency communication would seem to
me to be writing your own bit-banging or communication software on the
fresh linux installation, so that no installation of new software is
needed, preferably using a visual or audio connection so that voltage
glitching is impossible, although these channels can still be high
bandwidth unintentionally.  But if you understand the communication
system and security concerns in depth, go right ahead with any of it.

Something I value is very high latency communications.  For example,
using CDRs was a very secure thing that corporate progress has almost
done away with.  Burn your information to a CD, then load it on
another computer.  The CD has no microchips, the information is there
for easy review, it doesn't alter the voltage between any electrical
terminals on your system, and if you don't reuse cds then even if your
airgapped system is compromised, there is no obviously related way to
quickly send reply messages back to the system to alter its behavior.
High latency is good.  Only communicating when the user tells it to is
crucial.

Here's a piece of software I tried to make for transmitting QR codes:
https://github.com/xloem/qrstream

But yeah, I guess I'd investigate the system, see what the best thing
I could do with the resources reasonably available to me was, and go
from there.  If you got a raspberry pi zero you might be able to also
get an LED and a photocell to communicate using visible flashes of
light, that you can see and review (since if you want something
private it should already be encrypted before it leaves) via its GPIO
pins.  If I want quick and easy I'd probably just use a usb key, an
ethernet cable that's only plugged in for communications or an sd
card, and figure that even though it is easy to hide additional
traffic on the medium, I'm still doing so much more than anybody else
to defend my communications that the very act of doing so will help
things a lot.

If I write a followup to the raspberry pi example I'll pick something
that works for my immediate situation with say a pi, and maybe make
jokes of frustration about the issues with it.

I'm guess that the key is not to be hyper secure but to support people
being increasingly hyper secure.  If we can pull that off, it'll be
easy to be hyper secure because others will be sharing resources for
it.

Like Stefan says, it's incredibly valuable to monitor the
communications that enter and leave the system, to verify they are
what you expect.

This leaves emissions out, which are roughly ways of communicating
between systems that are not actually connected, and these ways can be
automated and used by viruses, and emissions are difficult to manage
mostly because all the work on managing them is classified and none of
the commercial products have any serious protections in place, but we
can fix that.

Don't freakin' censor the stolen-from-hackers-and-classified security
information, internet!

>
> Regards
> Stefan
>
>
> --
> NaClbox: cc5c5f846c661343745772156a7751a5eb34d3e83d84b7d6884e507e105fd675
>   The computer helps us to solve problems, we did not have without him.
>

Maybe I'll send an e-mail on googling what naclbox is.