gijsweterings / identitychain Goto Github PK

Eventhough we are using the async version of grpc, sometimes it triggers the network on main thread exception.

For now let's lift it with rx.

If we are going to send the secrets through grpc, we should enable encryption.
This however requires an ssl certifcate on every android devices for the netty server.

Maybe we could use Let's encrypt for this, they provice a few java libs to do certificate creation:
https://github.com/zero11it/acme-client

However they all seem to require java 8. @eanker @GijsWeterings you guys had experience with letsencrypt right? what do you think?

On phones with android 8, the runtime permission pop-up for contacts is not displayed.
Therefore the app can't run, as this permission is needed to run the app.
This seems to be due to an update to the way android handles permissions in this version of the API.

Therefore the app currently does not work with android 8.

Currently, the bluetooth functionality is not working properly, only sending a hardcoded value along. We either have to choose to remove the bluetooth functionality or fix it in such a way that it can also function correctly

When generating a zkp with a third party, they generate the zkp for us.
We can publish (for the range proof) the SQR and EL proofs.

However to respond to the challenge we need the random numbers that they generated, to calculate the response. These should also be transferred over the network so we can save them.

To do this we need to change their protobuffer structure and their networking.
This is now done through plain sockets and is rather hacky with no routing.

We think using: https://grpc.io/docs/tutorials/basic/java.html
would be our best bet in cleaning up this code, as it still allows us to use protobuffers easliy

When generating a zero-knowledge proof, an N exists, and (nearly) all calculations are performed in modulo N.
This N is, at the moment, generated by a "Trusted Third Party". The reason such an entity is needed is because the security of the protocol depends on neither the Prover nor the Verifier being in possession of the factorization of N.

In reality, there is of course no Trusted Party. Because N is generated as the multiplication of two large primes p and q, this is a problem. If the Prover generates N, then they are implicitly in possession of p and q. This means that in modulo N, they MAY be able to generate fake proofs using the factorisation of N they just calculated. We are not completely sure of this, it will be a research topic of @eanker and myself.

It is also unpractical to let N be generated by any random bystander, as we are currently unsure of the security implications of this. In the worst case scenario, the Prover fakes asking the "random bystander" and generates it themselves.

In the meantime, while our research progresses, we are letting the Prover generate p and q.
This means that for the moment all proofs generated should be considered dangerously insecure.

When creating the attestation we block the ui thread for a long time.
we should move to the async grpc api

Currently, in the QualityUI branch, there is a UI built for the BiometricActivity, which should check the validity of the fingerprint of the user. This activity is a stub at the moment, triggered by a test button in the main activity. It should be used as an intermediary activity, whenever authentication is required.

This should not be the case since this would allow others to verify the proof with halfblocks, that have not been signed yet.

Meaning you can make anyone attest anything without them caring.
This is a bug that slipped in due to the bad seperation of halfblocks / complete blocks in
the original trust chain app.

The list of discovered peers on the homescreen now only shows found peers, we need something that makes it possible to select a specific one, instead of the hardcoded one the app selects now (the first one discovered)

To handle naming conflicts we listen for: registration events

We first register as IdentityChain.
Then we find ourselves and ignore ourselves.
Then user two registers, but we also get that registration callback, so we rename ourselves to Identity Chain2.

Then we get the resolution callback from the second phone who has named himself IdentityChain2.

however we think we are now that phone and we drop him as a duplicate.

As the ING states:

The current version of this library implements the whitepaper “An Efficient Range Proof Scheme” by Kun Peng and Feng Bao. As discovered by Madars Virza, Research Scientist MIT Media Lab, this protocol contains a potential security vulnerability.

“The publicly computable value y/t is roughly the same magnitude (in expectation) as w^2 * (m-a+1)(b-m+1). However, w^2 has fixed bit length (again, in expectation) and thus for a fixed range, this value leaks the magnitude of the committed value.”

Therefore, the proof is not zero knowledge. We’re currently evaluating which protocol to use instead in order to provide a secure Zero Knowledge Proof protocol.

This is the same paper as we have implemented and thus we also leak the magnitude of w^2 * (m-a+1)(b-m+1)