[ciphershed] Re: Trust - was: Warrant canary

  • From: Niklas Lemcke - 林樂寬 <compul@xxxxxxxxxxxxxx>
  • To: ciphershed@xxxxxxxxxxxxx
  • Date: Sun, 22 Jun 2014 20:18:05 +0800

On Sun, 22 Jun 2014 13:06:01 +0100
PID0 <p1dz3r0@xxxxxxxxx> wrote:

> Niklas,
> 
> I do apologise, I certainly wasn't trying to suggest that we adopted the
> examples given in my email, I was purely trying to illustrate the
> purpose of the canary, and how it's used in the winder context.

I never thought you were trying to suggest that.

> 
> My concern is that we're focusing on ensuring that dev XY is next month
> who he is now. But there's nothing to stop; A) dev XY being an NSA mole
> from day 1, or B) the NSA coercing dev XY into showing his replacement
> what the warant canary for him is.

exactly, which is why I put up the two assumptions. According to those,
Adversaries are acting according to the law. If they are not, canaries
are worthless, not matter their form or implementation or secrecy.

> 
> The essence of what I was trying to convey in my description of the
> canaries is that once their existence is known you can be
> compelled/coerced into changing them to suit the beligerant. 

The whole idea of a canary is that you can not (legally) be coerced to
lie, i.e. post a fake canary. If you can be forced legally then a
secret one may be an option, but it would be very risky. If you are
being forced illegaly, it is even more risky and highly likely that the
targeted dev will choose to cooperate.

> Regardless
> of the technical mechanism used, be it email sig, email domain, etc. If
> it is known that you are required to do X to verify yourself as a person
> the beligerant will simply force you to tell them what it is (not that
> they'll need to since all emails to this mailing list are on google) and
> simply recreate it.
> 
> I would recommend that each core dev establishes a separate secret
> canary with at least two other core devs. Doesn't have to be some
> elaborate system of counter-signing from special accounts (which only
> proves that the message was sent from an authorised account, not that
> the person using the account was the same).

This would still not stop the A) and B) you mentioned. I do think it is
a very valuable idea which we should apply, but it is just another
layer of more or less the same kind of security like the common email
footer & signature.

> 
> I know the community is largely adverse to privacy (ironically), but
> keeping your canary a secret from everyone but those that need to know,
> reduces the liklihood that it's going to be used maliciously to
> impersonate someone that has been compromised (also, ironically).

As I said, I think it is a good idea to adopt secret canaries, but I
think that the kind of open canary would be mandatory. Certainly ten
(or how many core members there will be) people could be served with
warrants at the same time. I still feel there is a strict need to
communicate our canaries with the public. That does not stop us from
using additional security internally of course.

