Skip to content
This repository has been archived by the owner on Mar 30, 2018. It is now read-only.

Attribute Certificate Authority

Jump to bottom
Raul Laprida edited this page May 4, 2016 · 14 revisions

Attribute Certificate Authority

To support Attribute Based Access Control (ABAC) the user has to pass a set of attributes during TCert creation, these attributes will be used during transaction execution to determine whether the user can or cannot execute a specific chaincode. A mechanism to validate the ownership of attributes is required in order to prove if the attributes passed by the user are correct or not. The Attribute Certificate Authority (ACA) has the responsibility of validating attributes and of returning an ACert (Attribute Certificate) with valid attributes.

ACA will have a database to hold attributes for each user and affiliation. This DB will be encrypted.

  1. userID (The id passed by the user during enrollment)
  2. affiliation (The entity which user is affiliated to)
  3. attribute Key (The key used to look for the attribute, e.g. 'position')
  4. attribute value (The value of the attribute, e.g. 'software engineer')
  5. valid from (The timestamp from which the attribute is valid)
  6. valid to (The timestamp to which the attribute is valid)

FLOW

ACA flow

During ECert generation

  1. User requests an ECert to ECA
  2. ECA creates ECert
  3. ECA issues a fetch request (ECert) under TLS signed with the ECA's private key to the ACA.
  4. This request triggers the ACA asynchronous mechanism that fetches attributes' values from the outside world and populates these inside the database. In this step we don't go to the outside world to get the attributes, instead, we will just populate the DN with autogenerated (or from a config file) data_.
  5. ECA continues the ECert creation a returns the ECert to the user.

During TCert generation

  1. When the user needs TCerts to generate a transaction the user requests a batch of TCerts to the TCA, and provides the following:
    • Batch size (i.e. how many TCerts the user is expecting)
    • ECert
    • List of attributes (e.g. Company:IBM, Position: Software Engineer)
  2. TCA sends under TLS a request to ACA to get those attributes: a. RequestAttributes() this request contains:
    • ECert
    • Company: e.g., Hash(IBM)
    • Position: e.g., Hash(Software Engineer)
    • Signed with TCA private key
  3. ACA performs a lookup in his internal DB and replies one of the following messages***:
    • You do not have any of those attributes (error)
    • You have all attributes – returns an X.509 certificate with all those attributes and the ECert public key inside the certificate.
    • You have a subset of the requested attributes. We will still return an X.509 certificate with just the subset.
  4. TCA checks the validity period of the attributes and updates the list by eliminating those that are expired. Then it checks, for case b and c, how many (and which ones) of the attributes the user will actually receive inside each TCert. This information needs to be returned to the user so the user can decide whether the TCerts are useful to him or if he needs to perform further actions (i.e. issue a refreshAttributes command and request a new batch, throw an error or make use of the TCerts as they are).
  5. TCA could have other criteria/rules to update the valid list of attributes a. This will not break any legacy stuff
  6. TCA creates TCerts and populates them with valid attributes
  7. TCA encrypts the attributes with the keys derived from the Prekey tree
  8. TCA returns the batch of TCerts (all TCerts in the batch have the same attributes and the validity period is the same for the entire batch)

*** We are executing an attributes refresh before this step, but once the refresh service is implemented then the user will have the responsibility of keeping his/her attributes updated.

gRPC ACA API

  1. FetchAttributes

    rpc FetchAttributes(ACAFetchAttrReq) returns (ACAFetchAttrResp);

    message ACAFetchAttrReq { google.protobuf.Timestamp ts = 1; Cert eCert = 2; // ECert of involved user. Signature signature = 3; // Signed using the ECA private key. }

    message ACAFetchAttrResp { enum StatusCode { SUCCESS = 000; FAILURE = 100; } StatusCode status = 1; }

  2. RequestAttributes

    rpc RequestAttributes(ACAAttrReq) returns (ACAAttrResp);

    message ACAAttrReq { google.protobuf.Timestamp ts = 1; Identity id = 2; Cert eCert = 3; // ECert of involved user. repeated TCertAttributeHash attributes = 4; // Pairs attribute-key, attribute-value-hash Signature signature = 5; // Signed using the TCA private key. }

    message ACAAttrResp { enum StatusCode { FULL_SUCCESSFUL = 000; PARTIAL_SUCCESSFUL = 001; NO_ATTRIBUTES_FOUND = 010; FAILURE = 100; } StatusCode status = 1; Cert cert = 2; // ACert with the owned attributes. Signature signature = 3; // Signed using the ACA private key. }

  3. RefreshAttributes

    rpc RefreshAttributes(ACARefreshReq) returns (ACARefreshResp);

    message ACARefreshAttrReq { google.protobuf.Timestamp ts = 1; Cert eCert = 2; // ECert of the involved user. Signature signature = 3; // Signed using enrollPrivKey }

    message ACARefreshAttrResp { enum StatusCode { SUCCESS = 000; FAILURE = 100; } StatusCode status = 1; }

Assumptions

  1. An Attribute Certificate Authority (ACA) has been incorporated to the Membership Services temporarily in order to allow us to mandate how to communicate with it.
  2. Currently, we are fetching attributes from the configuration file (membersrvc.yml).
  3. Refresh attributes service is not implemented yet, instead, we are refreshing the attributes in each RequestAttribute invocation.
Clone this wiki locally