Skip to content

/ p2abcengine

Architecture

Jump to bottom
robertre edited this page Jan 19, 2015 · 7 revisions

The implementation of the privacy-preserving attribute-based credentials (ABC) engine demonstrates the feasibility of realizing Privacy-ABC systems and embracing different privacy ABC technologies under a common framework. This framework specifies (in a technology agnostic way) the architecture, policy language and the data artifacts exchanged between the parties. This implementation is being used in a number of real-world pilot applications. This release contains the code for all parties of the pABC system: User, Issuer, Verifier, Inspector and Revocation Authority. Following the layered approach, it provides an application layer interface and services for integrating the engine into existing systems; the functionality for processing requests (issuance, revocation messages, presentation policies, etc) in a technology independent way; the functionality (including user interface) for storing and managing credentials and other artifacts; the cryptographic engine for invoking different cryptographic realizations of pABCs (such as U-prove and IDEMIX); and a smartcard manager for smartcard handling. The implementation also contains an XML schema that specifies the data artifacts created and exchanged during the issuance, presentation, revocation and inspection of pABCs. Overview of the architecture. The architecture of p2abcengine is shown on Figures 1, 2 and 3. ###Figure 1: presenting a token to a verifier

###Figure 2: getting a credential issued by an issuer

###Figure 3: asking an inspector to decrypt a hidden but inspectable attribute

##Short description of the components##

Application layer

User Interface (UI) – User. The UI displays the possible choice of the pseudonyms and credentials to use for issuance/presentation, and shows a human-friendly description of the credentials and presentation token, namely, the information that will be revealed by presenting the token.

Services layer

ServiceHelper (SH) – User, Issuer, Verifier, Inspector, Revocation Authority. The SH constructs and initializes the ABC engine for the different roles, and hides away the complexity from the integration tests.

ABCE layer

IssuanceManager (IM) – User, Issuer. The IM routes the issuance message either to the CryptoEngine or to the PolicyCredentialMatcher.

PolicyCredentialMatcher (PCM) – User. The PCM prepares a list of choices of credentials, pseudonyms, and inspectors for the UI, based on the policies it receives from the upper layer. The PCM provides the CryptoEngine with the user's choice, so that the cryptographic proof generation can start.

PolicyTokenMatcher (PTM) – Verifier. The PTM is responsible for checking if a token received from the user matches a given policy. If it does, it must forward the token or the issuance message to the CryptoEngine. The PTM is also responsible for checking the established pseudonyms and for storing all verified tokens.

Token Manager (TM) - Verifier, Issuer. The TM stores the issuance and presentation tokens that were accepted by the issuer and the verifier respectively. The issuer's token manager also stores a "history" of the issuances, which consists of the list of issuer-specified attributes (including the revocation handle) and the issuance token for all credentials that were issued.

CredentialManager (CM) – User. The CM User is responsible for storing all secret or privacy-sensitive info: credentials, pseudonyms, secrets; and seamlessly integrates the blobstore on the smartcards (via the smartcard manager). It is also responsible for detecting smartcards and getting the PIN of the card from the user. During issuance it downloads and caches the default pictures associated with a credential. During advanced issuance and presentation it provides the PCM with a list of all credentials and pseudonyms currently available in the storage and on all active smartcards.

CredentialManager (CM) – Issuer, RevocationAuthority, Inspector. The CM Issuer is responsible for storing private keys. Note: will be renamed to the PrivateKeyStore in the next release.

Crypto layer

CryptoEngine (CE) – User, Issuer, Verifier, Revocation Authority, Inspector. The CE is responsible for all cryptographic computations for the p2abcengine. The CE transforms the presentation/issuance token description into a cryptographic proof. It orchestrates the different algorithms (Uprove, Idemix) and makes a call to an (external) cryptographic library (Idemix). If there are several possible choices for a particular algorithm, the CE chooses which one to use. The CE creates new pseudonyms, new non-device-bound secrets, new system parameters, and new key pairs with the help of the external cryptographic library (Idemix). It also provides a mechanism dependent and human-friendly proof description (what information is actually revealed) for the UI. The CE updates the non-revocation evidence of credentials. During issuance. the issuer's CE talks with the revocation authority (via the revocation proxy) to generate a new revocation handle and a non-revocation evidence for a new credential.

Storage/Communication components

SmartcardManager (SM) – User. The SM is responsible for interacting with smartcards. It allows the seamless operation of several cards in parallel. The smartcard manager is NOT responsible for detecting new cards or asking for the user's PIN: that is the credential manager role.

RevocationProxy (RP) – User, Issuer, Verifier, Revocation Authority. The RP is responsible for secure communication between the revocation authority and the user/issuer/verifier. It creates, parses and dispatches revocation messages.

KeyManager (KM) – User, Issuer, Verifier, Revocation Authority. The KM is responsible for storing trusted public keys, and if needed procuring these keys in an authenticated manner.

Smartcard (SC) – User, Inspector. The SC stores the secret and sensitive data. The SC can be realized as software or as a physical device. Data Interface allows one to store the credentials, inspector keys and other sensitive cryptographic objects in the card's blobstore. Crypto Interface provides cryptographic functionality for issuance and presentation that is related to a secret stored on the card.

You can’t perform that action at this time.