Policy-Discussion

[Javier Fernandez <javier.fernandez AT cacert.org>]

Ian G escribió:
> Hi Faramir,
> 
> How about we take this off the board list and over to the software devel
> list ... where there might be more interest and understanding?

  Good idea. But also, I think if we can't find a reliable tool already
created, we should not ask our developers to create it, since they are
already busy with other things...

  I'll send this message with copy to Policy list, since it seems it has
to do with security policy?


>>>> On 01/05/2010 07:52 PM, Faramir wrote:
>>>>>     By the way, what about using a shared secret scheme (like Shamir
>>>>> SSS)?
>>>>
>>>> Might help for those unfamiliar:
>>>>
>>>> http://point-at-infinity.org/ssss/demo.html
>>>
>>>
>>> :-)  Let me put it this way:  if you guys can design the procedure, then
>>> maybe!
>>
>>    Well, first we would need to know what is the current procedure with
>> the envelope, in order to compare and know if SSSS would be an
>> improvement or not. Maybe it can be used as a complement.
> 
> 
> Current procedure is documented in SM4.3.7:
> https://wiki.cacert.org/SecurityManual#Key_Management

  Hummm... If I understood it right, Teus can, at any time, open the
envelopes and get access to the passwords and keys, right? Maybe that
can be improved (I don't distrust Teus, it's just I think it is a bit
risky if a burglar gets the envelopes, or the Notary decides to put the
envelopes in the regular garbage can).

  But I also saw this https://wiki.cacert.org/Roots/EscrowAndRecovery
and I am not really sure about how was it done.

   Anyway, lets imagine the following: the encrypted files are stored in
an envelope, but instead of storing the passphrase in another envelope,
the passphrase is split using an N of M scheme (with SSSS), and each
member of the board receives an envelope with a piece of the passphrase.
Even if the Notary drops the envelope to the trash can, since the
passphrase is not included, nobody can decrypt the files. The pieces of
the passphrase don't need to be in a digital support, they can be
printed in paper, which is the most time-proof support media available.
Also, it's easy to safely destroy a printed copy of the passphrase piece.


...
>   "Finally, it is necessary, given the circumstances that command
>    its application, that the system be easy to use, requiring
>    neither mental strain nor the knowledge of a long series of
>    rules to observe."

   Right, but the usage of SSSS is really simple... maybe the whole
procedure would be a bit more complicate.

>>> So, for my money, here's the question:  can you design it such that it
>>> is more reliable than a piece of paper?

    Now I think about it, the passphrase shares created with SSSS can be
printed in pieces of paper. They are short, so it would not be hard to
type them into the computer to recover the secret.

Example:
1-851ee8f37a7028ddcde0322c0a82cb
2-d52e7971b11b1cf124d37734fa2ec4
3-b8260ac3f6fb8166a5dcaa344deb8b
4-0ec74a7029adac6d341a5778901a0b
5-63cf39c26e4d31fab5158a7827df56


> If secure means "cannot be recovered by people with n-1 shares" then OK.
>  But note that I am suggesting a wider definition that includes the
> overall security delivered to the community.

  I suppose the biggest risk would be if SSSS would become unavailable...

> Consider it to be the denial of service of cryptography.  If the system

  Right, currently I think the most pressing issue with the envelope
procedure, is the person having the envelope can become unavailable...

>>    About reliability: if one person has one envelope, that person has
>> full power (which may be good or not so good), but also means that
>> person must be really careful when crossing the streets, unless there is
>> another person with another envelope, and that second person would have
>> full power too.
> 
> 
> Right.  With multiple full envelopes, the reliability of delivery of the
> secret when needed goes right up to near 100%.  But the reliability of
> losing the secret to someone else goes up too.
> 
> So the trick is, can we keep the rate of good delivery up while keeping
> the rate of bad delivery down?

  Yes, we can keep using that very important envelope (encrypted files
plus passphrases), but we can also create a secondary set of envelopes
with the encrypted files, but without the passphrase required to decrypt
them. The passphrase would be split in an n/m scheme...

>>    Now lets think about this other scenario: there are 5 persons, each
>> one keeping a different (unique) piece of the secret. 3 pieces are
>> required to recover the secret, so, nobody has full power, and 2 persons
>> can be abducted by UFOs without affecting the reliability of the secret.
>>    Of course, when there is a need to recover the secret, 2 persons must
>> send their pieces to a third one, who would then have full power, but
>> that wouldn't be more risky than having 1 envelope, plus the persons
>> would know they have sent the pieces and the person is now capable of
>> restoring the secret.
> 
> 
> OK, 3 of 5.  Now look at the recent history of the board of CAcert, and
> consider that the AGM is coming up.  How much work is required to hand
> over those shares, and what is the likelihood that this work will be done?

  I think it would not be worse than the work needed to handover the
"full power" envelope.

  But I know this would require a lot more thinking about how can this fail.

...
> ( Also consider how the shares are delivered:  paper form?  or digital
> form?  How does this change the rates? )

  I'm not sure, that is a matter of security policy. The shares are
short enough to be printed and typed, and of course, they can be kept in
digital media too.

>>    Disadvantage: while we can always open an envelope, to recover a
>> shared secret we need the same software used to create it (different
>> implementations of Shamir's Shared Secret Scheme work in different
>> ways), but as long as the source code is known, it is unlikely that
>> software would become unavailable.
> 
> 
> Ah.  So we need to factor in something like, our Support team must
> support a piece of software on the various laptops of our board team. So
> that means:  OSX, Linux, Vista, W7, ...

  I tested the web demo at http://point-at-infinity.org/ssss/demo.html
for compatibility with the software in ubuntu, and they are
compatible... so maybe we can implement a copy of the demo website, but
using https instead of http, then people would be able to use the
software without the need to have ubuntu in their machines... but I
don't know if that would be secure enough.

>>    Implementations: there is a package available for Ubuntu, and an
>> implementation available for windows (I tested them, and shares created
>> in windows can be restored in ubuntu, but shares created in ubuntu can't
>> be recovered in windows. They are opensource so somebody -not me- can
>> try to fix that compatibility issue).
> 
> 
> If GPG has it, then we have a chance.  I'm curious ... doesn't PGP have
> it?  Why not GPG?

  As far as I know, PGP has an implementation of Shared Secret (I'm not
sure if it's Shamir's or another scheme), but I am not sure if it is
available in unlicenced version of PGP.
  GPG doesn't have any implementation of Shared Secret, because the
developers think it is a tool not related to OpenPGP, so if you need it,
you can find it elsewhere. Like PGP Disk Encryption, GPG doesn't have
the equivalent tool, but people can use Truecrypt instead. The problem
is Truecrypt is available for windows, MacOS and Linux, while I could
never find a SSSS tool fully multi-platform... maybe I should write at
GPG list and beg if they can port SSSS from ubuntu to windows...

   Some months ago, I sent an email to the person that ported SSSS to
windows, and told him about the compatibility issue. He answered he
didn't develop a current version due to lack of interest in the tool (if
there are not users, why to bother in developing it?). But he said maybe
he will take a look at it in future (or that is what I understood, maybe
I misunderstood him).

>>    So, maybe it is a good idea to keep an envelope, but also to have a
>> backup in the form of a shared secret.
> 
> 
> That sounds like a good idea!  Having it on paper as well as digital is
> much more reliable.

  By the way, I saw at https://wiki.cacert.org/Roots/EscrowAndRecovery
some talk about splitting a key, and about N/M scheme, so the idea is
not new, only the tool is different.

   Best Regards