Hi there,
I'm part of the SilentKeys team and we want to introduce our project
that will leverage a Tails fork. We talked about it briefly with one of
you at Numa about a year ago when we attended a UX session. We're based
in Paris and have been using Tails since at least 0.16. The first SK
prototype ran Liberte before moving over to Tails 0.21.
We are humbled by and very respectful of the philosophy, the ethics, the
professionalism, the technicality and the transparency of the Tails
project. It has come a long way, gaining both technical robustness,
public exposure and made a lot of crucial user-centered progress.
We know the balance between commercial projects and FLOSS can be both
tricky to attain and criticized but we won't let that prevent us from
trying.
The homepage is at:
https://getsilentkeys.com/ or
http://hvaudvqty72cxnbo.onion/
If you want to read more about the background of the story here's an
informal blogpost:
https://preev.io/blog/2016/04/sk-story/
The schematics/files for building a SilentKeys “module” and the source
code for building the fork (SatyaOS) will both be released around launch
time.
We are aware there are no silver bullets in infosec, and that for most
people reading this SK probably doesn't seem like much. We'll just ask
you remember that you're uber-geeks, part of the digital 1%.
We're building this for non-technical people (techno-phobic folks, very
busy pros, grandmas, privacy-inclined and snooping-conscious people that
still will never come to cryptoparties etc). Folks who just want to
browse, bank, shop, research or talk in relative (yet way higher than
WiniOSXid) safety, without having to worry about whether or not there is
malware snooping on them or if they're leaving crumbs all over.
We believe our technical choices (including using Tails), a familiar yet
sleek hardware format as well as physical separation and hardware
“read-only-ness” are novel mainstream propositions and fit our bill.
You're welcome to disagree of course, and by coming out like this we
really wish to engage in order to get constructive feedback.
We will post checksums of our releases for those who know how to verify
and more importantly we will produce bootable ISOs that will certify the
content of the system and the recovery memories for those who don't know
how to.
We sincerely believe there can be some form of synergy between our
project and the Tails project. Our visibility will probably increase the
usercount of Tails as we won't hide SilentKey's debt to the project to
our users nor in our communications. We will merely join all the other
open projects such as Tails that help bring *nix, Tor, encryption and
privacy issues in the spotlight. And unlike iCloak (where's the code??)
or Anonabox (Tor ain't no wildcard), we're committed to integrity and
transparency.
If things go well we will help Tails get more man-hours and code : for
instance we really want to have AppArmor enabled and properly configured
as soon as possible and for it to work on our system it has to first
work on Tails so we'll be joining the effort, as we already have before.
Same goes for your UX roadmap.
All development work we will do in-house will be freely available on our
Github for all to review, use, improve, you know the deal. Let's talk.
We're now working hard on the crowdfunding campaign, hoping to raise
enough to build the first series and move into beta. We won't stop you
from spreading the word if you like our initiative!
We'd be happy to answer any questions you have. You can find me,
RomeoPapa on OFTC. I've committed to stick around in #tails and you're
welcome in #silentkeys anytime.
Thanks!
Just a few more details:
The system's memory is physically read-only by default, mostly as a
last-resort safety against users mistakes. We're talking about the type
of users that when they see a web popup telling them to download a "free
antivirus" because "an infection has been detected" will ignore the
warnings that the system might be showing them and actually follow the
popup's instructions and are then left wondering how a virus got into
their system. Also this last line of defense can be useful against
attacks or malware that target 0-day vulnerabilities with privilege
escalation in one of the bundled applications: it's going to be hard for
malware to install itself on a write-protected system disk*.
When the system has to be upgraded, the wizard process will ask for the
user to activate the 'special' write-enable switch, that will physically
enable writing capabilities on the system memory. Once the system has
been upgraded, the wizard asks for the user to deactivate the
write-enable switch. We perform checks at boot-time and during run-time
to see if the user hasn't activated the write-enable switch by mistake
and warn him of the fact**.
* Of course, such type of malware with privilege escalation could come
and read/modify the content of the SD card and could read and modify the
host's hard-disk or could install itself in the bios. But then again do
you know any personal computing solution able to withstand such attacks?
** We can indeed imagine a future where specialised attacks in the form
of web popups might ask for users to activate the write-mode switch. We
hope that by then that the user might be more conscious of physically
activating a switch than just discarding an UAC prompt.
