Project

General

Profile

Feature #9802

Design a process to deal with signing key compromise

Added by BitingBird over 4 years ago. Updated about 2 months ago.

Status:
Confirmed
Priority:
Elevated
Assignee:
Category:
-
Target version:
-
Start date:
07/24/2015
Due date:
% Done:

20%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:

Description

Team: intrigeri, jvoisin, sajolida


Related issues

Blocked by Tails - Feature #15097: Risk analysis on our infrastructure Confirmed 12/23/2017

History

#1 Updated by sajolida over 4 years ago

  • Assignee set to intrigeri

On our roadmap for 2016, assigning this temporarily for intrigeri who was the first in the list of assignees :) What's the next step?

#2 Updated by intrigeri over 4 years ago

  • Type of work changed from Communicate to Research

What's the next step?

My team-mate and I meeting to organize this work.

#3 Updated by sajolida over 4 years ago

  • Tracker changed from Bug to Feature
  • Description updated (diff)
  • Target version set to 2016

#4 Updated by intrigeri about 4 years ago

  • Assignee changed from intrigeri to jvoisin
  • QA Check set to Info Needed

I think we need to spend a solid 4 hours work session (ideally face to face, worst case VoIP) on this to draft something good, and then we can submit it for review to our team-mates, adjust according to feedback, and finally write whatever documentation and tools are needed. jvoisin, looks like a good plan to you?

I think I can schedule time to work on this at the end of 2016Q2, or early in 2016Q3. Would that work for you as a tentative timeline?

#5 Updated by jvoisin about 4 years ago

Yup, no problem.

#7 Updated by intrigeri almost 4 years ago

Proposed a date.

#8 Updated by intrigeri over 3 years ago

  • Status changed from Confirmed to In Progress
  • Assignee changed from jvoisin to intrigeri
  • % Done changed from 0 to 10
  • QA Check deleted (Info Needed)

Three of us (co6, jvoisin and I) worked on this. Next step is that I type my notes and submit for review. We had no time to look into #7700 though.

#9 Updated by intrigeri about 3 years ago

  • % Done changed from 10 to 20

It's now in summit-2016.git:notes/signing_keys_compromission.md, and I/we should check what we want to do with it.

#10 Updated by jvoisin almost 3 years ago

I think that the scheme is currently being deployed, can someone please link the process on the ticket, and then close it?

#11 Updated by intrigeri almost 3 years ago

I think that the scheme is currently being deployed,

Only the revocation scheme is being deployed (#7700 which is private).
But our plan for dealing with such events has more to it :)

#12 Updated by intrigeri almost 3 years ago

  • Target version changed from 2016 to 2017

I'm told 2016 is over.

#13 Updated by cypherpunks almost 3 years ago

intrigeri wrote:

I think that the scheme is currently being deployed,

Only the revocation scheme is being deployed (#7700 which is private).
But our plan for dealing with such events has more to it :)

For what reason is it private? The lack of transparency is disturbing, for a few reasons:

  • Shannon's maxim: The enemy knows the system. If an adversary will be able to defeat a cryptographic key revocation scheme just by knowing how it works, the scheme is fundamentally broken. Unless I'm fundamentally misunderstanding why #7700 was made private, then the reason was that it was perceived that access to that information would break or weaken the scheme.
  • Kerckhoffs' principle: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge. Tails in general, and any relevant cryptosystems in particular, should operate under complete transparency, with everything in the system available to the public except the private keys.
  • Linus' law: Given enough eyeballs, all bugs are shallow. Giving only a few people access to the scheme prevents people from suggesting improvements or providing feedback. If only a few people have access, then the more resourced adversaries will be at an advantage.

If I have not misunderstood the reasons behind making #7700 private, then please reconsider its private status. The only things which should ever be secret information in a scheme like this are the secret key material.

I would also like to note that marking a ticket as private directly contradicts the social contract draft, which explicitly states:

Our entire bug report database is and will stay open for public view at all times. Reports that are filed here will promptly become visible to others.

Does this not apply to reports that are filed by devs who wish the reports not to be public? Additionally:

As Tails is created in a transparent manner, anyone is encouraged to participate, review it and point out problems.

I am unable to participate, review, or point out problems. How many other tickets related to the security of the Tails ecosystem am I not able to engage in? Either the draft needs revision, or the policy of secrecy does.

I'm uncomfortable using Tails, and giving Tails to my family, when neither I nor others in the security community are allowed to review the revocation scheme being deployed. Until the scheme is solid enough that Tails developers feel comfortable with it being public, I can't help but think of it as snake oil at best, and providing a false sense of security at worst.

Please reconsider this policy which neglects so many desiderata of cryptography.

#14 Updated by intrigeri almost 3 years ago

For what reason is it private?

That other ticket is private because some input fed into the revocation certificate distribution mechanism must be secret. But the design has been published a while ago: https://tails.boum.org/doc/about/openpgp_keys/signing_key_revocation/.

I think that most of what you wrote after this line was based on the incorrect assumption that the design of that mechanism was kept private, and is thus irrelevant once this has been clarified (and actually I agree with most of what you wrote, thanks for caring about this important topic :)

If you still feel the need to discuss this secrecy topic any further, please do that on a new, dedicated ticket, or even better, on the tails-dev mailing list: discussing topics on unrelated tickets is also a problem wrt. welcoming participation, 3rd-party review, etc., in a similar way to how secrecy is problematic: it adds barriers for potential contributors to find and participate in discussions they are interested in. Thanks!

I would also like to note that marking a ticket as private directly contradicts the social contract draft, which explicitly states:

Our entire bug report database is and will stay open for public view at all times. Reports that are filed here will promptly become visible to others.

Then that might be a bug in the social contract. I'll try to keep this in mind when I review that document, although you can answer the call for feedback yourself on the mailing list to ensure this is taken into account :)

#15 Updated by sajolida almost 3 years ago

And your feedback is welcome on #10022 if you are an expert and want to review the scheme.

#16 Updated by BitingBird about 2 years ago

  • Target version deleted (2017)

#17 Updated by intrigeri 8 months ago

  • Blocked by Feature #15097: Risk analysis on our infrastructure added

#18 Updated by intrigeri 8 months ago

Happy to work on this again once #15097 is done, if it shows that this is one of the areas where we should focus first.

#19 Updated by intrigeri about 2 months ago

  • Status changed from In Progress to Confirmed

(I'm not actively working on this at the moment; as said above, I'll wait for the risk analysis to be completed first.)

Also available in: Atom PDF