noid:
> Hi,
Hi, sorry for the delay.
> a) if you consider this could be a useful, viable and secure functionality.
> b) if you think it could be part of Tails in some future time.
Same here, "yes" to both. I don't know how much time you have to
allocate to that project but maybe you should first consider making a
prototype that works in Tails without putting to much emphasis into
getting it shipped in Tails by default as this will probably require
much more work (in terms of use case coverage, quality of code, Debian
packaging, etc.).
> Depending on the answers I would develop it taking care of possible future
> adoption or as an external application or a custom system based in Tails.
For the moment, I think that you should focus on making it an
application (in whatever is your preferred scripting language) that
works in Tails (and not a custom Tails distro for example as this would
be clearly overkill).
> I'm aware that a proper threat model should be done but in order to not take
> much of your time I've made a brief introduction and scheme for a first
> approach. Let me know if more information is needed to evaluate this.
>
> USE CASE:
>
> A group of users needs to create a secure communication system with the
> following requirements:
>
> 1. Allow synchronous and asynchronous communication.
> 2. No identity nor location information of accounts can be identified.
> 3. No content of communication can be observed.
> 4. The accounts are not intended to be reused in other aspects of their life.
> 5. Installation and group configuration must be easy to be achieved by standard
> users without getting in risk.
> 6. They are going to meet in person at least once.
All this sounds good. You might also need to clarify whether:
- The group is meant to communicate with the outside or only
internally. Because this could have a great impact on email for
example. If you want the group to communicate with the outside (for
example to have a public contact email address or each member to be
able to exchange emails with the outside) then you are forced to
use a public email service (you mentioned riseup later on). But if
the group is meant to communicate internally only, then you could
imagine having a private email server on a Tor hidden service, or
maybe even using a different protocol than email.
- The group is meant to be closed or open to inclusion or exclusion
of members. I think that the case of exclusion should be a
requirement as secure groups should be prepare to exclude someone
in case this person looses interest in the group, gets her hardware
or house raided by cops, or is discovered to be untrustworthy. So
I'm tempted to say that this should be a MUST in your threat model.
> POSSIBLE SOLUTION: Group-installer.
>
> The aim of this proposal it's to create a “group installer" function for Tails
> which must facilitate the installation on multiple usb devices and the
> configuration of persistence volume, email PGP key exchange and OTR chat
> between members of the group. At the same time it's intended to promote the
> use of identity isolation although it possibly wouldn't be mandatory by
> design.
>
> A basic scheme of it's functionality:
>
> 1. Ask for number of members.
> 2. Ask for accounts of a mail and jabber service (riseup.net allows both with
> same account).
Did you check whether the Jabber service of riseup allows you to have
private chatrooms, say with a password? Note that OTR doesn't work for
groups so the best you can have is a private chatroom on a trusted service.
> 4. Ask for passphrase.
> 3. Create key-pairs.
> 4. Create persistence folders for each user with GPG keyring, Claws and Pidgin
> configuration with key exchange, address book and OTR activated.
You should maybe consider using Icedove straight from the beginning.
Claws Mail is crappy and we'll migrate to Icedove at the beginning of
2016. Several of us are using it already in Tails and it might be easier
to configure through code.
> 5. Ask for usb device
> 6. Clone Tails
> 7. Create persistence volume
> 8. Copy persistence folders
> 9. Iterate from 5 to 8 until all user/devices are created.
>
> TO RESOLVE:
>
> Besides all technical and security issues that this idea involves and the
> compatibility or not with some Tails design (p.ex about persistence volume
> creation) there are some global questions to resolve:
>
> 1. Creation of mail and jabber accounts:
> It should be done within a Tails session and just for that group use. Ideally
> it would be done automatically by the group-installer but afaik there aren't
> trusted providers that implement this so the installer should ask for the
> creation of them manually. I've seen onionmail work on this but think it's
> preferable the use of well-known mail servers as riseup.net to ensure
> persistence of communication system.
Right. This would be very hard to automate and you should start with a
manual creation of those email accounts. Bootstrapping with 4 invites
codes for riseup should be enough:
- With invite code #1 and #2 you create mailbox A.
- With invite code #3 and #4 you create mailbox B.
- With mailbox A you create as many other invite codes as needed.
- With mailbox B you create as many other invite codes as needed.
> 2. Passphrase creation (persistence, PGP). Two scenarios:
> - They are all going to meet in person once. Installer asks for passphrase for
> each user.
I would do that: people should meet in person and each one type her
passphrase into the group installer without the others knowing it.
> - Someone must create all or some Live-Usb for other users that aren't
> present: some method for avoiding the impersonation of members by the group
> creator should be implemented. The use of a temporary passphrase and ask for
> change it at first boot could be a solution. (Maybe if users can't trust group-
> creator this scenario doesn't makes sense?)
It seems like you need to have this figure of the group creator anyway.
And then members of the group will have to trust her for so many things
(not having a rogue Tails system to start with). So you should take this
for granted: this person and this Tails system needs to be trustworthy.
> -------------
>
> Well I hope this is enough to make an idea.
It does. I think that in order to start with the more concrete work you
should write a manual on how to perform all this in Tails as of today.
Describing the threat model, the goals and non goals, the ceremony of
group creation by the group creator, etc. Your manual would include a
script of the instructions throughout the group creation.
Then only, you should try to find way to automate as much as you can of
this process. This will help you validate your threat model and have a
broad picture of the process and what needs to be achieved. Then you
will be able to dig into the technicalities while knowing where you go.
And if you end up being technically limited by some aspects (either your
technical knowledge, your time, or what's possible to do in Tails), then
you will still be able to deliver *something* that works at the end of
your project.
> I really appreciate the work you're doing and know Tails development has
> priorities, I'm not asking for you to change them and and I'm open to
> reconsider my project if some of the work that must be done fits my knowledge
> and my university work requirements.
That's another option but it's hard to tell without knowing in more
details what are you skills, how much time you will be able to dedicate
to your project, and what kind of project fits in this scope. I also
think that your project as you describe it is very ambitious and if you
want to downsize it a bit we might be able to find other tasks in our
roadmap for you.
> I must say that I make this project as a
> first in step in getting deeper into sysadmin and programming on Tails / Debian
> so don't expect too much from me in this next months ;)
Good to know!
--
sajolida
