Authentication Server solution based java provides organizations an unmatched level of access control and flexibility for secured access to online applications along with maintenance of transaction records. The solution is compliant to Interoperability guidelines recently issued by Controller of Certifying Authorities (CCA), Government of India.
Figure 4: Architecture
It should have three main components such as –
- Client side component for
- Entering OTP credentials (web or mobile)
- Creation of digital signature out of the data for authentication
- Server side component for carrying out real time verification and validation of credentials (OTP or digital signatures)
- Admin portal to manage Customers enrollments.
Authentication component does the verification and validation of the user’s credentials that is passed through websigner. The credentials include digital signature and digital signature certificate of the user. It verifies and validates both digital signature and digital signature certificate. Based on the validation result from the validation server the user is either allowed or disallowed access to the application.
Following are the features of Authenticator:
Automatic extraction of public key for verification: When the digital signature is created is using the WebSigner applet, the digital signature in the form signed data is passed to the backend server for validation. Once the signed data received by server, it strips the public key out of the signed data to validate the digital signature computed out of the original data. This is required for data integrity check.
Real time trust chain validation: The digital signature certificate issued to the end entity should be from a valid and licensed certifying authority. There are 7 Certifying Authorities in India who are licensed to issue digital signature certificates. This check is
done to verify that the certificate that is being used is issued by a trusted/licensed CA. So as part of the solution trust store, all trust root certificates of all licensed CAs in India will be provided. During digital signature certificate verification, this is one of the verification criteria that is being carried out. The issuer of the user certificate will be verified with the trust store of Solution . If the issuer is part of the trust store then it passes the validation otherwise rejected.
Multiple CA’s trust root chain enablement for trust chain validation
Real time DSC revocation through OCSP: OCSP is Online Certificate Status Protocol. This is one alternate way of checking the health/revocation status of the certificate. Generally, OCSP validation facility is not provided by all the CAs. But Solution has the provision of validating the revocation status of digital signature certificate through OCSP. Mostly, CRL [Certificate Revocation List] based verification is carried out to check the revocation status of the digital signature certificate. Generally, Revocation of certificate means, when a user feels that his digital signature certificate related keys are compromised or when the user loses his crypto token containing digital signature certificate, then he contacts respective CA for revocation of digital signature certificate issued to him. Based on the verification of the user, the CA revokes the digital signature certificate and publishes the serial number of the digital signature certificate in CRL. The updated CRL is then published on the CA’s website. So Solution during digital signature certificate verification will validate for the revocation status by checking with the respective CRL.
Multiple CA’s OCSP/CRL connection for checking the revocation status of DSC – Every digital signature certificate will contain the CDP i.e. CRL Distribution Point which contains the URL of CRL.
- Automatic DSC validity check
- Data integrity can be checked at any time
- Audit Trail
- Highly flexible and scalable
- Archiving of digital signature for legal recourse
- Verification of digital signatures applied on PDF and XML also
- Data integrity can be checked at any time
Certificate Revocation List (CRL) is a list of certificates (or more specifically, a list of serial numbers for certificates) that have been revoked or are no longer valid, and therefore should not be relied upon.
There are two different states of revocation:
A certificate is irreversibly revoked if, for example, it is discovered that the certificate authority (CA) had improperly issued a certificate, or if a private- key is thought to have been compromised. Certificates may also be revoked for failure of the identified entity to adhere to policy requirements such as publication of false documents, mis-representation of software behavior, or violation of any other policy specified by the CA operator or its customer. The most common reason for revocation is the user no longer being in sole possession of the private key (e.g., the token containing the private key has been lost or stolen).
This reversible status can be used to note the temporary invalidity of the certificate (e.g., if the user is unsure if the private key has been lost). If, in this example, the private key was found and nobody had access to it, the status could be reinstated, and the certificate is valid again, thus removing the certificate from future CRLs.
A CRL is generated and published periodically, after a clearly defined timeframe. A CRL can also be published immediately after a certificate has been revoked. The CRL is always issued by the CA which issues the corresponding certificates. All CRLs have a lifetime during which they are valid;. During a CRL’s validity period, it may be consulted by a PKI-enabled application to verify a certificate prior to use.
Certificate is checked for the validity.
Checks if the user has signed the transaction data using the registered certificate.
Digital Certificate based Authentication
Digital Certificate based authentication in Solution is powered through a client side signing component and server side validation component.
Digital Signature Based Registration
The CRIS users will be assigned his/her role within the Reporting Entity (RE) ecosystem. Once the role is assigned to CRIS users, the users can select the option for ‘Principal Officer’ here. The user shall then be asked to upload the digital signature file.