Reply to topic  [ 9 posts ] 
PISP: Proposed solution for selective information sharing. 
Author Message

Posts: 7
os: linux
Post PISP: Proposed solution for selective information sharing.
Code:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Title: Private Information Sharing Protocol [P.I.S.P.]
 Draft Version 1.1
  Author: Cannon Ciota <cannon@cannon-ciota.info> Created: 2017-01-21

 Abstract
   Opt in method of using publicly accessible directories,
   particularly namecoin, to list updatable information which
   can only be viewed by authorized entities.

 Motivation
   Primarily intended as a usecase for (but not limited to)
   namecoin as a proposal for a standard allowing entries such
   as contact information i.e. phone numbers, addresses, etc. to
   be listed in a way that allows only authorized entities of the
   entry owner's choice to be able to interpret such information.
   Namecoin, a secure decentralized universal directory, is
   great for binding a multitude of information to a single human
   readable identity in such a way that is not only censorship
   resistant, resilient, and verifiable, but also immune from
   tampering. However, due to the public nature of blockchain,
   what namecoin currently lacks in is a standard way to list
   specific portions of an identity's datastore in a way which
   allows sharing of such information to authorized entities only,
   at the control and discretion of the identity owner.

  Specification
   Each namecoin identity would have listed a public key, or
   pointer to a public key of which the owner's namecoin client
   software has a corresponding private key. This public/private
   keypair would be used for this Private Information Sharing
   Protocol, or P.I.S.P for short.  The public key would be
   denoted in the standard namecoin JSON format using one of two
   forms, embedded or as a pointer. A pointer would be useful
   in scenarios in which a large key is used or if space within
   the namecoin identity's limited size for data is scarce.

Examples

Embedded:
- ---------
 {
   "pisp-pub":"026D3CA82768BC8D8E512EC97DFFAA7CACD52FF913A66911CFF074172F3CB0934E"
}

Pointer:
- --------
{
  "pisp-point":
   {
    "url":"http://cannon-ciota.bit/cannon-ciota_publickey.pisp",
    "fingerprint":"2BB515CD66E74E2845DC6494A5A22879"
   }
}

or optionally we can use a hashsum of the pointed file in case the
file contains more fields than just the public key, to allow for
future extensions to PISP proposed standard.

{
  "pisp-point":
   {
    "url":"http://cannon-ciota.bit/cannon-ciota_publickey.pisp",
    "sha256":"5580aaa1a28145a1ec6c4136af58bdafb23fc13dbdb820ef1da7753e9f744f7d"
   }
}

Contents of cannon-ciota_publickey.pisp:
- ----------------------------------------
 {
   "pisp-pub":"026D3CA82768BC8D8E512EC97DFFAA7CACD52FF913A66911CFF074172F3CB0934E"
}

   Whenever looking up someone‚Äôs PISP public key from their
   namecoin identity, the client would first search for the
   pisp-pub (PISP public key) field, and if not found will proceed
   to search for the pointer field denoted as pisp-point (PISP
   pointer). The PISP pointer field would have the location of the
   public key used for PISP along with the fingerprint, or hashsum
   of the pointed file. The contents of the file mentioned in the
   pointer field would have the public key in the same JSON format
   as would be if directly in the namecoin datastore. Reason why
   is to allow the enabling of any future extensions to the PISP
   proposed standard.  PISP would be opt in. To opt in one would
   simply include a field in their namecoin identity to advertise
   their PISP public key, using either pisp-pub or pisp-point.
   For purpose of demonstration we will assume Alice and Bob both
   have a PISP public key included in their namecoin ID. Bob
   wants his phone number listed in his namecoin identity so
   his contacts can reach him, even if his phone number changes
   frequently. However Bob only wants specific contacts to know
   his current personal phone number, and Bob may want a seperate
   group of contacts to know his business phone number. Bob may
   also have another phone number that is public. And so Bob's
   phone entry in his namecoin ID might look like the following

{
   "phone":
   {
    "pisp":"http://EXAMPLE.URL/bobs-phone.pisp"
   }
}

or for multiple phones