> 
> On 22/06/2014 12:47, Niklas Lemcke - 林樂寬 wrote:
> > Since I'm developing my own idea of how to tackle the issue, I
> > will top post and answer to your several points along the way.
> > 
> >     Yes, no scheme can possibly be 100% secure. That can
> > however not be the basis for any decision. The benefits and drawbacks
> > have to be carefully evaluated. It is easy to get carried away and
> > introduce unnecessarily complex and thus in the end counterproductive
> > mechanisms.
> > 
> >     First, I will specify the assumptions I am making for the
> > following discussion: 
> > 
> >  * The main threats we are looking to parry with the warrant canary
> > scheme (which ever we will end up deploying) are those that operate in
> > some form of legal framework. That is why it is called 'warrant'
> > canary. Without this assumption a warrant canary is without any value,
> > since the attacking entity can just point a gun at somebody's
> > grandchild, mother, pet, or use it's favourite form of torture to
> > compel one of the members to cooperate. This kind of threat is not
> > covered by any form of warrant canary.
> > 
> >  * Within that legal framework, persons can be forced to remain silent
> > about the issue, but cannot be forced to lie to others. Warrant canary
> > are not tested in court, so this is really just that: an assumption.
> > With this assumption being invalid, warrant canaries would again be
> > completely worthless; so we will just assume it is valid, but keep in
> > the back of our mind that there are unknowns in the equation.
> > 
> >  * The contributing persons are all well-intentioned.
> > 
> >     These three assumptions already show that, clearly, warrant
> > canaries are not a solution we can depend on. Rather they can help us
> > fend off a proper subset of the existing threats, and in combination
> > with other mechanics lead to a more and more foolproof overall system. 
> > 
> >     Further, after accepting the three above assumptions for the
> > context of this discussion, let me reestablish a notion Bill brought
> > forth a while ago: It is not vital for us to know whether every person
> > is in fact the person she / he claims to be. That would mean making
> > thorough background checks on everyone, and if some resource-strong
> > agency wanted to fool us that way, they would certainly succeed. Thus
> > it is of much more importance for us to know whether the person
> > contributing as and claiming to be Developer XY in half a year is still
> > the person he was now. This is why at the beginning we all exchanged
> > our public keys, and (with some exceptions still) all sign our emails
> > to this list.
> > 
> >     Having established all of this, let us examine the strengths
> > and weaknesses of the two schemes currently discussed.
> > 
> >  * First, the signed email with a warrant canary footer.
> > 
> >     Strengths:
> >      - Simplicity (theoretically one single point of failure for
> > each individual: the validity of the assumptions)
> >      
> >     Weaknesses: 
> >      - People forget to copy the footer into mails
> >      - when posting from mobile, mails will not be signed which
> > renders any footer useless.
> >      - certainly some more
> > 
> >  * The scheme you suggested
> > 
> >     Strengths:
> >      - certainly some, but they are not important for arguing my
> > point, so I will not list them here
> >      
> >     Weaknesses:
> >      - Complexity, i.e. many possible points of failure. E.g. you
> > may have a complex web of friends and contacts, but i) they may not all
> > feel the need to be serious about the issue, or ii) the weakest point
> > in the scheme determines the schemes security, and there are certainly
> > some developers with less complex networks
> >      - Furthermore its security also completely depends on the
> > validity of the above assumptions. This does not defeat any issues like
> > torture or malicious developers. Thus it does not add any additional
> > security to the simpler scheme.
> > 
> >     The same goes for the schemes that Chris discovered to be most
> > efficient but unfeasible across the internet. If an attacker tells the
> > target "you don't talk or your child dies", I believe most would choose
> > not to turn that garden gnome.
> > 
> >     Hence it is vital to have a second (and possibly third,
> > fourth..) line of defense, the most obvious being meticulous control of
> > any added / changed code by more than one of the core developers. The
> > (very possible) case of one or more of the assumptions failing has to
> > be catered for. But this is not part of the discussion about our canary
> > scheme.
> > 
> >     I suggest to keep using the signed-email-with-footer scheme.
> > There can certainly be a few adjustments made to it to cope with some
> > of the usability-flaws it inherits. For example we assign
> > @ciphershed.org email addresses to all core members. That address will
> > only be used from the members working station, with footer and
> > signature by default. (No need to add it manually everytime because you
> > may don't want to add the footer by default into mails you send to your
> > mom.) 
> >     That way there will also be less misunderstandings and false
> > alarms, since mails from mobiles will be sent from a different address
> > and we know those won't be signed. But the mails from the
> > @ciphershed.org addresses will always be signed. That way it certainly
> > is a "no-brainer" as you insist (and which I agree to). If any member
> > has not sent mail from her / his ciphershed address for a longer while,
> > we can ask him to send a message. Depending on her / his reaction we
> > will be able to judge the situation.
> >     
> >     Since each message is different, and each message is signed
> > together with the footer, I do not think there is the need to adjust
> > the footer with a recent headline or anything similar.
> > 
> >     Of course, additional approaches to security can be discussed,
> > and maybe pairs of members can establish secret canaries as Chris
> > pointed out. But as a simple and efficient basis the signed-mail-footer
> > approach is the best one, I believe. 
> > 
> > 
> > Niklas
> > 
> > 
> > On Sun, 22 Jun 2014 02:55:51 -0700
> > Karen Palen <karenpalensl@xxxxxxxxx> wrote:
> > 
> >> Obviously no scheme can possible be 100% secure.
> >>
> >> One of the things you have missed here is that this must be applied to 
> >> EVERY project participant at the same instant!
> >>
> >> Certainly you can defeat the scheme for any one individual, but to track 
> >> down ALL of the friends/relatives of EVERY individual even remotely 
> >> associated with the project is an enormous task. Even with this project 
> >> as small as it is now must involve several thousand friends/relatives 
> >> who have nothing whatever to do with this project.
> >>
> >> To intimidate (legally or otherwise) EVERY one of them RIGHT NOW is as 
> >> close to impossible as I can imagine, especially since (in my case at 
> >> least) they would be spread over 20+ countries!
> >>
> >> That being said, it would take some really HUGE resources to track down 
> >> every friend/contact that even I alone have made for the past 30+ years. 
> >> As a Ham Radio operator for 50+ years my friends include people from 
> >> literally every corner of the Earth!
> >>
> >> Many years ago I actually explored this with the NSA as a way to provide 
> >> password security and they admitted that there was no way that they 
> >> could keep track of my Ham Radio contacts! I doubt if the situation is 
> >> much different today - unless you postulate and "evil Bogon Empire".
> >>
> >> The essence of the scheme is to verify identity and I cannot think of 
> >> any better way that through those who have known you for much of your life.
> >>
> >> The rest is subject to revision, but I do insist that ANY scheme be a 
> >> "no brainier"/"no effort" for the very long time that "nothing happens"!
> >>
> >> Too many false alarms are deadly!
> >>
> >> Mike
> >>
> >> On 06/22/2014 02:19 AM, Niklas Lemcke - 林樂寬 wrote:
> >>> On Sun, 22 Jun 2014 02:06:52 -0700
> >>> Karen Palen <karenpalensl@xxxxxxxxx> wrote:
> >>>
> >>>> I would suggest that the only truly reliable way to validate identities
> >>>> is through long time friends/relatives who can ask about memorable but
> >>>> otherwise unremarkable life events.
> >>>>
> >>>> e.g. Who barfed on Uncle Joe's shirt at his wedding?
> >>>>
> >>>> Anyone who was actually present at the wedding would remember this, but
> >>>> the odds of it being recorded in some database are minimal.
> >>>>
> >>>> Let me propose a scheme:
> >>>>
> >>>> 1) Provided you log on to some unrelated account once per
> >>>> week/month/whatever then nothing happens.
> >>>>
> >>>> 2) If someone FAILS to log on to that account (many possible
> >>>> explanations at this point) then emails are sent to several
> >>>> friends/relatives with a message saying something to the effect that
> >>>> "something has appears to have happened to Bill please contact him ASAP
> >>>> and ask him about XXX AND SOME OTHER QUESTION THAT ONLY HE COULD ANSWER!"
> >>>>
> >>>> 3) If the phone call/contact shows that Bill is still alive and freely
> >>>> answering questions (including ones that no one could anticipate!) Then
> >>>> everything resets. However if "Bill gives a WRONG answer then the
> >>>> friend/relative is asked to send an email to XXX@xxxxxxx with a specific
> >>>> message. Obviously several friends/relatives NOT associated in any way
> >>>> to this program are required!
> >>>
> >>> If any entity actually is able and willing to spend enough effort,
> >>> money, resources to dig me up at my home, force me to hand over my
> >>> keys, to shut up and to keep posting my warrant canary at the bottom of
> >>> my emails, then why should they not be capable of doing any one of the
> >>> following:
> >>>
> >>>   - Also present warrants to my family & friends, forbiding them to ring
> >>> the alarm (remember that they can certainly forbid people to speak out.
> >>> the canary works on the assumption that they can not force us--at
> >>> least not legally--to lie).
> >>>
> >>>   - intercept said email
> >>>
> >>>   - send a second email stating "sorry, false alarm, in fact she / he's
> >>> all good!" (no signatures of any kind either)
> >>>
> >>>   - also force me to tell my family all is good
> >>>
> >>>   - since they got my keys and passwords, just log on to said account on
> >>> my behalf every week
> >>>
> >>> In fact I felt that this was barely more secure, but certainly more
> >>> complex than the simple email-signature canary.
> >>>
> >>>
> >>> I will elaborate on my view on the topic in a later email--possibly
> >>> tonight.
> >>>
> >>> Niklas
> >>>
> >>>
> >>>>
> >>>> 4) IF (and ONLY IF) the specific message is received then the alarm is
> >>>> sounded - as loud and widespread as possible!
> >>>>
> >>>> I think this satisfies several requirements for such a "warrant canary:
> >>>>
> >>>> 1) If all is well no one need do anything (i.e. there is nothing to
> >>>> forget). Remember this will be the case for many years. Automation is
> >>>> essential.
> >>>>
> >>>> 2) Anonymity (to whatever level is desired) is preserved - ONLY the
> >>>> relative/friends need know the person's identity, and even they do not
> >>>> need to know that "Bill" is associated with some "subversive" project!
> >>>>
> >>>> 3) After several weeks of "mulling" this I rally can't see any "fall
> >>>> through" holes which would defeat it.
> >>>>
> >>>> Only the "evil Bogon Empire" who have complete records of everything the
> >>>> Human Race has said and done for the past 100 years could defeat this.
> >>>>
> >>>> NO NONE knows me like my sister or 20+ year friends! For example I have
> >>>> used an alias on many "comment boards", my sister spotted the reference
> >>>> the moment she saw it! No one else could possibly have done so!
> >>>>
> >>>> Comments? Paranoia?
> >>>>
> >>>> Mike
> >>>>
> >>>> On 06/21/2014 02:52 PM, Kyle Marek wrote:
> >>>>> On 06/21/2014 04:54 PM, Pier-Luc Caron St-Pierre wrote:
> >>>>>> Since PGP is a decentralized model, we need to find a way to validate
> >>>>>> our identities.
> >>>>> We could read our fingerprints to each other over TeamSpeak
> >>>>>
> >>>>> ------------------------------------------------------------------------
> >>>>>
> >>>>>       At the time of sending this message, I have not been contacted by
> >>>>> any government official or worker regarding my participation in
> >>>>> CipherShed or any related project. I have not been asked to supply any
> >>>>> information to them that may be used to impersonate me nor have I been
> >>>>> asked to aid the government or it's officials or workers in modifying
> >>>>> part of CipherShed or any related project. I am not aware of any of my
> >>>>> property or anything regarding me being bugged, searched, or compromised
> >>>>> in any way. Anything that accepts PGP encryption or signing should have
> >>>>> been cryptographically secured with my PGP key.
> >>>>
> >>>
> >>>
> >>>
> >>
> > 
> > 
> > 
> 



-- 
Niklas

At the time of writing, no warrants have ever been served to me, Niklas
Lemcke, nor am I under any personal legal compulsion concerning the
CipherShed project. I do not know of any searches or seizures of my
assets.

Attachment: signature.asc
Description: PGP signature

Other related posts: