Please enable JavaScript.

Coggle requires JavaScript to display documents.

CS5900-DSP (Lecture 1 (Topics (Data security requirement, Policies: DAC,…

- - - - Insider Leakage
  - - - Confidentiality
      - Integrity
        
        Not necessarily zero modification, but are all under some assumptions and are consistent, meaningful, and useful.
        
        By authorized parties
        
        By authorized process
        
        In acceptable ways
      - Availability
  - - - (1) Definition of data transparency
      - (2) Dimensions or feathers related to the data transparency.
        
        Business secretes
        
        Access control
        
        Accuracy
        
        Transparency
      - (3) What are the technological challenges to protect the data transparency?
        
        ZKP
        
        Differential privacy
        
        Identity anonymity
- - - - :red_flag:Purdue Oracle Access
      - QUESTIONS
        
        How the different models works?
        
        Advantages: pros and cons for different use cases?
      - Useful commends
        
        CONNECT / DISCONNECT
        
        HOST
        
        DESCRIBE
        
        HELP
        
        EXIT
        
        SET SERVEROUTPUT ON
        
        DBMS_OUTPUT.PUT_LINE()
        
        /
        
        Terminating the PL/SQL block by putting the forward slash in the single line with only this sign!
      - C4: SQL Tutorial
        
        Basic operations
        
        INSERT INTO table_name (column_list) VALUES (values_list)
      - Oracle DB Security Guide
        
        The main goals
        
        Designing and implementing security policies to protect the data of an organization, users, and applications from accidental, inappropriate, or unauthorized actions
        
        Creating and enforcing policies and practices of auditing and accountability for inappropriate or unauthorized actions
        
        Creating, maintaining, and terminating user accounts, passwords, roles, and privileges
        
        Developing applications that provide desired services securely in a variety of computational models, leveraging database and directory services to maximize both efficiency and ease of use
    - - :red_flag:With the Hyperledger Papers (Doc. Analysis)
        
        Decentralization
        
        Collaborative
        
        Append-only (very different from database)
        
        Except special (very special cases)
        
        Mechanisms
        
        the members of a Hyperledger Fabric network enroll through a trusted Membership Service Provider (MSP)
        
        In most cases, chaincode interacts only with the database component of the ledger, the world state (querying it, for example), and not the transaction log.
        
        Consensus
        
        PBFT
        
        Kafka
        
        SOLO
        
        In addition to the multitude of endorsement, validity and versioning checks that take place, there are also ongoing identity verifications happening in all directions of the transaction flow. Access control lists are implemented on hierarchical layers of the network (ordering service down to channels), and payloads are repeatedly signed, verified and authenticated as a transaction proposal passes through the different architectural components. To conclude, consensus is not merely limited to the agreed upon order of a batch of transactions; rather, it is an overarching characterization that is achieved as a byproduct of the ongoing verifications that take place during a transaction’s journey from proposal to commitment.
        
        Shared of clear power of collaboration
        
        HLF Model Structure
        
        Identity
        
        Security & Membership Service
        
        MSP
        
        Peers
        
        Assets
        
        Chaincode
        
        Ledger Features
        
        Consensus
        
        Blockchain Network
        
        :checkered_flag: Identity
        
        Build for all the peers, orderer, etc. by PKI and x.509 digital certificate.
        
        PKI provides list of identities, and Membership Service Provider (MSP) tell which ones are accepted.
        
        Root CAs, Intermediate CAs and chain of trust
        
        Certificate Revocation List
        
        Fabric CA
        
        Server and client, easy to set up.
        
        MSP and .pem comes into play in the server side.
        
        :red_flag:Membership
        
        Local MSP
        
        Channel MSP
        
        MSP folder
        
        Root CAs
        
        Intermediate CAs
        
        Organization Units
        
        Similar to the legal person role for a company
        
        Administrators
        
        Revoked Certificates
        
        Signing Certificates
        
        Keystore (Private Keys)
        
        TLS Root CAs
        
        TLS Intermidiate cAs
      - How to break the HLF system?
        
        DDoS
        
        Threatening Model
        
        Attacks
        
        Defense
      - Peers
        
        Holds ledgers and chaincodes, and the patterns are not restricted. Which means that the number of ledger can chaincodes on each of them can range from 0 to any positive number theoretically.
        
        Peers never consult with other peers in order to respond to a query from an application. Applications can, however, connect to one or more peers to issue a query; for example, to corroborate a result between multiple peers, or retrieve a more up-to-date result from a different peer if there’s a suspicion that information might be out of date. In the diagram, you can see that ledger query is a simple three-step process.
        
        The role of channel: provide a private and secure way for peers to communicate
        
        Peer provides control point to access to, and manage for, channels (like a group of friends talk secretly)
        
        :red_flag: How the Hyperledger Network achieve decentralization?
        
        You can see that (other than the ordering service) there are no centralized resources — in the example above, the network, N, would not exist if the organizations did not contribute their peers. This reflects the fact that the network does not exist in any meaningful sense unless and until organizations contribute the resources that form it. Moreover, the network does not depend on any individual organization — it will continue to exist as long as one organization remains, no matter which other organizations may come and go. This is at the heart of what it means for a network to be decentralized.
        
        Even though the ledger in a network reaches consensus, but all the peer logic of presentation and applications call be different, which all controlled by the organization that deploy and contribute them.
        
        The peers are every thing/resource to a Hyperledger network
        
        :red_flag: How is the identity/role assigned to each peer?
        
        Peers have an identity assigned to them via a digital certificate from a particular certificate authority. You can read lots more about how X.509 digital certificates work elsewhere in this guide but, for now, think of a digital certificate as being like an ID card that provides lots of verifiable information about a peer. Each and every peer in the network is assigned a digital certificate by an administrator from its owning organization.
        
        Mapping the username/publicKey to other user information (identity)
        
        The X.509 is a common way for identity and PK linking management.
        
        :star: New opportunity for ID assignment and proof
        
        X.509 (digital certificate) is like an ID card that provides lots of information about an identity linking from it's public key. What if we can use ZKP to proof the validity of the identity in an organization, but not who it is, nor any other information that was used to proof identity?
        
        PK
        
        Data Payload
        
        Certificate Authority
        
        Certificate List
        
        Revocation List
        
        First be familiar with all the endorsement policy and org. ID distribution method (TLS)
        
        We give a name to every entity that interacts with a blockchain network using an identity — a principal.
        
        The Identify certificate of an entity determines the ownership, and not the physical holding location (cloud or some where doesn't matter)
        
        The life cycle of adding a block
        
        If a application want to update something on a public ledge of the network, it need to
        
        1) Propose proposal to the endorsement peers and wait for the signed certificated response;
        
        2) Once the application got the certificated response from enough endorsement peers, it sends the proposal with certificates to the orderer in the network, which will talk multiple proposals from different applications. It will not necessarily pack all the proposals in the order of receiving them, but instead marshall them in any order and mark these as final order for these unique transactions when either the block reach desired size, or reaches the maximum elapse time;
        
        3) The orderer distribute the new block to each peer in the network, and the peers will validate each transaction in assigned order with exactly the same mechanism. If a transaction is invalid, then it won't add that transaction to the ledger, and, instead of delete it, mark it for future auditing.
        
        My questions are:
        
        If the result in step (1) from the chaincode in the endorsing peers are non-deterministic (cannot reach consensus?), what can the endorsement peers do to reach consensus for a legitimate proposal?
        
        In the step (2), unlike in public blockchain like BTC or ETH, Hyperledger only record any transaction once in the whole network, thus hard fork is impossible in Hyperledger. But what if something that really hurt the public good of parties in this blockchain network happened, e.g. DAO? Is there any way to mitigate the result other than hard fork in here?
        
        In step (3), what is the validation rule used by each peer when they check each transaction? Are they shared by all the peers? Who distributed it? And which file is that in the HLF root directory/docker?
        
        Thanks a lot for your help!
      - :explode: Questions
        
        How endorsement works?
        
        What's the difference and similarity between GRAND and REVOKE (pros and cons)?
        
        Give it a try
      - :star: Private Data
        
        Processing (Transaction flow) of Private Data
        
        Using the transient field to send private data in a proposal to the endorsing peers
        
        Endorsing peers store the private data in transient data store
        
        The endorsing peers send the certificate back with the hash of the private data, and the data itself.
        
        How the endorsing peers process the private data with out leakage (They only choose the once that are allowed to process the data)?
        
        Writer policy
        
        The writing policies are defined when the channel is built
        
        The validation include checking endorsement policy satisfaction, and the integrity of each block history after uploading.
        
        :red_flag: Here we use the Private Data Collection to define the policies to data purge (number of blocks all the private data to live, no matter commit or not), access control, the private collection distribute policy org. (the organizations that can be chosen for endorsement).
        
        What are the crypto used by HLF for channel?
        
        Ursa project
        
        3 more items...
        
        Send everything to the orderer, and then peers can validate the transaction just by the HASH?
        
        Why just by HASH
        
        For the purpose of verification of integrity by the authenticated peers that can read the private data.
        
        The last step of commitment is by the authorized peers, i.e. the peers with right to see the private data. If they already have the private data stored in their transient data store they can just use it and commit, otherwise they will need to pull the private data from another peer first.
        In the time of validation, the private data is moved to their local private database (sideDB), and after that the private data will be removed from the transient data store.
        
        What are the protection mechanism HLF used for private data guarantee? (Enc?)
        
        ALLOW: endorse, commit, query private data after V1.2
        
        SideDB (private database)
        
        HASH of the data for transaction records
        
        Used for future revealing for the dispute settling and assets transferring
        
        Private data collection
      - Gossip Data Dissemination Protocol
        
        Functionalities
        
        Bringing all the nodes up to date, and speed up sync on block and ledger data in channel
        
        MSP manage the live and offline status of peers, and their memberships
        
        Help new nodes to sync
        
        Security of communication
        
        In channel: (Authentication) Using the CA certificate to sending and receiving message from nodes (X.509), and also relying on TLS level for P2P (security) communication.
        
        Ledger blocks are signed by ordering server, and then delivering to the lead node in a channel.
        
        Lead nodes (for bandwidth efficiency in a channel, so shouldn't be too much)
        
        Dynamic (voting)
        
        Static (admin select)
        
        External and internal endpoints
        
        Internal endpoints in an organization: to know each peers
        
        External node of an organization: help the anchor peer to learn peers in this organization
        
        Anchor peer: know all the organization peers (at least one in each org.)
      - Client Identity Chaincode Library
        
        CID
        
        MSPID
        
        Attibutes
        
        Assert Attributes
        
        Update Attributes
        
        X.509 Certificates
      - Fabric CA
        
        Fabric CA Client
        
        Configuration setting
        
        Precedences:
        
        CLI flags (modify both the env. and conf. file)
        
        Env. variables (just modify the env. and not the config. file)
        
        Configuration file
        
        Relative path (relative to the configuration directory) and absolute path
      - Endorsing Policy
      - MSP
      - Read Write Sementics
      - :red_flag: Leger
    - - The Oracle DB Security Guide
      - Hyperledger Fabric Latest Doc