[Pki-clean-room-devel] Contributing docs and translation

[Stephan Beck]

Hi Daniel,

Daniel Pocock:
> 
> 
> On 15/10/16 15:49, Stephan Beck wrote:
[...]
> 
> As you can see from the wiki[1], I have been trying to document a
> workflow, but it is not quite complete.  Even if you don't know how to
> write a program to implement the workflow, what do you think about the
> steps I've outlined?
> 
> Another related topic is the way that we format and label the
> filesystems used for private keys and for transporting keys, the wiki
> also mentions that but it would be good to make a more rigid
> specification.  The scripts I already created[2] simply use a volume
> label to distinguish which devices contain the private master key.
> 
> Before creating a full user interface, it will also be necessary to
> create some more helper scripts, like those I already created, for
> doing low-level tasks, e.g. managing the filesystems.  If you are
> familiar with bash or Python scripting you are very welcome to
> contribute code like that too.

As to the workflow sketch (just some thoughts):
1) using a kernel compiled without networking is a good solution for
disabling all networking, as you point out even before the proper
#workflow section. No need to worry about any interface that might not
be completely disabled or might be prone to being enabled by a
(possible) remote attacker. The best solution to an air-gapped key
generation and management machine appears to be a machine with
networking disabled by hardware design, .i.e. no network adapter at all,
no bluetooth stacks, nothing. On the other hand, and taking into
consideration that the clean room DVD addresses not only developers and
geeks but virtually any type of user, that leaves the risk of an
important air-gap pre-requirement being subject to the decision of the
user; he/she is "responsible" for removing any network device or for
buying a computer that complies with that requirement by design (if
there is such), or he/she may as well disregard, forget, not worry to
much about it.

A persona style user modeling, describing different types of user, each
with his own (most probable) use case, might shed some light on the
question whether it should be up to the user to meet this requirement.
In one question: do we believe that there is a type of (defined) user
that is likely to disregard or simply be unable to comply with the "Have
your computer's network devices removed" requirement or not? If yes, the
following solution appears to be the best one in terms of trading off
security and liberty (of not complying).
Using a kernel compiled without any type of network support has this
requirement being met (already) on the "upstream" side, so in terms of
ensuring that "no networking (i.e. no interference) will be possible" it
might be an even better solution. Particularly, in the case of the
chipsets with embedded network adapters you mention. What do you think?

I see that in (1) the guardianproject's approach seems to imply using
keyserver connection only, via TAILS, but they do not particularly
mention whether this is an action to be carried out on another,
networked machine, or not. Probably. I am not quite sure whether their
Clean Room solution (a live-DVD, a bootable stick?) has a kind of menu
for selecting either (what they call) NEW SETUP (off-line) or an item
like WORK WITH EXISTING KEYS (including limited connectivity for key
publishing) on booting up, or if they are talking about separate
processes on different machines.


As to the printer setup for printing secret key and revocation
certificate: there are multi-functional printing/scanning/faxing devices
equipped with WLAN adapters, so it would be fine to include at least a
note recommending not to use those devices without having networking
disabled.

#First time workflow:
The guardianproject's team wonders if they should include support for
migrating from an existing key (1), as this is seen as contradictory
with respect to the clean room concept. How do we think about that?

How about including X509 certificates generation functionality via gpgsm
or is it not desirable? I'd say, yes.

I am not quite sure if the attempts to create new terms for "key" are
desirable (1). Are they? Would another term/other terms really foster
mass usage of encrypted communications (which would be a legitimate
reason for shifting away from "key") more than, let's say, a good UI
would (have the potential to)?

~/.gnupg/gpg.conf
--personal-cipher-preferences
You do not list the ECDSA, ECC ciphers. I guess, that because of gpg's
version used. Is there a chance to have these algorithms included in the
OpenPGPCleanRoom-DVD?

As to the formatting and labelling of the file system I haven't made up
my mind yet, I'll take a look. btrfs as filesystem appears to be a good
solution.

I looked at your scripts, and as far as scripting skills are concerned,
I'd be keen on improving my fairly limited skills. I use the command
line a lot, but only played with both, bash and python, and did not get
very far (just about the basics). It's only that I don't know if such a
project would be the right place to study and practice, as other people
do a quicker job (what's your timeline? :-). Well, if I was to have the
choice, I'd go for python3.


Well, just some thoughts and comments for now likely to be completed in
the next days.

Regards

Stephan



(1) https://dev.guardianproject.info/projects/psst/wiki/CleanRoom