Re: [Sat] Views

[Venkatraman Ramakrishna <[e-mail]>]

Forgot to add the link to the confidentiality feature spec within the Cacti project: https://github.com/hyperledger/cacti/blob/main/weaver/rfcs/models/security/confidentiality.md. The model is explained here.

Rama

From: sat <[e-mail]> On Behalf Of Venkatraman Ramakrishna
Sent: Tuesday, April 4, 2023 8:48 PM
To: Rafael Belchior <[e-mail]>
Cc: [e-mail]
Subject: [EXTERNAL] Re: [Sat] Views

The network (i. e. , peer nodes) behind G2 can encrypt the data using the public key of the app within the network behind G1 that requested the data. Neither G2 nor G1 can decrypt the blob, which will be packaged into a view. Quantum-safety concerns
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
The network (i.e., peer nodes) behind G2 can encrypt the data using the public key of the app within the network behind G1 that requested the data. Neither G2 nor G1 can decrypt the blob, which will be packaged into a view. Quantum-safety concerns aside, this should be robust against MITM attacks by either gateway.

Rama

From: Rafael Belchior <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, April 4, 2023 8:40 PM
To: Venkatraman Ramakrishna <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: [Sat] Views

Rama, Thank you for your answers. Inline: A 2023-04-04 09: 26, Venkatraman Ramakrishna escreveu: Rafael, Sorry for replying so late to your questions. >>>Basically you are proposing an additional procedure where the network of G2 enforces
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd

Rama,

Thank you for your answers. Inline:

A 2023-04-04 09:26, Venkatraman Ramakrishna escreveu:

Rafael,



Sorry for replying so late to your questions.



>>>Basically you are proposing an additional procedure where the network of G2 enforces the security regarding proof generation by G2, correct?



The network of G2 is enforcing the security by validating the proof through its consensus mechanism. The proof itself is not being generated by G2 though; it's being generated by G1 requesting its network (like how G1 currently gets lock/burn assertions from its network in SATP). G2 simply communicates the proof to an app or directly submits it to its network for validation.





>>>Are these additional functionalities and changes to the security model desired to be part of the core protocol or particular instantiations of the gateway (eg plugins)?



No, in fact the opposite. The data sharing mechanism we are drafting, and which is implemented in Weaver and Cacti, is even more paranoid than SATP w.r.t. trust in gateways; it does not trust gateways for integrity nor for confidentiality purposes. This is prevent gateways from either (1) tampering with data/assertions and proof, or (2) exfiltrating them to other external parties that the source network, which may be a permissioned network, does not wish to share authentic data and proofs with.



How can we guarantee the second property, confidentiality? In theory, a non-trusted gateway can share information with non-authorized parties.

Rafael



Rama





From: Tecnico Lisboa <[e-mail]<mailto:[e-mail]>>
Sent: Friday, March 24, 2023 4:50 AM
To: Venkatraman Ramakrishna <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: [Sat] Views



Hello Rama, Basically you are proposing an additional procedure where the network of G2 enforces the security regarding proof generation by G2, correct? Are these additional functionalities and changes to the security model desired to be part

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hello Rama,

Basically you are proposing an additional procedure where the network of G2 enforces the security regarding proof generation by G2, correct?



Are these additional functionalities and changes to the security model desired to be part of the core protocol or particular instantiations of the gateway (eg plugins)?



Rafael



On 21 Mar 2023, at 11:26, Venkatraman Ramakrishna <[e-mail]<mailto:[e-mail]>> wrote:

David,



Sorry for the inordinate delay in responding to you on this topic. (At least it was not pressing, as the "view" drafts are presently not within the SATP scope.)



Yes, supporting Views (and View Addresses) is meant to be an additional function for the gateways. I don't recall how well this is sketched out in the drafts I linked to, but there is more work required at G2 in a view request-response protocol. G1 simply communicates messages back and forth within minimal processing (assuming the address of G2 is embedded within the View Address) whereas G2 must submit a request and collect a response from its backing network just like G2 collects evidence for a minting in SATP. I'll try to work this out later once the SATP is more or less crystallized, but I think supporting views and addresses will require relatively minor augmentations to the features that the gateways must anyway implement for SATP.



There is a basic security problem that arises in view request and processing, but the solution for this is built into the end-to-end protocol (https://datatracker.ietf.org/doc/draft-ramakrishna-sat-data-sharing/<https://datatracker.ietf.org/doc/draft-ramakrishna-sat-data-sharing/>) in the following ways:

  1.  The gateway (G2 specifically) is not trusted either for integrity or confidentiality purposes: it simply returns a proof generated by N/W2, and it does not have the authority (or capability) to unilaterally generate a proof that G1 or N/W1 will accept. In this respect, the trust model is different from what the SATP currently assumes.
  2.  The network being requested for a view (N/W2) will run an access control check before sending a response. If N/W2 is a blockchain/DLT, for example, this will be a consensus-driven decision executed through a smart contract. The right "proof" can't be generated unless this access control check is passed by a quorum of honest peers.

I can't think of other security issues. Do you see anything that is not covered here?



Regarding the utility of this procedure: this protocol was created (and implemented) to solve a particular need for the sharing of ledger (or smart contract) state from one permissioned DLT network to another, and we just extracted a common pattern and found a mechanism to handle it. The use cases draft (https://datatracker.ietf.org/doc/draft-ramakrishna-sat-use-cases/<https://datatracker.ietf.org/doc/draft-ramakrishna-sat-use-cases/>) has examples (see Section 3).



Rama



From: sat <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: 13 January 2023 00:54
To: [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] [Sat] Views



Hi Rama: I am referring to your two documents linked in your Oct. 17, 2022 email. In the SATP process the only use I can see for a View is to examine the Digital Asset before it is actually transferred. However, it has been stated in the WG

ZjQcmQRYFpfptBannerStart

This Message Is From an Untrusted Sender

You have not previously corresponded with this sender.

ZjQcmQRYFpfptBannerEnd

Hi Rama:

  I am referring to your two documents linked in your Oct. 17, 2022 email.

In the SATP process the only use I can see for a View is to examine the Digital Asset

before it is actually transferred.  However, it has been stated in the WG meetings that

the details of the Digital Asset and the transfer must be specified in an agreement that

precedes the transfer.  So supporting Views is an additional function for the gateways.



Adding  the processing of Views to the gateways may be useful to support application

communications between Blockchain networks.  But the additional security problems View

processing entails is not justified unless View processing is required for SATP.

We also have a great of work to make SATP a useful protocol in the real world.



David Millman



--
sat mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sat<https://www.ietf.org/mailman/listinfo/sat>


--
-- Rafael Belchior

Ph.D. student in Computer Science and Engineering, Blockchain - Técnico Lisboa
https://rafaelapb.github.io/<https://rafaelapb.github.io/>
https://www.linkedin.com/in/rafaelpbelchior/<https://www.linkedin.com/in/rafaelpbelchior/>