{
   "phone":
   {
    "public":"+99 1234567890",
    "business":
      {
      "pisp":"http://EXAMPLE.URL/bobs-business-phone.pisp"
      },
    "personal":
      {
      "pisp":"http://EXAMPLE.URL/bobs-phone.pisp"
      }
   }
}

   The .pisp file would have the relevant information but
   encrypted to the pisp public key of each of the contacts Bob
   authorizes to have access to such information. To prevent Bob's
   connections from being revealed each encrypted data snippet
   (one per contact) would not list public keys, only encrypted
   data. And so any contact would have to attempt to decrypt
   each snippet within the .pisp file until it finds a snippet
   it is able to decrypt. As a result outsiders cannot determine
   whom Bob's connections are, only the number of authorized
   connections. One mitigation to advertising number of authorized
   contacts would be to pad the .pisp file with decoy snippets. As
   a precaution against bruteforcing data to matching cypher text
   each snippet would also include a random salt unique for each
   snippet before encrypting.  And so if Bob wanted his number
   visible to Alice, he would include his current phone number
   (with a random salt) encrypted to Alice's listed PISP key and
   include the encrypted snippet into his .pisp file referenced
   in his namecoin identity. Alice's addressbook app on her phone
   would automatically lookup Bob's number from his namecoin ID,
   after seeing it as not publicly viewable but protected by
   PISP it would then use Alice's private PISP key to attempt to
   decrypt each snippet in Bob's .pisp file until successfully
   decrypting a snippet which then reveals Bob's number to Alice.
   If Bob's PISP protected phone number is not visible to Alice,
   after finding no decipherable snippet the app can tell Alice
   "not authorized to view this information". Alice then can
   hit a button on her app such as "request contact info for
   Bob's phone" which would send a request to Bob through a
   communications channel (such as publically listed email
   address or bitmessage address in Bob's namecoin ID) which
   would request Bob to include Alice as an authorized contact
   for that specified piece of information (in this case, Bob's
   personal number). The request would be signed by Alice's
   PISP key before being encrypted to Bob's PISP key to protect
   from spoofing and to maintain confidentiality of both the
   contents and identity of requester, to anyone who is not Bob.
   Upon receiving such request, Bob can choose to either allow
   Alice access or ignore such request. Because denying access
   is passive rather than active unlike granting access, this
   provides plausible deniability for Bob. If Bob chooses to
   not allow Alice as an authorized contact to view his number,
   he simply does nothing which provides plausible deniability
   of Bob's decision as Alice would not know if Bob explicitly
   chose to not to acknowledge request, or if Bob simply just
   forgot, or did not read the request.

//EOF
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYiHEeAAoJEAYDai9lH2mwo4wQAI9gvQdGqypsBWXa8F7tdjvY
iKBzcD1Xhhlva2Tl8FPGeJ9XrF+8xair1bu/wYjNq0L6Pnj5x2OO5zmkpXlTpuwk
aIzgqOeDKJIEPGNPu1eLQcsNuYNlwF0I8eTh1uC02a51wCmCyK2K0gnCzjJR6B3n
8hu0yBnnPqrYxN5/mP0efYrYHIrYQ+qrditvat4xHFRQPgoNuQHbah43yabDmBSD
9eqAO9Tzm09APx7mfgDSTNswE+DaF2J+CguNKiPuUhmznuAGGaAHj7Rjx/pjR6uc
oxyw8EkLWCTQvTGqpnNz2NyDRMFwjjj6lfqJ7dk4OAPfcIDnCcqaGp6iKA7K7M4d
VLgl6KIYkZheKRBqBNKPKcbmEeQvaqW5k38bgDERMF918LnPwSzVRbko3RVdAU8i
mNLfyIH5GOxFGVEWVK4x0Z7S9Mzr+PnGak8QPQ9HdzcvInq9BgwyIv4Mb4+RQoVb
FU0L0amvAo4FfK5K12FECilR9TK9hb1azUhk2BBEgzrkcY1kr6J8a0bpvWUP4ODC
uVB0FCvieiQU8PWYolU4BobOBR7KpTeQJZCv33RXGWZahpFfcxDWfEj0F97k8Qvl
T9X5Fn2w7B6gERrzmxbVj+aErlhL9UAvlhORGW968zfK2GDtkAPxhTOZN9q2I7Pq
FpAUdjmGzztdZm3goAKG
=K+r6
-----END PGP SIGNATURE-----


Wed Jan 25, 2017 10:15 am
Profile

Posts: 307
Post Re: PISP: Proposed solution for selective information sharin
Very interesting application use-case of the Namecoin blockchain. This could be a solution to the problem of how to control read-access to individial parts of one's public profile on the blockchain.
I haven't looked at the security implications of the intended protocol, yet. If there are any security issues then they should be easily solvable, though.

Have you already created an up-to-date example for a JSON record containing a pisp field on the blockchain? Your existing id records (i.e. id/cannon) contain malformed JSON data: the outermost bracket is missing. Furthermore, the many linefeed characters ("\n") may cause JSON parsers run into problems in the future (although currently allowed by the JSON specs).


Wed Jan 25, 2017 3:23 pm
Profile

Posts: 1817
os: linux
Post Re: PISP: Proposed solution for selective information sharin
Hi Cannon,

Very interesting proposal. Apologies for my delayed response.

A few comments:

What algorithm is used for the fingerprint field? How could that algorithm be changed later? (You use both "sha256" and "fingerprint" as JSON fields here, apparently for similar purpose. SHA256 hashes of public keys are commonly called fingerprints.)

What protection is there against the names of phone numbers being revealed (the "business" and "personal" labels in your example)? I suspect that attacks could be mounted that perform metadata analysis against these labels (including when they change). Maybe encrypt them as well, so that Alice has to try to decrypt each phone number and when she finds one that is decryptable, she learns the label too?

What protection is there against the number of phone numbers being revealed? I suspect that using decoys might not be sufficient to hide it against statistical attacks. It might be interesting to use a merkle tree for this. I can't think of a way to do so without requiring Bob to tell Alice the merkle branch proof when he grants her access, though.

Finally, I'm honestly not very familiar with what existing proposals exist in this space. I would be surprised if no one has previously tried to solve this use case. Any idea?

Cheers!

_________________
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5


Sun Jan 29, 2017 8:03 am
Profile

Posts: 7
os: linux
Post Re: PISP: Proposed solution for selective information sharin
biolizard89 wrote:
What algorithm is used for the fingerprint field? How could that algorithm be changed later?

No specific algorithm used in the examples of this draft proposal. That could be determined with more discussion as for what to use for fingerprint fields and keys.

biolizard89 wrote:
How could that algorithm be changed later?

hmm for keys maybe add a label to the key entry to indicate what type it is? Or I wonder how easily a client software could detect what is being used.

biolizard89 wrote:
(You use both "sha256" and "fingerprint" as JSON fields here, apparently for similar purpose. SHA256 hashes of public keys are commonly called fingerprints.)

I used "sha256" and "fingerprint" separate on purpose to distinguish between their purpose. The idea is that "fingerprint" is referring to hash of the key, whereas "sha256" is referring to the hash of the pointed data which may contain more than just a key.

biolizard89 wrote:
What protection is there against the names of phone numbers being revealed (the "business" and "personal" labels in your example)? I suspect that attacks could be mounted that perform metadata analysis against these labels (including when they change). Maybe encrypt them as well, so that Alice has to try to decrypt each phone number and when she finds one that is decryptable, she learns the label too?

That is a good point. I like the idea of ability to encrypt label also so long as it is optional. In the example I used I have the labels of the phone entry (business, personal, etc...) public with the contents being a pointed to encrypted snippets. However if I wanted to encrypt a label also, I could just have those hidden labels encrypted within the data snippets as you mentioned, in my "phone" entry of my namecoin ID I would include a referenced .pisp file with a blank label. The entry that contains no label would indicate that it is for purposes of storing phone numbers with corresponding encrypted labels.

biolizard89 wrote:
What protection is there against the number of phone numbers being revealed? I suspect that using decoys might not be sufficient to hide it against statistical attacks. It might be interesting to use a merkle tree for this. I can't think of a way to do so without requiring Bob to tell Alice the merkle branch proof when he grants her access, though.


Would need to take some thinking to determine possible statistical attacks and counter measures.

biolizard89 wrote:
Finally, I'm honestly not very familiar with what existing proposals exist in this space. I would be surprised if no one has previously tried to solve this use case. Any idea?

I am curious about other alternative solutions. This is a huge need especially for public directories, I have not seen anything yet for this use case hence why I typed this up.

_________________
Cannon
Namecoin ID: cannon


Tue Feb 07, 2017 7:25 pm
Profile

Posts: 7
os: linux
Post Re: PISP: Proposed solution for selective information sharin
I think I forgot to mention in the draft, that obviously all .pisp files or any referenced external data should be either signed and/or hashsum of it included in the namecoin ID for verification purposes.

_________________
Cannon
Namecoin ID: cannon


Tue Feb 07, 2017 7:30 pm
Profile

Posts: 7
os: linux
Post Re: PISP: Proposed solution for selective information sharin
cassini wrote:
Have you already created an up-to-date example for a JSON record containing a pisp field on the blockchain? Your existing id records (i.e. id/cannon) contain malformed JSON data: the outermost bracket is missing.

Thanks. I will be updating it soon and when I do so will include an embedded pisp example.

cassini wrote:
Furthermore, the many linefeed characters ("\n") may cause JSON parsers run into problems in the future (although currently allowed by the JSON specs).

If you are referring to the post I only formatted that way to make it easy for humans to read. If you are referring to my namecion ID then yes it will get corrected soon.

_________________
Cannon
Namecoin ID: cannon


Tue Feb 07, 2017 7:44 pm
Profile

Posts: 1817
os: linux
Post Re: PISP: Proposed solution for selective information sharin
Would you like me to ask Joachim from Jolocom to take a look at this proposal and give feedback? I met Joachim at DWS 2016; Cassini subsequently met him at GETD#4. It seems like a topic for which Joachim may be familiar with prior work (or perhaps the lack thereof).

_________________
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5


Wed Feb 15, 2017 2:44 pm
Profile

Posts: 7
os: linux
Post Re: PISP: Proposed solution for selective information sharin
biolizard89 wrote:
Would you like me to ask Joachim from Jolocom to take a look at this proposal and give feedback? I met Joachim at DWS 2016; Cassini subsequently met him at GETD#4. It seems like a topic for which Joachim may be familiar with prior work (or perhaps the lack thereof).


Yeah sure, would be interesting to see what his input is on this, or if there are other currently working things of similar nature.


Perhaps may want to refer him to this forum link due to the proposal being very draft version. (Hence why I posted it here for further input). And since comments on this thread mentions something I forgot to include in the draft, that all .pisp files or any referenced external data should be either signed and/or hashsum of it included in the namecoin ID for verification purposes. Along with more clarifications brought forth in this thread.

Unless you think we should first update the draft write up before forwarding to him.

_________________
Cannon
Namecoin ID: cannon


Sat Feb 18, 2017 12:00 am
Profile

Posts: 1817
os: linux
Post Re: PISP: Proposed solution for selective information sharin
cannon-c wrote:
biolizard89 wrote:
Would you like me to ask Joachim from Jolocom to take a look at this proposal and give feedback? I met Joachim at DWS 2016; Cassini subsequently met him at GETD#4. It seems like a topic for which Joachim may be familiar with prior work (or perhaps the lack thereof).


Yeah sure, would be interesting to see what his input is on this, or if there are other currently working things of similar nature.


Perhaps may want to refer him to this forum link due to the proposal being very draft version. (Hence why I posted it here for further input). And since comments on this thread mentions something I forgot to include in the draft, that all .pisp files or any referenced external data should be either signed and/or hashsum of it included in the namecoin ID for verification purposes. Along with more clarifications brought forth in this thread.

Unless you think we should first update the draft write up before forwarding to him.


I've sent Joachim a link to this forum thread.

_________________
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5


Sun Mar 19, 2017 3:16 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 9 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by STSoftware for PTF.