akaro / persoapp

Automatically exported from code.google.com/p/persoapp
0 stars 0 forks source link

pseudonyms against Sybil attacks: nicer API and business process requirements #2

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. try to use ePA in free software applications 
2. consider the fact that you want to give the code everything needed to run it 
to end-users
3. consider that you cannot certify each end user separately as trusted to 
extract his private data from his nPA, and that you don't want to do this as a 
test but for a real-world application.

What is the expected output? What do you see instead?

Successful free software deployment without SaaSS (no typo).  This requires an 
ePA function that has no bad privacy implications when used by "anybody".  
Creating a pseudonym to defeat Sybil attacks in overlay networks fits this 
category nicely. What I would like to see is an API/example to do exactly this, 
and a business process to freely generate the necessary certificates to allow 
_anyone_ to create pseudonyms for "any" application free of charge (while 
strictly limiting the number of pseudonyms created per individual per 
application to one).

What version of the product are you using? On what operating system?

n/a. GNU operating systems.

Please provide any additional information below.

For free software to be able to use PersoApp in realistic 'libre' deployments 
(where it is not just used as part of a service), the certification process is 
a major roadblock, not just because of the expense but because there is no 
organization to be certified or to hold the private key.  I understand that the 
process is supposed to safeguard private information. Still, there is possibly 
one exception to this: the pseudonym function.

One big security issue in P2P networks is the so-called "Sybil" attack, where 
an adversary creates many identities (let's wildly assume the adversary does 
not control the Bundesdruckerrei this time). This could be prevented if each 
user had to show that he was 'real', by creating an unlinkable, 
application-specific pseudonym using the ePA.  As merely creating a pseudonym 
--- which should not be linkable to any 'real' identity or any personal data of 
the ePA, or any other pseudonym created for any other application --- is NOT 
private data (it's just a capability), this would be a useful way to defeat 
Sybil attacks (I would want this for my GNU project) AND I see no technical 
and/or privacy reasons why certificates that would allow applications to use 
this function could not be created cheaply (i.e. for free, as it can be done 
without any kind of audit), and without certifying a formal organization (which 
often does not exist for free software projects).

Ultimately, I would like to have a (simple) API to obtain a pseudonym for a 
given application identifier, i.e. I might specify "GNUnet" as the application 
identifier, and if there is a valid ePA in the device (and the user authorizes 
the operation, depending on reader, etc.) the API returns a pseudonym (ideally 
a private key that I can use for signatures, where the corresponding public key 
is certified to be a valid pseudonym that corresponds to a real human by 
"Germany"). Now, that's the ideal, but of course going to some website, typing 
in some application identifier ("GNUnet") and (automatically, without a fee) 
receiving a Berechtigungszertifikat first which would then be passed to the 
reader by the application later would also be acceptable.

Note that saying "but you can do everything in the Test-DV" without needing 
formal certification is not helpful at all --- eventually, a free software 
project wants to be used by real users in the real world, and at that point I 
must give the private key to obtain the information to each user, and I want it 
to work with real ePAs, not fake test crap.  So as long as real-world 
deployment is prevented, why would I bother to develop something for the 
Test-DV?  This is why this proposal is important: it could be deployed to the 
real world in free software without creating privacy issues.

Original issue reported on code.google.com by groth...@gmail.com on 31 Jan 2014 at 7:06

GoogleCodeExporter commented 9 years ago

Original comment by sdukan.f...@gmail.com on 27 Mar 2014 at 3:03

GoogleCodeExporter commented 9 years ago
The project PersoApp offers an open-source implementation of the BSI technical 
guidelines (BSI-TR) concerning the German national electronic identity card. 
The concept of the Berechtigungszertifikat is a cornerstone in the German eID 
architecture and therefore will not change in the foreseeable future. In any 
case, changing this concept would be a matter to be discussed with german 
officials rather than an open-source project that is committed to implementing 
the BSI technical guidelines. However, you are welcome to use the source code 
provided by this project to implement an alternative eId architecture of your 
liking. But you should be aware that you will not be able to use the german 
national identity card for that purpose.

Original comment by sdukan.f...@gmail.com on 28 Mar 2014 at 10:36