-
Notifications
You must be signed in to change notification settings - Fork 3
Pillar Authentication Framework
The Pillar Project system is built on REST API's that different sub-systems can access for specific services. This article defines the authentication approach used to enforce that only legitimate entities can access these API's and alleviate potentials for denial of service attacks. The API's can be accessed by the wallet application or other components of the system.
- The wallet application can access the the core-wallet-backend API for various white-pages interactions
- The core-wallet backend can access the blockchain explorer API to register wallets for transaction notifications, as well as the offer platform
- The offer engine can access the core-wallet-backend API to verify the authenticity of wallets placing orders on offers.
- And there are potentially many more other similar scenarios.
We decided to use the ECDSA (Elliptic Curve Digital Signature Algorithm) to sign all REST API requests on the the Pillar Project system. This signature guarantees the fact the request is initiated from the holder of a public key, but this should also be combined by a proper provisioning of this public key on the server side to avoid anyone having a public key flooding the server with requests. There are two means for provisioning these public keys on the API provider server:
- Auto-provisioning: could be used by the wallets, auto-provisioning is based on a pre-configured (embedded in the application) private key that the wallets use to sign the first request they send to the core-wallet-backend. The core-wallet-backend knows the associated public key of this embedded private key and can then authenticate the first wallet request to it. The proper public of the wallet/user can then be created on the server and future request to it should use the associated private key to be authenticated.
- Manual provisioning: used by other subsystems that are limited by their number and may require manual approval to be added to the server. This manual provisioning ideally takes place from the web administration interface of the API providing server. Once provisioned all requests from corresponding system can be authenticated by the server.
| method | signature in | signed data in | requester public key |
|---|---|---|---|
| POST | X-API-signature header | request body | request body |
| PUT | X-API-signature header | request body | request body |
| GET | X-API-signature header | query string | not sent, but id information in query string |
- For POST, PUT and GET methods, the requester signs the body part of the request with its private key and sends the signature in the X-API-signature header.
All sub systems of the Pillar project that require cryptographic signing or verification should use the provided authentication SDK. The default cryptographic system used is the Elliptic curve cryptographic curve secp256k1, which is the same used by the Ethereum and Bitcoin blockchains. Hence, the standard cryptographic system on the Pillar Project us the secp256k1 elliptic curve cryptography.
Based on the performances that it exhibits, the implementation (libraries) of choice for elliptic curve cryptography in Pillar Project, is https://www.npmjs.com/package/elliptic, which is enforced by the Pillar Authentication SDK.