Whonix Warrant Canary

Organization
#11

I like the formatting. Keep it simple so everyone can understand it. :slight_smile:

Maybe one change.

The Whonix lead developer digitally signed this file
and states the following:

If its only you singing the file.

1 Like
#12
  • Don’t you want the Whonix master key fingerprint somewhere?
  • How often (very roughly) will the Whonix APT repository get resigned? Readers will want to know.
  • Bit wordy & passive language?

Instead, how about:

Whonix Canary

Statements

The Whonix lead developer who digitally signed this file states the following:

  1. Canary issue date: see the gpg signature time.

  2. No warrants have ever been served on the Whonix Project; for example, to hand out the private signing keys or to introduce backdoors.

  3. We plan to publish the next canary statement whenever the Whonix APT repository is re-signed. This occurs approximately every month. [Ref 1] [Ref 2]

This file should be signed with a detached OpenPGP signature by the Whonix lead developer.

Do not trust the contents of this file blindly - always verify digital signatures!

Special announcements

None.

Disclaimers and notes

Be mindful that Whonix has been designed under the assumption that all relevant infrastructure is permanently compromised. This means NO trust is placed in any of the servers or services which host or provide any Whonix-related data, particularly software updates, source code repositories, and Whonix downloads.

This canary scheme is not infallible. Signing the declaration makes it very difficult for a third party to produce arbitrary declarations, but this does not prevent the use of coercion, blackmail, compromise of the signer’s laptop or other measures to produce false declarations.

The news feeds quoted below (see Proof of freshness) confirm this canary could not have been created earlier than the issue date. This demonstrates a series of canaries was not created in advance.

This declaration is provided without any guarantee or warranty. It is not legally binding upon any parties in any form. The signer should never be held legally responsible for any statements made here.

Proof of freshness

(coming soon)

References

  1. https://github.com/Whonix/Whonix/blob/master/aptrepo_remote/conf/distributions#L11
  2. DebianRepository/Format - Debian Wiki “The Valid-Until field may specify at which time the Release file should be considered expired by the client.”
#13

I haven’t seen this by anyone else except Qubes. And “Qubes does so” by itself isn’t an argument. Perhaps I should have asked Qubes for reasoning behind it? Well, the Whonix master key fingerprint will be visible when checking the gpg signature of the canary. If another (malicious) fingerprint would sign the canary they’d just change the contents of the file too. So yeah, an implicit assumption (not written anywhere before now but assumed) is that the one verifying the canary already know Whonix ™ Signing Key by heart. Maybe not by heart but they already need to know which identity/fingerprint is behind. For whom it makes sense to sign the canary.

Good point. The valid-until period is currently set to 1 month. (Debian uses 2 weeks.)

(On APT valid-until: Valid-Until field in Release files | Ganneff’s Little Blog)

