Feb 16, 2019, 4:08 AM by xa...@protonmail.com:
>
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, February 15, 2019 10:58 PM, <> qubes-...@tutanota.com
> <mailto:qubes-...@tutanota.com>> > wrote:
>
>> Dear Patrick,
>>
>> I appreciate your answer and understand your point of view. On the other
>> side, the issue raised by the law in Australia (and GCHQ asked for that too,
>> like the request of ghost user in all the "encrypted" conversations) is an
>> important security concern and should be taken into consideration in the
>> thread/trust model not only with Whonix, but with all the HW, SW,
>> infrastructure and personnel. As of today, it is not.
>>
>
> While this threat is certainly a concern it is nothing new. Although new in
> Australia, many other countries have had similar laws and/or don't have any
> laws that would prevent the govts from forcing a person to do pretty much
> what ever they want. With ever evolving threats it would be near impossible
> to keep up. Once a mitigation is found for one, two more emerge. How do you
> combat adversaries that have near unlimited resources? Trust model/concerns
> have been considered in > https://www.whonix.org/wiki/Trust
> <https://www.whonix.org/wiki/Trust>> . (Has anyone bothered to read it?)
>
I am not talking about magical 100% protection or 10$-wrench-decryption. I
believe this attack is different by its implications and consequences. Sure
many govs using different methods today, many of which are but un-lawfull.
Doing this can ruin any case be it getting to the court. By having these laws
in place, like the ones in Australia, this attack yesterday unlawful, is lawful
today. This has high consequences. To ruin any project today it is enough that
they come and ask you for your keys, or ask to plant a backdoor. If not, you go
to jail. Project is over, perfectly fit with law. Yesterday it wasn't possible
so simply, they had to be on border with or cross the law, considering morality
of the dev constant.
>> Existing thread models are currently not considering this form of attack.
>> Same way as the existing thread models, including those of Qubes, TAILS,
>> Whonix and others, are not covering the thread of being forced on the border
>> to GB or US to hand over all the keys to all your digital devices under the
>> thread of imprisonment. There is no Hidden OS functionality mentioned, and
>> no known development in this area, even the thread exists and ppl are
>> already successfully exploited by these attacks.
>>
>
> If anyone can come up with a mitigation to an adversary putting a gun to a
> developers head and asking nicely for their private key - id like to hear it.
> How exactly does someone overcome an impossible situation? How do you you
> cover a - do as is say or die- threat model? Holy shit! It was here all
> along! > https://www.whonix.org/wiki/Trust#Free_Software_and_Public_Scrutiny
> <https://www.whonix.org/wiki/Trust#Free_Software_and_Public_Scrutiny>
>
As an example, if developer is anonymous, one can point gun at his own head
only. This should be part of the thread model, mitigations and contingency
plans. You are again trying to find 100% solution for everything, and if not
available, you call it impossible situation. It is possible situation and must
be analyzed separately from other threads with different characteristics.
>> This is but not an issue of Whonix. It is an issue of not addressing the
>> new, emerging attacks clearly. The FMECA, which is constantly not updated,
>> becomes obsolete, and continuously useless. From my personal experience, if
>> people are sub-aware that some FMECA points could be very difficult to
>> address and solve reasonably, they tend to avoid to put it in to the FMECA
>> and start to care.
>>
>> Concerns related with that Ausie law and similar activities of some
>> entities, are based on reality. Before the law was here, it was more
>> difficult to successfully reach forced cooperation. Usually it was through
>> blackmail, convincing, threads or similar activities, to forge the canaries
>> and insert the dirt in the code or HW. There was still quite good space for
>> an effective resistance of the personnel, if one wanted. The personnel was
>> protected by law. The kind of moral part today is killed there completely.
>> Today they just come and bring you the lawful request and you must comply
>> with it and fulfill the request, or go directly to jail ( I think it is 5
>> years?), and at the same time you are bound not to tell anyone, by any means
>> be it your corporate employer, your teammate, brother or development project
>> partner. They effectively created from every citizen a potential agent,
>> which cant deny to become one if requested.
>>
>
> Yes, before the law other means would be necessary to compel a developer to
> backdoor software in **Australa**. Now the laws says the govt can force a
> person, or go to jail. Some would choose jail (then the cats out of the bag.
> Everyone would then know why they went to jail. common sense). Others might
> not have much of a choice. Regardless, this and other emerging attacks has
> been consider and covered.... (not necessarily whonix specific)
>
> * > https://www.whonix.org/wiki/Trust#Free_Software_and_Public_Scrutiny
> <https://www.whonix.org/wiki/Trust#Free_Software_and_Public_Scrutiny>
>
> * > https://www.whonix.org/wiki/Trust#Trusting_Debian_GNU.2FLinux
> <https://www.whonix.org/wiki/Trust#Trusting_Debian_GNU.2FLinux>
>
> * > https://www.whonix.org/wiki/Trust#Trusting_Tor
> <https://www.whonix.org/wiki/Trust#Trusting_Tor>
>
> * > https://www.whonix.org/wiki/Trust#Evil_Developer_Attack
> <https://www.whonix.org/wiki/Trust#Evil_Developer_Attack>
>
But they would have been in jail. Heroes, but in jail. And the project is over.
If the target of the project is becoming a hero, than your attitude is ok. But
the sec projects like Qubes, TAILS and similar, don't have it in their
description. They are supposed to be resistant to the threads, mentioned in
their thread model. I am saying lets include these there too. Projects like
Qubes and TAILS, Whonix are about endpoint protection. The hidden operating
system and hidden files ( an example), plausible deniability, and similar
features, are as well the endpoint protection. Without it, in today's world you
cant build reasonable security model. If crossing certain state borders,
airports, or living in some states breaks your security completely with one
question from an official, one has to ask what realy is the durability of such
solution. Considering existing real-world threads, is it enough to have just
Veracrypt with that functions, or we need to have a look deeper into the
matter? I believe we need to go deeper and mitigate these risks
>> Quite easy countermeasures were possible, if the devs (in this case), were
>> anonymous. But they are not so much, right? Therefore are open to this
>> particular attack that just emerged. How and when will it be added to the
>> thread model and covered, together with other new emerging threads, by
>> respective tams, is the only question to be answered.
>>
>
> Already covered.
>
Seeing all the faces in all the conferences and dev meetings and photos and
videos everywhere, I humbly doubt you are right :)
>
> My questions: When will the people who bring these issues up (valid issues)
> realize this is a shared burden - both devs and community. Why didn't the OP
> feel compelled to put forth the effort to research and understand this
> problem before crying wolf? This issue is not new. This same issue
> (developers backdooring) had been discussed and beaten into the ground
> countless times.
>
Shared burden, YES! Lets share this-particular-attack(s?) in the thread/trust
models, mitigations and contingency plans. First step is to put it in. If you
feel you don't need to, because they both ways come with the wrench and break
your bonese, your thread model is covering only one attack, which both ways is
extremely difficult to mitigate. Lets enlarge it a bit. FMECA loves multitudes,
even some points just remain opened.
> Here is what is comes down to. Developers can be forced to alter/backdoor
> software in **many** countries. It makes no difference how its done, threat
> of jail or violence makes no difference. This is an impossible situation to
> 100% solve. It could be solved but not likely due to the lack of support
> (financial, code contributions, audits etc.. ) from communities from
> **every** project.
>
"makes no difference." I believe it makes a lot of difference. To kill you or
torture you, needs very different reasons, resources and determination, than to
kindly ask you to do things, or face perfectly lawful action in fashion ties,
with you not being able to win.
No one is asked to solve anything 100%. This is the magic of FMECA and similar
tools. If you are honest, professional and really good, you will not be able to
cover all the points 100%. That's the magic and pain of true OPSEC, based on
reality. I agree with you, it is really related to every project and therefore
it should be covered in every project.
>
> FWIW I'd like to give the OP a round of applause for singling out a well
> respected dev when this is not just Whonix issue. Not only for that but also
> deciding (for the dev) that he would just cave in if encountered with this
> law/situation. This is an attack on his character if i ever saw one. This
> problem applies to Tor, Qubes, Whonix, DropBox, devs that live in any country
> that doesn't have laws that protect people or have laws that can compel them
> to cooperate.
>
I believe, that honest risk assessment of the new situation in Australia (it is
new, simply is) needs to be done correctly. I must be done and doing it is not
an attack of the character of the dev. New attack, can but challenge the
character in a different way, than expected before the law was approved. Take
into consideration please, that in the thread model you must consider also
probability that certain attack happens, and determination of the attacker.
To use torture, murder or any other violent or unlawful measures, (to get the
same effect as following Ausie law today), needs completely different
attacker's determination, very different and rare, highly specialized resources
to do that job, and there is much lower probability for this measure to be
executed in real life. How many sec devs were tortured and killed this year,
because they denied to hand over their keys?
To execute the attack today with law in hand is incomparably simpler, with the
same or even higher effect. It needs incomparably much less determination from
the attacker, largely available, non-specialized resources can be used to do
the job, and so the probability to execute the attack is much higher too.
Do you get my point now?
>
> OK I'm done with my rant. ;)
>
Done too :)
>>
>> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>> You received this message because you are subscribed to the Google Groups
>> "qubes-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to >> qubes-users+unsubscr...@googlegroups.com
>> <mailto:qubes-users+unsubscr...@googlegroups.com>>> .
>> To post to this group, send email to >> qubes-users@googlegroups.com
>> <mailto:qubes-users@googlegroups.com>>> .
>> To view this discussion on the web visit >>
>> https://groups.google.com/d/msgid/qubes-users/lynnvql--...@tutanota.com
>> <https://groups.google.com/d/msgid/qubes-users/LYnNVQl--3-1%40tutanota.com>>>
>> .
>> For more options, visit >> https://groups.google.com/d/optout
>> <https://groups.google.com/d/optout>>> .
>>
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/LZ4pvoH--3-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.