( https://github.com/Whonix/Whonix/blob/master/aptrepo_remote/conf/distributions#L11 )

So I have to resign Whonix repository at less than 1 month before I signed it last time. I do it most times when I work on Whonix source code, and when I remember. So it’s infrequent. But we haven’t had outdated apt repository metadata for a while so that works quite well.

Not sure what you mean by that but by experience your suggestions are almost(?) always taken. :slight_smile:

Please add.

#14

Thanks. I edited that into my suggested canary text above.

At step 3, I noted there should also be two footnotes:

  1. https://github.com/Whonix/Whonix/blob/master/aptrepo_remote/conf/distributions#L11
  2. DebianRepository/Format - Debian Wiki “The Valid-Until field may specify at which time the Release file should be considered expired by the client.”

This canary looks good to go?

When it’s up with Proof of Freshness, we only need to change the wiki canary entry accordingly.

1 Like
#15

What I never understood, what made me doubt the usefulness of canaries, but also never asked in public:

What if the case trying to plan for here actually happens? What if there:

  • is a legal basis exists to request adding a backdoor to Whonix, and
  • canary doesn’t get updated,
  • assume absence of other kinds of coercion for simplicity and focus of this question.

Then after the canary doesn’t get updated in time, the public could reasonably assume that a backdoor was added to Whonix.

In result: everyone who used Whonix from the time of the last canary issued (no backdoor version) until the canary expired (backdoor added in meanwhile) would be potentially compromised by the backdoor, depending on the type of backdoor.

That would be a very bad result indeed. But perhaps better to know after a month that one was compromised for a month than never knowing it? Is that the point of a canary?

“positives” (if it can be called that) in such worst case scenarios:

  • A canary might dissuade requests for adding a backdoor?
  • People might look for the backdoor, catch it, analyze it and widely publicize?
  • Possibly make similar backdoors in future unlikely by technological improvements?
  • People could fork Whonix and fix the issue?

What lavabit actually did by shutting down their service seems a much better than what lavabit could have done if they just had a canary and let it expire.

Warrant canary still seems to me have a very narrow scope:

  1. legally forced to add a backdoor
  2. legally forbidden to shut down service (can one be forced to run a project/business?)
  3. legally allowed to not update canary (right to refuse compelled speech)

Note: The point of this post is gathering a better understanding possibly leading to a better implementation. Whonix canary will be implemented in near future either way.

#16

While I don’t see how it applies to Whonix, (2) can certainly happen at cases authorities view the operation as illegal / supporting illegal activities: they take over the project while the project manager is required / coerced to cooperate. We have seen it happen with dark net markets.

I agree that a combination of all 3 is quite unlikely.

Of course. Some users didn’t have a chance of updating and will not be affected. They are saved. Others didn’t have potentially harmful material, yet. The rest will minimize the damage in any way they can and abstain from adding further compromising material or engage in communication that can compromise others.

Another point: there is some apparent contradiction between the principle of “perform updates as frequently as possible” and this canary concept. If indeed there is a canary (that is reliable in at least some scenarios), won’t it be better to update from Whonix sources only once a month, after it’s published (or you can look at it as possible negative of having a canary - users delay updates).

1 Like
#17

Or the way Truecrypt original devs shutdown shop by releasing a version that doesn’t encrypt.

Shutting down the website/code repos is indeed a more visible warning than any text notice.

2 Likes
#18

Canary is now live.

Duplicated to github in case of whonix.org server issues.

2 Likes
#21

Fixed.

Can you please change two things:

  1. Should have [1] [2] instead of [Ref 1] [Ref 2] in a few places (top section & footnotes section)
  2. Please add at the top this missing part and underline “Statements” (you want to keep numbering them right?):

—===[ Whonix Canary #1 ]===—

Statements

1 Like
#22

References removed entirely because: No need to mention my internal process “of doing this most of the time whenever I resign Whonix repository”. Greatly simplified:

We plan to publish the next canary statement within 4 weeks.

Sorry, I didn’t get this one.

Actually, no, I don’t have numbering in mind.

Btw canary-template.txt lives here:

Pull requests welcome.

#23

Actually it looks good now. +1

1 Like
#24

Can something be learned from…

?

Related: riseup.net likely compromised - #4 by anon36816226

#25
#26

At time of writing, Whonix warrant canary is valid. However, it’s time to address some issues that recently came to mind.

Problem: Potential Maintenance Lapses:

  • Re-signing the canary might happen too late. Didn’t happen yet. Pretty unlikely as I usually do this whenever I resign the repository. And re-signing can be done during any point within the 4 weeks period to restart the 4 weeks period.
  • There is no indication at the moment whatsoever that this might happen, but it’s possible that in future due to medical issues, an accident, being unable to re-sign the canary for a period of 4 weeks or longer. Should that ever happen, that should not forever shed doubt on the project. At least no more than unavoidable.

Solution: Healing Warrant Canary

  • The warrant canary could get added a passage that future signatures can heal previous maintenance lapses.

Recommended User Action in Case of Warrant Canary Issues:

Warrant Canary Issues could be:

  • Canary signature expired. (No new signature was created within 4 weeks after the last signature.)
  • Canary disappeared.

Recommended User Action in Case of Warrant Canary Issues:

  • Disable Whonix repository.
  • Stop downloading Whonix releases.
  • Monitor situation.
  • Organize community in another place.
1 Like
#27
#28

https://www.cloudflare.com/learning/privacy/what-is-warrant-canary/

#29

Enumerating Whonix project infrastructure we care about and in what circumstances its trustworthiness would be necessary:

1) whonix.org server related:

However, even if whonix.org server was under complete surveillance, that would not wreck the functionality of the Whonix software.

2) Whonix software related:

  • Users downloading Whonix images, not doing digital signature verification. These should not get compromised.
  • Users downloading Whonix images, doing digital signature verification. These should not get compromised.
  • Users upgrading Whonix using the package manager. These should not get compromised.
  • Users downloading Whonix source code (doing or not doing digital signature verification). These should not get compromised.
  • That is, in case there was some legal order to backdoor Whonix, and/or to sign backdoored Whonix and/or to turn over signing keys.

Priorities:

  • Whonix software is much more important than whonix.org website.

Possible Solutions:

  • A) Either make two sections in the canary. One for whonix.org server
    and one for Whonix software. In case of a legal threat, drop one
    section. That however, seems very experimental legal wise.
  • B) Exclude whonix.org server as long as Whonix software is free of
    backdoors.

Canary re-wording consideration:

Change from

  1. No warrants have ever been served on the Whonix Project;
    for example, to hand out the private signing keys or to introduce
    backdoors.

to

Definition “artifact”: Whonix software, Whonix downloads, Whonix
source code

  • The Whonix Project has never added any backdoor to any artifact.
  • The Whonix Project has never turned over any signing key.
  • The Whonix Project has never knowingly signed any artifact containing any backdoor.
  • The Whonix Project has never weakened, compromised, or subverted any of its cryptography.
1 Like
#30

Bad idea upon reflection.

Probably going for it.

Draft - Warrant Canary Draft

Was modified:
Dev/Warrant Canary Draft: Difference between revisions - Whonix

Giving more time for comments and if there are no major issues, going to change the actual canary.

#31

Implemented.

#32

Warrant Canary Draft wording was updated to include both, Kicksecure and Whonix.