Get 20M+ Full-Text Papers For Less Than $1.50/day. Start a 14-Day Trial for You or Your Team.

Learn More →

Using Privacy Enhancing and Fine-Grained Access Controlled eKYC to implement Privacy Aware eSign

Using Privacy Enhancing and Fine-Grained Access Controlled eKYC to implement Privacy Aware eSign Advances in Science, Technology and Engineering Systems Journal ASTES Journal Vol. 4, No. 4, 347-358 (2019) ISSN: 2415-6698 www.astesj.com Special Issue on Advancement in Engineering and Computer Science Using Privacy Enhancing and Fine-Grained Access Controlled eKYC to implement Privacy Aware eSign Puneet Bakshi , Sukumar Nandi Department of Computer Science and Engineering, Indian Institute of Technology, Guwahati, 781039, India A R T I C L E I N F O A B S T R A C T Article history: eSign is an online electronic signature service which is recently gaining Received: 28 May, 2019 more prominence in India. eSign is based on two online services from Accepted: 23 July, 2019 UIDAI, viz. a viz., Aadhaar based authentication and retrieval of resident’s Online: 19 August, 2019 eKYC information after taking his/her consent. With increased adoption of Aadhaar based services, privacy of user data has become more and Keywords: more important. Present method of taking boolean consent from resident eSign through non-UIDAI entity may not be acceptable for two main reasons, first eKYC is that the consent does not include in itself a proof from resident that the Electronic Signature consent is indeed taken from him/her and second is that the resident may Privacy wish to have better privacy and fine grained access control rules to access Access Control his/her eKYC data. Bakshi et.el have introduced a mechanism to improve Authentication amortized performance of eSign using a digital access token. In this work, Token the digital access token is enhanced to include Privacy Enhancing and Fine- BAN logic Grained Access Control (PEaFGAC) Statements for facilitating Privacy Aware eSign. These tokens can be used by other entities to access eKYC data of the resident with better access controls enforced by the resident. This paper briefly describes the present model of eSign, the earlier proposed model of eSign followed by the proposed model of Privacy Aware eSign. The proposed model of Privacy Aware eSign is also analyzed using BAN logic assuming Dolev-Yao security environment. 1 Introduction Unique Identification Authority of India (UIDAI) and receive a 12-digit identity number called Aadhaar [1] [2]. As part eSign is an online electronic signature service in India which of the enrollment process, resident needs to provide infor- is being promoted by Government of India as part of its Dig- mation about his/her identity and address to UIDAI such ital India Initiative. As opposed to traditional dongle based as Name, Date of Birth, Address, Phone number, Email-id, electronic signature, eSign provides benefits such as less Biometric (fingerprint-scan, iris-scan) etc. The process of cost, no manual authentication, no requirement of special obtaining this information from the end user is known as hardware device and no requirement for the end user to keep Know Your Customer (KYC) and is initially introduced by any key secret. With the passage of Information Technology Reserve Bank of India (RBI) for financial banks [3]. Tradi- Act (ITA-2000), an electronically signed digital document tionally, this process involves submission of a self-attested is considered equivalent to a handwritten signed paper doc- physical form along with necessary physical documents, fol- ument. In India, eSign is being regulated by Controller of lowed by verification and approval by receiving organization. Certifying Authority (CCA) and is being operated by cer- eKYC is an online service which facilitates completion of tain designated empaneled agencies known as eSign Service KYC process electronically. eKYC has some significant Providers (ESP). ESP provides its services to application benefits over traditional KYC, eKYC eliminates submission specific agencies known as Application Service Providers of physical documents by customer, is faster and is less error (ASP). ASP provides eSign service to the end users. eSign is prone. UIDAI’s eKYC service facilitates a third entity to governed by Public Key Infrastructure (PKI) which is further retrieve resident’s identity, address and other details after governed in legal matters by the national legislature of the taking explicit consent and authorization from the resident. country. To avail eSign service, a resident needs to enroll with With increased adoption of Aadhaar based identification, Corresponding Author: Puneet Bakshi, IIT Guwahati, b.puneet@iitg.ac.in www.astesj.com 347 https://dx.doi.org/10.25046/aj040443 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) fXg X is signed by key Y many online services are now using Aadhaar based services S K Symmetric key of entity Y and with its such wide adoption, privacy of user data has be- S K Symmetric key shared by entities Y and Z. Y Z PR Private asymetric key of entity Y come even more important. Although Aadhaar based eKYC PB Public asymetric key of entity Y service provides access to eKYC data only after taking an R Resident explicit consent from the resident, this way of taking consent AS P Application Service Provider ES P eSign Service Provider from resident has two shortcomings. First is that the consent i U I DAI Unique Identification Authority of India is taken by non-UIDAI entity and does not encode in itself a I D , I D Identities of R , AS P and ES P R AS P i i i i i proof from resident that the consent is indeed given by the I D ES Pi T I D ; T I D Unique transaction identifiers generated resident. Second is that providing a boolean consent is too ES Pi AS Pi by ES P and AS P i i broad, either an unconditional access is given to the whole PW Password of R for login to AS P portal R i i eKYC information or no access is given at all. A resident AadhaarNo Aadhaar No of R R i C Cookie associated with R ’s logged-in R i may wish to have a better privacy enhancing fine-grained i session, assigned by AS P access control to his/her eKYC data. Resident may wish PR , PR Private keys of R browser, AS P , ES P B AS P i i i i i to define a privacy and access control policy dictating the PR , PR and U I DAI ES Pi U I DAI PB , PB Public keys of R browser, AS P , ES P B AS P i i i i i scope of information which can be provided, the purpose PB , PB and U I DAI ES P U I DAI for which the information can be provided and recipients n nonces such as n1 , where  is any integer ! AS P to whom the information can be provided. For example, a and ! can be R , AS P , ES P or U I DAI i i i DataR (DataA ; Intermediate data in plaintext to be send by i i resident may wish to disclose only his/her name and address, DataE ; DataU ) R (AS P , ES P , U I DAI) i i i i i only for electronic signature purpose and only to a specific S ignR (S ignA ; fH(DataR )g i i i PR Ri eSign Service Provider. S ignE ; S ignU ) i i consent Consent from resident whether his/her eKYC use ekyc In [4], the author explained two limitations of present eS- can be used ign model. The first limitation is that the eKYC data access consent Consent from resident whether a digital access genuse at token can be generated for later use reflects a restrictive self-only, full-resource and unlimited License License for AS P (ES P ) to use services AS P i i access control. Author pointed out that a resident may wish License from ESP (UIDAI) ES P to have a better access control mechanism which allows third M Message (in plaintext) to be eSign DS C Digital Signature Certificate generated for entities to access part of a resource which is to be used for Ri Mi message M for resident R i i a specific purpose and for a limited time period. The sec- fMg eSigned message (by R ) through ES P eS ign R ES P i i i i ond limitation is that for each eSign request, resident has H() One way cryptographically secure hash fn k Concatenation operator to authenticate itself each time and to include the authenti- XOR operator cation proof in each such request. Author pointed out that if a resident needs to eSign multiple times, time taken by Figure 1: Notations used in this paper initial authentication phase will be a major bottleneck. The author proposed that amortized performance of eSign can be 2 Related Work improved using digital access token which encodes in itself the authentication proof and other information such as how Digital tokens are increasingly being used in many cryptog- many eSign requests can be made using this token and the raphy related applications to achieve varied objectives. expiry time of the token. U-Prove [5] is an identity management solution based This paper is an extension of [4] and the digital access on blind signatures [6] which uses digital tokens to achieve token is enhanced to implement Privacy Aware eSign. Our objectives of privacy and anonymity. U-Prove consists of main contribution in this paper is to introduce a method to two protocols, viz., issuance protocol and presentation pro- implement Privacy Aware eSign using Privacy Enhancing tocol. In issuance protocol, identity provider issues digital and Fine-Grained Access Control (PEaFGAC) Statements. token to the subscriber which (s)he can later present to the A resident can encode these statements in digital access to- verifier in presentation protocol so that the service provider ken for better access to his/her eKYC data. This token can can grant resource access to the subscriber. A U-Prove to- be provided to third entities so that they can present this to- ken consists of a unique token identifier, a public key of the ken for claiming protected resource from UIDAI. This paper token which aggregates information in the token, a token also presents security analysis of the proposed scheme using information field which encodes token specific information, Burrows-Abadi-Needham (BAN) logic. The analysis shows a prover information field which is opaque to the issuer, is- that in the proposed scheme, even if the network is unreli- suer signature on all the other token contents and a boolean able, the exchanged information is reliable and is secured value which indicates whether the token is protected by a against eavesdropping. device. U-Prove uses digital tokens e ectively by encoding The remainder of this paper is organized as follows. Sec- necessary information in it in cryptographically secure way tion 2 presents related work. Notations used in the paper to achieve objectives such as privacy and anonymity. are reported in figure 1. Section 3 presents Aadhaar based OAuth2 [7] is an authorization framework which allows eKYC service. Section 4 presents eSign version 2.0 model. delegation of access to protected resources to a third party Section 5 presents eSign model proposed in [4] to improve by using digital tokens referred to as access tokens. Access amortized performance of eSign. Section 6 presents pro- tokens are issued to Clients by Authorization Server after posed Privacy Aware eSign model using privacy enhancing taking permission from Resource Owner. An access token and fine-grained access controlled eKYC. Section 7 presents can be of two types, viz., a bearer token and a MAC token. formal security analysis of the proposed model using BAN A bearer token is an opaque string which can be used to logic and finally section 8 concludes the paper. claim access to a resource by any entity who presents the www.astesj.com 348 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) token. A MAC token is essentially a shared symmetric key scope, purpose and recipient. which is used to sign a challenge by the client to prove its possession of the token to authorization server. OAuth2 uses URL: digital tokens e ectively for access delegation and is used https://<host>/kyc/<ver>/<ac>/<uid[0]>/<uid[1]> by many organizations for data sharing. /<asalk> Bitcoin [8] is a decentralized digital currency which can be transacted over peer-to-peer bitcoin network. A bit- Input Data: coin network is composed of cryptographically secure linear <Kyc ver="" ra="" rc="" lr="" de="" pfr=""> chains of blocks with each block containing a header and <Rad>base64 encoded fully valid Auth XML for a collection of transactions. A transaction is essentially a resident digital token that changes ownership of bitcoins from one </Rad> entity to another. Each transaction in bitcoin network is </Kyc> broadly composed of three parts, viz., input, output and Response Data: amount. Input refers to the previous owner of the bitcoins, <Resp status="" ko="" ret="" code="" txn="" ts="" output refers to the new owner of the bitcoins and amount err=""> encrypted and base64 encoded KycRes refers to the amount of bitcoin that is transacted. Bitcoins element uses cryptographically secure digital information containers </Resp> (similar to digital tokens) e ectively for the realization of digital currency. <KycRes ret="" code="" txn="" ts="" ttl="" actn="" Although Attribute Based Encryption (ABE) is also err=""> <Rar>base64 encoded fully valid Auth response evolved to protect privacy of user data, it is based on Identity XML for resident Based Encryption (IBE). An agency may not shift from PKI </Rar> to IBE framework for a number of reasons. <UidData uid=""> <Poi name="" dob="" gender="" /> <Poa co="" house="" street="" lm="" loc="" 3 Aadhaar based e-KYC service vtc="" subdist="" dist="" state="" (v2.1) country="" pc="" po=""/> <LData lang="" name="" co="" house="" Aadhaar based eKYC service is available to general citizens street="" lm="" loc="" vtc="" only through certain empaneled agencies such as eSign Ser- subdist="" dist="" state="" country="" pc="" po=""/> vice Provider (ESP) and the infrastructure network is secured <Pht> base64 encoded JPEG photo of the by certain designated agencies known as Authentication Ser- resident vice Agency (ASA) and KYC User Agency (KUA). eKYC </Pht> service is hosted as a stateless REST based web service <Prn type="pdf"> base64 encoded signed over HTTPS and the details are sent as input data encoded Aadhaar letter for printing in XML. Figure 2 depicts Aadhaar’s eKYC webservice as </Prn> specified in eKYC v2.1 specification [9]. The specifica- </UidData> tion provides following information about element rc which <Signature/> represents the resident consent. </KycRes> “rc – (mandatory) Represents resident’s explicit consent for accessing the resident’s identity and address data from Aadhaar system. Only valid value is “Y”. Without explicit Figure 2: Aadhaar’s eKYC 2.1 API consent of the Aadhaar holder application should not call this API [9].” 4 Present model of eSign in India As can be seen from the specification, rc is a boolean con- sent and assumes that it has been transferred from resident In eSign version 2.0 [10], a resident first registers itself with to UIDAI unaltered. Although intermediate communication a front end application specific agency viz. a viz., Applica- channels between various entities from resident to UIDAI tion Service Provider (ASP). A resident can use either OTP are well secured and access to eKYC data is provided only based authentication or biometric based authentication. In after receiving explicit consent from resident, this way of case of OTP based authentication, OTP generation request taking consent from resident has two shortcomings. First is forwarded to UIDAI via ASP and ESP. UIDAI generates is that the consent is taken by a non-UIDAI entity and does an OTP and sends it to resident’s registered mobile number. not encode in itself a proof from resident that it is (s)he In case of biometric based authentication, resident gets his who provided the consent. This is because residents do not fingerprint/iris scanned through a registered device. After have any registered tamper proof crypto device which can be authentication phase, resident now initiates an eSign request used to encrypt user consent using resident specific PIN or through ASP by providing it the consent to use his/her eKYC, password. Second is that providing a boolean consent is too the document to be signed and his/her Aadhaar number. ASP broad, either an unconditional access is given to the whole calculates cryptographic hash of the document and sends eKYC information or no access is given at all. A resident it along with the resident’s consent and resident’s Aadhaar may wish to have a better privacy enhancing fine-grained number to ESP. ESP takes authentication proof from resi- access control to his/her eKYC data indicating details on dent, creates a random symmetric key S K and a ES P U I DAI www.astesj.com 349 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) Personal Identity Data Object (PI D). PI D encodes in itself based authentication). Other than that, in some use cases the resident’s authentication proof and the cryptographic such as Create Birth Certificate, Create Death Certificate, hash of the PI D object (S H A256(PI D)). ESP first encrypts Student Enrollment, etc., the application is most heavily used PI D with S K , second encrypts cryptographic hash during a certain time period (nearing the end of a deadline) ES P U I DAI of PI D (S H A256(PI D)) with S K and third en- which puts a sudden nationwide load on UIDAI services. ES P U I DAI crypts S K with public key of UIDAI (PB ). ES P U I DAI U I DAI 5 eSign model as proposed in [4] ESP now wraps them in a new object called “Auth” and sends it to UIDAI in eKYC request. UIDAI provides eKYC In [4], author explained two limitations of present eSign information to ESP. Using received eKYC information, ESP model and proposed a mechanism to address the same. The generates a Digital Signature Certificate (DS C) and provides first limitation is that in present model of eSign, eKYC data it to ASP. ASP provides the digitally signed document to the access reflects a restrictive self-only, full-resource and un- resident. limited access control. Author pointed out that the resident may wish to have a better access control mechanism re- ESP/KUA/KSA Resident ASP UIDAI flecting third-entity-also, partial resource, use-limited and time-limited. Generate Generate O OTP TP Aadhaar Number Generate OT P Resident Consent (use eKYC for eSign) Version ::: ::: Generate OT P f S K g ES O U I DAI PB U I DAI PID Generate OT P Biometric OTP ::: ::: S K ES P U I DAI OT P f S H A256(PI D) g S KES P U I DAI ::: Retrie Retriev ve e eKYC eKYC information information S ign Document Figure 4: Auth Object (eSign 2.0) Aadhaar Number S ign Document Resident Consent (use eKYC for eSign) Resident Consent (Gen Access Token) Version ::: ::: eKYC(Auth) f S K g ES O U I DAI PB U I DAI eKYC PID Biometric OTP ::: ::: S K ES P U I DAI Use Use ekYC ekYC to to prepare prepare DSC DSC and and sign sign document document f S H A256(PI D) g S KES P U I DAI U se eKYC to generate ::: digital signature Figure 5: Auth Object as proposed in [4] Digital S ignature The second limitation is that a resident has to authenti- S igned Digital cate himself/herself for each eSign request and include the Document corresponding authentication proof in each eSign request. If a resident wishes to eSign a large number of docu- ments, the initial authentication phase will comprise most of the overall eSign time. After taking necessary consent from the resident, his/her authentication proof be stored with ESP Figure 3: Sequence diagram of eSign 2.0 in first request and is reused in rest of the requests. In practice, the initial authentication phase in eSign re- A digital access token [figure 6] can be used to include quest is most time consuming since it involves either the claims from participating entities (ESP and UIDAI). A new manual text input (in case of OTP based authentication) or service named GenerateAccessToken is proposed to be intro- the physical scan of the fingerprint/iris (in case of biometric duced by UIDAI. www.astesj.com 350 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) ESP Data ESP/KUA/KSA Resident ASP UIDAI ESP Private Claims ::: ::: ::: ::: S K ES Pi ESP Public Claims Generate Generate O OTP TP Aadhaar No Generate OT P Resident Consent I D AS Pi I D ES P AS P Transaction ID Generate OT P ES P Transaction ID ::: ::: PR ES P ESP DSC Generate OT P PB ES Pi OT P UIDAI Data UIDAI Private Claims ::: ::: ::: ::: S K U I DAI UIDAI Public Claims eSign eSign document, document, generate generate Access Access T Tok oken en Aadhaar No Resident Consent S ignDocument I D AS P I D ES Pi AS P Transaction ID ES P Transaction ID GenerateAccessT oken(Auth) UIDAI Transaction ID Token ID Token Expiry Time eSigns Granted Access T oken ::: ::: PR U I DAI UIDAI DSC PB U I DAI Retrie Retriev ve e eKYC eKYC information information PR U I DAI eKYC(AccessT oken) Figure 6: Access Token Structure as proposed in [4] eKYC In this proposed model of eSign [figures 7, 8], resident first authenticates himself/herself using OTP or biometric based authentication and sends eSign request to ASP. ASP forwards this eSign request to ESP. ESP takes OTP and per- Use Use ekYC ekYC to to prepare prepare DSC DSC and and sign sign document document mission to generate access token from resident and creates an “Auth” object. This “Auth” object is created as before but U se eKYC to generate additionally including ESP claims as well. ESP sends Gen- digital signature erateAccessToken request to UIDAI including “Auth” object. After receiving this request, UIDAI creates an access token Digital S ignature including its own claims as well as claims received from ESP. UIDAI sends this access token back to the ESP. Now, ESP sends eKYC request to UIDAI including this access S igned Digital token instead of the “Auth” object. After receiving eKYC Document ; information from UIDAI, ESP generates Digital Signature Certificate (DSC) from it and provides the same to ASP. ASP embeds DS C in the document and sends the digitally signed document to the resident. For all rest of the eSign requests, ESP can reuse the same access token in eKYC requests and Figure 7: First call to eSign in eSign model proposed in [4] avoid the initial authentication phase. The paper also presented two usability scenarios, based 6 Privacy Aware eSign model on whether the eKYC information can be cached by ESP or not. If ESP is permitted to reliably and securely store In earlier proposed model [section 5] digital access token is eKYC information of the resident, even the repeated eKYC used to increase amortized performance of eSign by storing requests from ESP to UIDAI can be avoided. necessary claims from UIDAI and ESP. The same token can The paper also presented performance comparison anal- be enhanced to include claims from resident as well. A resi- ysis of proposed model with present model and found sub- dent can encode claims related to privacy and fine grained stantial improvement in amortized performance of eSign. access control of his/her eKYC data. A stricter PEaFGAC statements may be enforced centrally at UIDAI level and an www.astesj.com 351 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) overriding less strict rule can be supplied with each eKYC also encodes in it the purpose for which eKYC can be ac- request to grant access to the requesting entity. cessed (Purpose), required (eKYC) attributes of information seeker (AP) and eKYC information which can be provided to the requester (scope). If required, a user can have multiple ESP/KUA/KSA Resident ASP UIDAI privacy statements for his/her eKYC data represented by di erent tags. eSign eSign document, document, generate generate Access Access T Tok oken en S ignDocument AadhaarNo POI: name, dob Check f or Access T oken POA: U se Access T okeni f valid co, house, street, lm, loc, vtc, subdist, dist, state, country, pc, po LData: lang, name, co, house, street, lm, loc, vtc, subdist, dist, state, country, pc, po Retrie Retriev ve e eKYC eKYC information information Pht: <Base64 encoded JPEG photo of resident I f Access T oken is valid; Org: eKYC(Access T oken) dep, desig Other: email eKYC Figure 9: Least information assumed to be available from eKYC for this paper Use Use ekYC ekYC to to prepare prepare DSC DSC and and sign sign document document PS.ID: U se eKYC to generate PS.Tag: digital signature eSignDoc PS.Purpose: eSign Digital S ignature PS.AP: (email = *@finance.iitg.ac.in) OR (org = IITG AND org.dep = finance) OR S igned Digital (desig >= director) Document ; PS.Scope: poi.name, poi.dob, poa.country, Ldata.lang Figure 10: Example of a PEaFGAC statement Figure 8: Second call to eSign in case eKYC needs to be fetched again It is assumed that all entities which request eKYC data also have their eKYC information available with UIDAI. 6.1 Privacy and Fine-Grained Access Con- This include not just the users but the organizations such as trol (PEaFGAC) Statements for eKYC ESPs as well. To better know an entity (both users and orga- data nizations), it is proposed that eKYC fields are expanded to include more details such as entity type (indicating whether A PEaFGAC statement encodes in itself the scope of infor- the subject is a human or an organization), resident’s orga- mation which can be provided, the purpose for which the nization, resident’s department, resident’s designation, etc. information can be provided and attributes of recipients to When an entity attempts to access eKYC data of a resident, whom the information can be provided. These statements entity’s eKYC data and purpose for which the eKYC data is are comprised of small sub-statements which are combined sought are verified against PEaFGAC statement protecting using relational operators. Each statement is identified by a eKYC data to decide whether the requisite access can be numeric id and an alphanumeric tag. granted or not. Only if the access can be granted, will the An example of a PEaFGAC statement is presented in eKYC data be provided to the requesting entity. The eKYC figure 10. This statement encodes in it that the purpose for data provided to the entity is limited in scope by PEaFGAC seeking eKYC information should be eSign, seeking entity statement. For rest of this paper, eKYC data is assumed to must either have the email in domain finance.iitg.ac.in, or consists of at least the information presented in figure 9. must be working in finance department of Indian Institute of Technology, Guwahati (IITG), or must have a designation 6.2 PEaFGAC Token of director or above. The statement is uniquely identified by a statement identifier (ID) and has a small alphanumeric The token structure introduced in [4] can be enhanced to representational string (TAG). Other than these, the staement include resident claims including PEaFGAC statement [fig- www.astesj.com 352 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) Login to ASP ure 11]. Before sending an eSign request, resident creates a Generate nonce n1 DataR1 = I DRkPWRkPBBkn1R PEaFGAC token by sending a token generation request to i i i i T G M1 R ! AS P S ignR = fH(DataR )g 1 1 PRB UIDAI through ASP and ESP. During token generation pro- f loginReq(DataR ; S ignR ) g 1 1 PB AS P DataA = C  (n1 + 1) 1 R R i i cess, resident is redirected to UIDAI web page where (s)he T G M2 R AS P S ignA1 = fH(DataA1)gPR AS P provides OTP value for authentication and PEaFGAC state- f loginRes(DataA ; S ignA )g 1 1 PBB Generate OTP ment for privacy and fine-grained access to his/her eKYC Generate nonce n2 DataR2 = AadhaarNoRkCRkn2R data. Subsequently UIDAI verifies the OTP value and signs i i i T G M3 R ! AS P S ignR = fH(DataR )g 2 2 PRB cryptographic hash of the statement with its private key and f getot pAS PReq(DataR ; S ignR ) g 2 2 PB AS P Generate nonce n1 AS P stores the signed hash in resident’s private claims and stores DataA = AadhaarNo kI D k 1 Ri AS Pi the statement in plaintext in resident’s public claims section T G M4 AS P ! ES P License kT I D kn1 AS P AS P AS P i i i S ignA = fH(DataA )g 1 1 PR AS P of PEaFGAC digital access token. f getot pES PReq(DataA ; S ignA ) g 1 1 PBES P Generate nonce n1 ES Pi ESP Data DataE = AadhaarNo kI D k 1 R ES P i i License kT I D kn1 ESP Private Claims T G M5 ES P U I DAI ES P ES P ES P i i i ::: ::: ::: ::: S ignE = fH(DataE )g 1 1 PRES P S K ES P f getot pReq(DataE ; S ignE ) g i 1 1 PB U I DAI T G M6 R U I DAI f OT P g S ecureCellularNetwork ESP Public Claims DataU = returnS tatuskT I D k 1 ES P Masked MobileNok(n1 + 1) ES Pi Aadhaar No T G M7 ES P U I DAI S ignU = fH(DataU )g 1 1 PR U I DAI Resident Consent f getot pRes(DataU ; S ignU )g 1 1 PB ES P I D AS P DataE = returnS tatuskT I D k 2 AS P I D ES Pi Masked MobileNok(n1 + 1) AS P AS P Transaction ID i T G M8 ES P AS P S ignE = fH(DataE )g 2 2 PRES P ES P Transaction ID f getot pES PRes(DataE ; S ignE )g 2 2 PB AS P ::: ::: PR DataA = returnS tatusk ES Pi 2 Masked MobileNok(n2R + 1) T G M9 ES P R ESP DSC S ignA = fH(DataA )g 2 2 PRAS P f getot pAS PRes(DataA ; S ignA )g 2 2 PB PB ES P Generate Token Generate nonce n3 Ri DataR = C kn3 3 R R i i T G M10 R ! AS P S ignR = fH(DataR )g 3 3 PR UIDAI Data B f gentokAS PReq(DataR ; S ignR ) g 3 3 PB AS P UIDAI Private Claims Generate nonce n2 AS Pi ::: ::: ::: ::: DataA = AadhaarNo kI D kLicense k 3 Ri AS P AS P i i T G M11 AS P ! ES P T I DAS Pkn2AS P i i S K U I DAI S ignA = fH(DataA )g 3 3 PRAS P UIDAI Public Claims f gentokES PReq(DataA ; S ignA ) g 3 3 PB ES P Aadhaar No Generate nonce n3 ES P Resident Consent DataE = AadhaarNo kI D k 3 Ri ES Pi I D License kT I D k AS Pi ES Pi ES Pi T G M12 ES P ! U I DAI I D n3 ES P ES P i i AS P Transaction ID S ignE3 = fH(DataE3)gPR i ES P ES P Transaction ID f gentokU I DAIReq(DataE ; S ignE ) g i 3 3 PB U I DAI UIDAI Transaction ID Generate nonce n1 U I DAI Token ID DataU = U I DAIRedirectU RL (ForT akingPrivacyS tatement s)k Token Expiry Time T G M13 U I DAI ES P eSigns Granted PBU I DAIkT I DES Pkn1U I DAI S ignU = fH(DataU )g ::: ::: 1 1 PRU I DAI PR U I DAI f gen psU I DAIReq(DataU ; S ignU ) g 1 1 PB ES P Generate nonce n4 UIDAI DSC ES P DataE = U I DAIRedirectU RL PB U I DAI (ForT akingPrivacyS tatement s) T G M14 ES P AS P kPB kT I D kn4 U I DAI AS P ES P i i S ignE = fH(DataE )g 4 3 PR ES P f gen psES PReq(DataE ; S ignE ) g 4 4 PBAS P Generate nonce n4 Ri Resident Data DataA = f Present U I DAIRedirectU RL to Resident Public Claims Resident which request s him T G M15 AS P R to provide OT P V alue and Privacy statement skPB kn4 g U I DAI Ri ID, Tag, Purpose, AP, Scope PS1 S ignA = fH(DataA )g 4 4 PR AS P f gen psAS PReq(DataA ; S ignA ) g 4 4 PBB T G M16 R ! U I DAI f PEaFGAC PrivacyS tatement s g ID, Tag, Purpose, AP, Scope PBU I DAI PS2 PEaFGAC Token Generation Request DataR = C k(n4 + 1) 4 Ri Ri S ignR = fH(DataA )g T G M17 R ! AS P 4 4 PR PS3 ID, Tag, Purpose, AP, Scope B f gen psAS PRes(DataA ; S ignA ) g 4 4 PBB PR U I DAI DataA = (n4 + 1) 5 ES Pi T G M18 AS P ES P S ignA = fH(DataA )g 5 4 PR Resident Private Claims AS Pi f gen psES PRes(DataA4; S ignA4) gPB ES P H(PS1) i DataE = (n1 + 1) 5 U I DAI H(PS2) T G M19 ES P U I DAI S ignE = fH(DataE )g 5 5 PRES P H(PS3) i PRU I DAI f gen psU I DAIRes(DataE ; S ignE ) g 5 5 PB U I DAI Create PEaFGACT okenAT Ri DataU = AT k(n3 + 1) 2 Ri ES P T G M20 ES P U I DAI S ignU = fH(DataE )g 2 5 PR ES P f gentokU I DAIRes(DataE ; S ignE ) g 5 5 PB U I DAI DataE = (n2 + 1) Figure 11: Proposed PEaFGAC Token Structure 6 AS Pi T G M21 AS P ES P S ignE = fH(DataE )g 6 5 PRES P f gentokES PRes(DataE6; S ignE6) gPB AS P Figure 12 depicts the sequence and details of communi- DataA = (n3 + 1) 5 R T G M22 R AS P S ignA = fH(DataE )g 5 5 PRAS P cation messages among participating entities for generation i f gentokES PRes(DataA ; S ignA ) g 5 5 PB of a token. First column indicates the message identifier, second column indicates the participating entities and the Figure 12: Proposed PEaFGAC Token Generation protocol direction of communication and third column indicates what message is sent and how it is constructed. www.astesj.com 353 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) 6.3 Proposed Privacy Aware eSign model us- [11]. Because of space limitation, it is assumed that PEaF- GAC token has already been generated securely.Analysis of ing PEaFGAC statement for eKYC data the token generation request can be done similarly.BAN logic and PEaFGAC token is a well-known model used to find beliefs of participants in This section presents how PEaFGC statement for eKYC a cryptographic protocol. data and PEaFGAC token can be used to implement Pri- vacy Aware eSign. It is assumed that PEaFGAC token has O perator U sage Description already been generated as explained in section 6.2. It is also P j= X P believes statement X assumed that the communication channel between resident P C X P sees statement X and ASP is secured using SSL/TLS, between ASP and ESP P 7 ! X P controls X is secured using SSL/TLS and between ESP and UIDAI is #(X) Message X is fresh secured using dedicated secure leased lines. P $ Q P and Q share key K Figure 13 depicts the sequence and details of communi- K 7! P P has K as its public key cation messages transferred in eSign request in case eKYC P Q Formula X is a secret known needs to be fetched again. only to P and Q fXg Formula X is encrypted using K Login to ASP Generate nonce n1 hXi Formula X is combined with DataR = I D kPW kPB kn1 1 Ri Ri Bi Ri M1 R ! AS P formula Y S ignR = fH(DataR )g 1 1 PR f loginReq(DataR ; S ignR ) g 1 1 PB AS P DataA = C  (n1 + 1) Figure 14: Fundamental BAN operators 1 R R i i S ignA = fH(DataA )g M2 R AS P 1 1 PR AS P O perator U sage Description f loginRes(DataA ; S ignA )g 1 1 PBB Initiate eSign request M eSign of message M is done by eS ign R ES P CC A Generate nonce n2 Resident R through ES P DataR = M kconsent k 2 i use ekyc approved by CC A consent kC kn2 M3 R ! AS P genuse at R R i i eS ign R ES P CC A S ignR = fH(DataR )g 2 2 PRB = MkDS C f signdocAS PReq(DataR ; S ignR ) g R M 2 2 PB AS P = MkfeKYC kH(M)g k Generate nonce n1 R PR AS P R DataA = H(M )kAadhaarNo kI D k PB kS ignChain 3 i R AS P R i i License kT I D k AS P AS P i i = MkfeKYC kH(M)g k R PR M4 AS P ES P consent kconsent k use ekyc genuse at PB kfPB g k R R PR ES P n1 AS P fPB g ES P PR CC A S ignA = fH(DataA )g 3 3 PR AS P i secure f signdocES PReq(DataA ; S ignA ) g P j= E ! E P believes that communication 3 3 PB i j ES P Retrieve eKYC (reusing access token) and sign document from entity E to E is secure i j secure Generate nonce n1 ES P P j= E E P believes that communication i j I f AT is valid use it from entity E to E is secure j i M5 ES P ! U I DAI DataE = AT kH(M )kn1 5 Ri i ES Pi secure S ignE = fH(DataE )g P j= E ! E P believes that communication 5 5 PR i j ES P f kycES PReq(DataE ; S ignE ) g 5 5 PB between entities E and E is U I DAI i j Retrieve eKYC ES P secure in both directions Retrieve AT ! UC ! AP i ACT Perm P j= E ! E P believes that entity E has V eri f y whether access can be granted i j i based on above two parameter s: given permission for action M6 ES P U I DAI eKYC = eKYC o f resident sco ped i ACT to entity E by AT ! UC ! sco pe P j= C { E P believes that cookie C is R i R DataU = eKYC k(n1 + 1) 3 R ES P i i associated with logged-in entity E S ignU = fH(DataU )g 3 3 PR U I DAI C ! I D E E R R f kycES PRes(DataU ; S ignU ) g 3 3 PBES P i E j= E ! E E believes that it has securely R R R R Generate key pair PB PR using eKYC Ri Ri Ri communicated its identity I D S ignChain = f PB g k R PR i ES P to entity E through cookie C R E f PB g ES P PR i CC A DS C = f eKYC kH(M ) g k R M R i PR i i i R Figure 15: Extended BAN operators M7 AS P ES P PB kS ignChain Delete PR DataU = DS C kT I D k(n1 + 1) 2 R M AS P AS P i i i i S ignU = fH(DataU )g 2 2 PR ES P The security environment is assumed to be based on f signdocES PRes(DataU ; S ignU ) g 2 2 PB AS P Delev-Yao model in which all messages are communicated fM g = M kDS C i eS ign R ES P i R M i i i i DataA = fM g k(n2 + 1) over public channels and an attacker can see, modify, com- 6 i eS ign R ES P R i i i M8 R AS P S ignA = fH(DataA )g 6 6 PR AS P i pose and replay messages but cannot break cryptographic f signdocAS PRes(DataA ; S ignA ) g 6 6 PBB principles. The security environment also assumes that an V eri f y correctness o f eKYC; H(M) and M9 R $ R S ignChain in fM g i eS ign attacker can decipher messages if he has a valid decryption key. Some of the fundamental operators used in BAN logic Figure 13: Proposed Privacy Aware eSign model are defined in figure 14. An extension to BAN logic, defined in figure 15 is required to analyse the proposed model. 7 Formal Security Analysis of the Rules of Inference proposed model using BAN Logic [R1:] Message meaning rules concern the interpretation This section presents formal security analysis of the pro- of messages. They all derive beliefs about the origin of posed scheme using Burrows-Abadi-Needham (BAN) logic messages. www.astesj.com 354 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) PB For shared secrets, the inference rule is E j= 7! E , R R E j= C { S , R R P j= Q P, P ChXi E j= #n , Y R R E j= ffYg g = Y P j= Q B X R PR PB R R E C f CommM sgReq ( That is, if P believes that the secret Y is shared with Q and XkC kn ; R R sees hXi , then P believes that Q once said X. Y fH(XkC kn )g ) g R R PR PB R E i R S ecure E j= R ! E , R R [R2:] The nonce-verification rule expresses the check that E j= R B X a message is recent, and hence, that the sender still believes in it: P j= #(X), P j= Q B X [R8:] If receiver entity E believes that PB is pub- R E P j= Q j= X lic key of receiver entity E , n is a fresh nonce R E generated by E , E receives message of the form R R That is, if P believes that X could have been uttered only f CommM sgReq (Xkn ;fH(Xkn )g )g , then E be- E E PR PB R R R E E R R recently and that Q once said X, then P believes that Q lieves that X is sent by entity E and communication channel believes X. from E to E is secure and no message is observed, modi- R R fied or replayed by an intruder. [R3:] The jurisdiction rule states that if P believes that Q has jurisdiction over X, then P trusts Q on the truth of X: PB E j= 7! E , R R P j= Q ) X, P j= Q j= X E j= ffYg g = Y , R PR PB E E R R E j= #n P j= X R E E C f CommM sgReq ( Xkn ; [R4:] The seeing rule states that if a principal sees a for- fH(Xkn )g ) g E PR PB R E E mula, then he also sees its components, provided he knows R R S ecure the necessary keys: E j= E ! E R R R E j= E B X R R Pj=Q$P(;)PCfXg PC(X;Y ) PChXi K , , , PCX PCX PCX [R9:] If receiver entity E believes that communication Pj=7!P, PCfXg from all possible sender entities E to E (8i = 1:::n) is Pj=7!P, PCfXg 1 R R K K i , . PCX PCX secure, then E believes that communication channel to E R R is secure and no message is observed, modified or replayed by an intruder. Note that if P sees X and P sees Y it does NOT follow that P sees (X; Y ) since that means that X and Y were uttered at [R10:] If resident R believes that C is a cookie associ- the same time. ated with a unique session from resident R, PB is public key of entity E , n was a fresh nonce generated by R and R R [R5:] The fresh rule states that if one part of the formula is used in a previous request call from R to E , R receives a fresh, then the entire formula must be fresh. message of the formfCommM sgRes(Xk(n + 1);fH(Xk(n + R R 1)g )g , then E believes that X is sent by entity R P j= #(X) PR PB R E E R R and communication channel from R to E is secure and no P j= #(X; Y ) message is observed, modified or replayed by an intruder. [R6:] The belief rule states that if P believes one part of the [R11:] If sender entity E believes that PR is private key R E formula, then it also believe part of the formula. of sender entity E , PB is public key of receiver entity E , R E R n was a fresh nonce generated by R and used in a previous P j= (X; Y ) request call from E to E , E receives message of the form R R R P j= (X) fCommM sgRes (Xk(n +1);fH(Xk(n +1)g )g , then E E PR PB R R E E R R E believes that X is sent by entity E and communication R R channel from E to E is secure and no message is observed, R R Extended Rules of Inference modified or replayed by an intruder. [R7:] If receiver entity E believes that C is a R R [R12:] If sender entity E believes that communication cookie associated with a unique session from resident from all possible receiver entities E (8i = 1:::n) is secure, R, PB is public key with browser used by resident R, then E believes that communication channel to E is secure R R PB is public key of receiver entity E , n is a fresh E R R and no message is observed, modified or replayed by an nonce generated by R, E receives message of the form intruder. fCommM sgReq(XkC kn ;fH(XkC kn )g ) g , then R R R R PR PB B E i R E believes that X is sent by entity R and communication [R13:] An electronic signature (M ) is a valid signature R ieS ign channel from R to E is secure and no message is observed, only when resident verifies that three main parts in signature, modified or replayed by an intruder. viz., eKYC, H(M) and S ignChain are as expected. www.astesj.com 355 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) secure Assumptions AS P j= R ! AS P i i i secure R j= R ! AS P i i i The protocol makes several assumptions. The assumptions secure AS P j= AS P ! ES P i i i relevant for the discussion of this paper are listed below. secure ES P j= AS P ! ES P i i i secure [A1:] It is assumed that all sessions from all residents R ES P j= ES P ! U I DAI i i secure keeps their cookie C secret. U I DAI j= ES P ! U I DAI [A2-A6:] The scheme makes several assumptions about [G7:] Resident R must be sure that at the end what he public keys. For example, R believes that PB is public receives is indeed a digital signature on message M , signed i AS P i i key of AS P . Similar to this, other entities also make similar by resident’s private key and generated by the genuine ES P . i i assumptions. These assumptions are listed below. R j= M = M i i eS ign R ES P CC A eS ign i i PB AS P R j= 7! AS P :::(A2) i i PB Idealization AS P ES P j= 7! AS P :::(A3) i i PB ES P BAN idealization of communication messages in communi- AS P j= 7! ES P :::(A4) i i cation phase is shown in table 1 PB ES P U I DAI j= 7! ES P :::(A5) PB Table 1: BAN Idealization of Proposed Protocol (Part I: M1-3) and (Part II: U I DAI ES P j= 7! U I DAI :::(A6) M4-8) M1 AS P C flogin ( [A7:] AS P assumes that all valid cookies C i R I D kPW kPB kn1 R R B R i i i i are associated with a valid ongoing session from a fH(I D kPW kPB k R R B i i i unique valid user R already logged in to AS P portal. i i n1 )g R PR i B AS P j= C { I D 8i = 1::n i R R g i i PB AS P M2 R C floginRes ( [A8-A15:] R and AS P assumes that all nonce n (where i i i R C  (n1 + 1) is any integer used in the scheme) are fresh. Similar to R R i i fH(C this, other entities also make similar assumptions. These R (n1 + 1))g assumptions are listed below. R PR i AS P PB R j= #n :::(A8) i R M3 AS P C fsigndocAS PReq ( AS P j= #n :::(A9) i R M kconsent k i use ekyc AS P j= #n :::(A10) i AS P consent kC kn2 ); genuse at R R i i ES P j= #n :::(A11) i AS P fH(M kconsent k i use ekyc ES P j= #n :::(A12) i ES P consent kC k genuse at R U I DAi j= #n :::(A13) ES P n2 )g R PR i B U I DAI j= #n :::(A14) U I DAI ES P j= #n :::(A15) i U I DAI PB AS P M4 ES P C fsigndocES PReq ( H(M )kAadhaarNo k i R [A16:] It is assumed that when AS P receives message I D kLicense k AS P AS P i i of the form CommM sg(DataA ; S ignA ) from ES P , j j PB i AS P T I D kconsent k AS P use ekyc it has verified the validity of data, i.e., fS ignA g = j PB ES P consent kn1 ; genuse at AS P H(DataA ). The same assumption is made for all entities f H(H(M )kAadhaarNo k i R receiving messages of this form. I D kLicense k AS P AS P i i T I D k AS P Goals to be achieved. consent k use ekyc consent k genuse at Following are the goals which are envisaged to be achieved n1 ) g AS P PR i AS P by the proposed model. i PB ES P [G1-G6:] Sender entity must be sure that the data received M5 U I DAI C fkycES PReq ( by receiver entity is same as what was sent by it and is not AT kH(M )kn1 ; R i ES P i i modified, observed or replayed by an intruder after it was fH(AT kH(M )k R i sent by the sender entity. Similarly, receiver entity must n1 )g ES P PR i ES P be sure that the data received by it is same as what was i sent by sender entity and is not modified, observed or re- PB U I DAI played by an intruder after it was sent by the sender entity. www.astesj.com 356 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) M6 ES P C fkycES PRes ( Using I5 and I6, secure eKYC k(n1 + 1) (G3 : Proved) R ES P ES P j= AS P ! ES P i i i i i fH(eKYC k (n1 + 1))g ES P PR i U I DAI Using M4, R11, g secure PB ES P (I7) AS P j= AS P ! ES P i i i M7 AS P C fsigndocES PRes ( Using M7, R8, feKYC kH(M )g k R i PR i R secure (I8) AS P j= AS P ES P i i i PB kfPB g k R R PR i i ES P fPB g k Using I5 and I6, ES P PR i CC A secure (G4 : Proved) T I D k(n1 + 1); AS P j= AS P ! ES P AS P AS P i i i i i fH(eKYC kH(M )g k R i PR i R PB kfPB g k R R PR i i ES P Using M5, R7, secure fPB g k ES P PR i CC A (I7) U I DAI j= ES P ! U I DAI T I D k AS P Using M6, R11, (n1 + 1))g secure AS P PR i ES P (I8) U I DAI j= ES P U I DAI Using I7 and I8, PB AS P i secure U I DAI j= ES P ! U I DAI M8 R C fsigndocAS PRes ( M kfeKYC kH(M )g i R i PR i R (G5 : Proved) kPB kfPB g k R R PR i i ES P Using M5, R11, fPB g k(n2 + 1) ES P PR R secure i CC A i (I9) ES P j= ES P ! U I DAI i i fH(M kfeKYC kH(M )g i R i PR i R Using M6, R8, kPB kfPB g k R R PR i i ES P secure (I0) ES P j= ES P U I DAI fPB g k i i ES P PR i CC A (n2 + 1))g R AS P Using I9 and I10, i i secure (G6 : Proved) ES P j= ES P ! U I DAI i i PB [P7:] Using message M9 and rule R13, it can be de- duced that R believes that fM g is a valid elec- i i eS ign Analysis tronic signature. [P1-P6:] Using messages M1, M3 and rule R7, it can Using M9 and R13, be deduced that AS P believes that communication R j= fM g = fM g i i eS ign i eS ign R ES P CC A i i from R to AS P is secure. Using messages M2, M8 i i (G7 : Proved) and rule R11, it can be deduced that AS P believes that communication from AS P to R is secure. From i i these two deductions, it can further be deduced that 8 Conclusion AS P believes that communication between R and i i AS P is secure in both directions. This work is an extension of the work [4] on enhancing amor- tized performance of eSign by using digital access tokens Using M1, M3, R7, R8, secure including claims from ESP and UIDAI. In this work, the (I1) AS P j= R ! AS P i i i digital access token introduced in [4] is extended to include Using M2, M8, R11, secure privacy and fine-grained access control statements for access (I2) AS P j= R AS P i i i to resident’s eKYC data. This enhanced token can be used Using I1 and I2, by third entities to access the protected eKYC data with secure (G1 : Proved) better privacy and fine-grained access control rules enforced AS P j= R ! AS P i i i by the resident. A formal security analysis of the proposed model using BAN logic is also presented. Using M1, M3, R10, R11 secure (I3) AS P j= R ! AS P i i i Using M2, M8, R8, References secure (I4) AS P j= R AS P i i i [1] UIDAI, “Unique Identification Authority of India”, [Online]. Avail- Using I3 and I4, able: https://uidai.gov.in (2017). secure (G2 : Proved) AS P j= R ! AS P i i i [2] Wikipedia, “Aadhaar”, [Online]. Available: https://en.wikipedia.org/wiki/Aadhaar (2017). Using M4, R7, [3] Reserve Bank of India, “Master Direction - Know Your secure (I5) ES P j= AS P ! ES P Customer (KYC) Direction, 2016”, [Online]. Available: i i i https://rbidocs.rbi.org.in/rdocs/notification/PDF Using M7, R11, s/18MDKYCD8E68EB1 3629A4A82BE8E06E606C57E57.PDF, secure (I6) 2018. ES P j= AS P ES P i i i www.astesj.com 357 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) [4] Bakshi, Puneet, Neelakantan Subramanian, and Sukumar Nandi. “Us- [13] Merkle, Ralph C. “A digital signature based on a conventional en- ing digital tokens to improve amortized performance of eSign.” 2018 cryption function.” Conference on the theory and application of IEEE 16th Intl Conf on Dependable, Autonomic and Secure Comput- cryptographic techniques. Springer, Berlin, Heidelberg, 1987. ing, 16th Intl Conf on Pervasive Intelligence and Computing, 4th Intl [14] Paquin, Christian, and Greg Zaverucha. “U-prove cryptographic spec- Conf on Big Data Intelligence and Computing and Cyber Science ification v1. 1.” Technical Report, Microsoft Corporation (2011). and Technology Congress (DASC/PiCom/DataCom/CyberSciTech). IEEE, 2018. [15] Chaum, David. “Blind signatures for untraceable payments.” Ad- [5] Paquin, Christian, and Greg Zaverucha. “U-prove cryptographic spec- vances in cryptology. Springer, Boston, MA, 1983. ification v1. 1.” Technical Report, Microsoft Corporation (2011). [16] Hardt, Dick. The OAuth 2.0 authorization framework. No. RFC 6749. [6] Chaum, David. “Blind signatures for untraceable payments.” Ad- vances in cryptology. Springer, Boston, MA, 1983. [17] Nakamoto, Satoshi. “Bitcoin: A peer-to-peer electronic cash system.” [7] Hardt, Dick. The OAuth 2.0 authorization framework. No. RFC 6749. (2008). [18] PKIA2017, “Development of Smart Authentication and Identifica- [8] Nakamoto, Satoshi. “Bitcoin: A peer-to-peer electronic cash system.” tion in Asia”, [Online]. Available: http://pkiindia.in/pkia/#preceding, (2008). [9] UIDAI, “Aadhaar e-KYC API Specification - Version 2.1”, [Online]. [19] CCA, “Pki framework in India”, [Online]. Available: Available: http://www.cca.gov.in/cca/sites/default/files/file http://www.cca.gov.in/cca/?q=pki˙frame work.html (2015). s/eSign-APIv2.1.pdf, 2017 [20] CCA, “Public key certificate classes”, [Online]. Available: [10] CCA, “eSign Service”, [Online]. Available: http://www.cca.gov.in/cca/?q=node/45 (2017). http://cca.gov.in/cca/?q=eSign.html (2017). [11] Burrows, Michael, Martin Abadi, and Roger Michael Needham. “A [21] CCA, “Empanelled eSign Service Providers”, [Online]. Available: logic of authentication.” Proceedings of the Royal Society of London. http://www.cca.gov.in/cca/?q=service-providers.html (2017). A. Mathematical and Physical Sciences 426.1871 (1989): 233-271. [22] Jones, Michael, John Bradley, and Nat Sakimura. Json web token [12] Rivest, Ronald L., Adi Shamir, and Leonard Adleman. “A method (jwt). No. RFC 7519. 2015. for obtaining digital signatures and public-key cryptosystems.” Com- munications of the ACM 21.2 (1978): 120-126. [23] Jones, Mike, et al. Cbor web token (cwt). No. RFC 8392. 2018. www.astesj.com 358 http://www.deepdyve.com/assets/images/DeepDyve-Logo-lg.png Advances in Science, Technology and Engineering Systems Journal Unpaywall

Using Privacy Enhancing and Fine-Grained Access Controlled eKYC to implement Privacy Aware eSign

Bakshi, Puneet; Nandi, Sukumar
Advances in Science, Technology and Engineering Systems Journal – Jan 1, 2019
Download PDF
12 pages

Loading next page...
 
/lp/unpaywall/using-privacy-enhancing-and-fine-grained-access-controlled-ekyc-to-hvqer0xvNa
Publisher
Unpaywall
ISSN
2415-6698
DOI
10.25046/aj040443
Publisher site
See Article on Publisher Site

Abstract

Advances in Science, Technology and Engineering Systems Journal ASTES Journal Vol. 4, No. 4, 347-358 (2019) ISSN: 2415-6698 www.astesj.com Special Issue on Advancement in Engineering and Computer Science Using Privacy Enhancing and Fine-Grained Access Controlled eKYC to implement Privacy Aware eSign Puneet Bakshi , Sukumar Nandi Department of Computer Science and Engineering, Indian Institute of Technology, Guwahati, 781039, India A R T I C L E I N F O A B S T R A C T Article history: eSign is an online electronic signature service which is recently gaining Received: 28 May, 2019 more prominence in India. eSign is based on two online services from Accepted: 23 July, 2019 UIDAI, viz. a viz., Aadhaar based authentication and retrieval of resident’s Online: 19 August, 2019 eKYC information after taking his/her consent. With increased adoption of Aadhaar based services, privacy of user data has become more and Keywords: more important. Present method of taking boolean consent from resident eSign through non-UIDAI entity may not be acceptable for two main reasons, first eKYC is that the consent does not include in itself a proof from resident that the Electronic Signature consent is indeed taken from him/her and second is that the resident may Privacy wish to have better privacy and fine grained access control rules to access Access Control his/her eKYC data. Bakshi et.el have introduced a mechanism to improve Authentication amortized performance of eSign using a digital access token. In this work, Token the digital access token is enhanced to include Privacy Enhancing and Fine- BAN logic Grained Access Control (PEaFGAC) Statements for facilitating Privacy Aware eSign. These tokens can be used by other entities to access eKYC data of the resident with better access controls enforced by the resident. This paper briefly describes the present model of eSign, the earlier proposed model of eSign followed by the proposed model of Privacy Aware eSign. The proposed model of Privacy Aware eSign is also analyzed using BAN logic assuming Dolev-Yao security environment. 1 Introduction Unique Identification Authority of India (UIDAI) and receive a 12-digit identity number called Aadhaar [1] [2]. As part eSign is an online electronic signature service in India which of the enrollment process, resident needs to provide infor- is being promoted by Government of India as part of its Dig- mation about his/her identity and address to UIDAI such ital India Initiative. As opposed to traditional dongle based as Name, Date of Birth, Address, Phone number, Email-id, electronic signature, eSign provides benefits such as less Biometric (fingerprint-scan, iris-scan) etc. The process of cost, no manual authentication, no requirement of special obtaining this information from the end user is known as hardware device and no requirement for the end user to keep Know Your Customer (KYC) and is initially introduced by any key secret. With the passage of Information Technology Reserve Bank of India (RBI) for financial banks [3]. Tradi- Act (ITA-2000), an electronically signed digital document tionally, this process involves submission of a self-attested is considered equivalent to a handwritten signed paper doc- physical form along with necessary physical documents, fol- ument. In India, eSign is being regulated by Controller of lowed by verification and approval by receiving organization. Certifying Authority (CCA) and is being operated by cer- eKYC is an online service which facilitates completion of tain designated empaneled agencies known as eSign Service KYC process electronically. eKYC has some significant Providers (ESP). ESP provides its services to application benefits over traditional KYC, eKYC eliminates submission specific agencies known as Application Service Providers of physical documents by customer, is faster and is less error (ASP). ASP provides eSign service to the end users. eSign is prone. UIDAI’s eKYC service facilitates a third entity to governed by Public Key Infrastructure (PKI) which is further retrieve resident’s identity, address and other details after governed in legal matters by the national legislature of the taking explicit consent and authorization from the resident. country. To avail eSign service, a resident needs to enroll with With increased adoption of Aadhaar based identification, Corresponding Author: Puneet Bakshi, IIT Guwahati, b.puneet@iitg.ac.in www.astesj.com 347 https://dx.doi.org/10.25046/aj040443 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) fXg X is signed by key Y many online services are now using Aadhaar based services S K Symmetric key of entity Y and with its such wide adoption, privacy of user data has be- S K Symmetric key shared by entities Y and Z. Y Z PR Private asymetric key of entity Y come even more important. Although Aadhaar based eKYC PB Public asymetric key of entity Y service provides access to eKYC data only after taking an R Resident explicit consent from the resident, this way of taking consent AS P Application Service Provider ES P eSign Service Provider from resident has two shortcomings. First is that the consent i U I DAI Unique Identification Authority of India is taken by non-UIDAI entity and does not encode in itself a I D , I D Identities of R , AS P and ES P R AS P i i i i i proof from resident that the consent is indeed given by the I D ES Pi T I D ; T I D Unique transaction identifiers generated resident. Second is that providing a boolean consent is too ES Pi AS Pi by ES P and AS P i i broad, either an unconditional access is given to the whole PW Password of R for login to AS P portal R i i eKYC information or no access is given at all. A resident AadhaarNo Aadhaar No of R R i C Cookie associated with R ’s logged-in R i may wish to have a better privacy enhancing fine-grained i session, assigned by AS P access control to his/her eKYC data. Resident may wish PR , PR Private keys of R browser, AS P , ES P B AS P i i i i i to define a privacy and access control policy dictating the PR , PR and U I DAI ES Pi U I DAI PB , PB Public keys of R browser, AS P , ES P B AS P i i i i i scope of information which can be provided, the purpose PB , PB and U I DAI ES P U I DAI for which the information can be provided and recipients n nonces such as n1 , where  is any integer ! AS P to whom the information can be provided. For example, a and ! can be R , AS P , ES P or U I DAI i i i DataR (DataA ; Intermediate data in plaintext to be send by i i resident may wish to disclose only his/her name and address, DataE ; DataU ) R (AS P , ES P , U I DAI) i i i i i only for electronic signature purpose and only to a specific S ignR (S ignA ; fH(DataR )g i i i PR Ri eSign Service Provider. S ignE ; S ignU ) i i consent Consent from resident whether his/her eKYC use ekyc In [4], the author explained two limitations of present eS- can be used ign model. The first limitation is that the eKYC data access consent Consent from resident whether a digital access genuse at token can be generated for later use reflects a restrictive self-only, full-resource and unlimited License License for AS P (ES P ) to use services AS P i i access control. Author pointed out that a resident may wish License from ESP (UIDAI) ES P to have a better access control mechanism which allows third M Message (in plaintext) to be eSign DS C Digital Signature Certificate generated for entities to access part of a resource which is to be used for Ri Mi message M for resident R i i a specific purpose and for a limited time period. The sec- fMg eSigned message (by R ) through ES P eS ign R ES P i i i i ond limitation is that for each eSign request, resident has H() One way cryptographically secure hash fn k Concatenation operator to authenticate itself each time and to include the authenti- XOR operator cation proof in each such request. Author pointed out that if a resident needs to eSign multiple times, time taken by Figure 1: Notations used in this paper initial authentication phase will be a major bottleneck. The author proposed that amortized performance of eSign can be 2 Related Work improved using digital access token which encodes in itself the authentication proof and other information such as how Digital tokens are increasingly being used in many cryptog- many eSign requests can be made using this token and the raphy related applications to achieve varied objectives. expiry time of the token. U-Prove [5] is an identity management solution based This paper is an extension of [4] and the digital access on blind signatures [6] which uses digital tokens to achieve token is enhanced to implement Privacy Aware eSign. Our objectives of privacy and anonymity. U-Prove consists of main contribution in this paper is to introduce a method to two protocols, viz., issuance protocol and presentation pro- implement Privacy Aware eSign using Privacy Enhancing tocol. In issuance protocol, identity provider issues digital and Fine-Grained Access Control (PEaFGAC) Statements. token to the subscriber which (s)he can later present to the A resident can encode these statements in digital access to- verifier in presentation protocol so that the service provider ken for better access to his/her eKYC data. This token can can grant resource access to the subscriber. A U-Prove to- be provided to third entities so that they can present this to- ken consists of a unique token identifier, a public key of the ken for claiming protected resource from UIDAI. This paper token which aggregates information in the token, a token also presents security analysis of the proposed scheme using information field which encodes token specific information, Burrows-Abadi-Needham (BAN) logic. The analysis shows a prover information field which is opaque to the issuer, is- that in the proposed scheme, even if the network is unreli- suer signature on all the other token contents and a boolean able, the exchanged information is reliable and is secured value which indicates whether the token is protected by a against eavesdropping. device. U-Prove uses digital tokens e ectively by encoding The remainder of this paper is organized as follows. Sec- necessary information in it in cryptographically secure way tion 2 presents related work. Notations used in the paper to achieve objectives such as privacy and anonymity. are reported in figure 1. Section 3 presents Aadhaar based OAuth2 [7] is an authorization framework which allows eKYC service. Section 4 presents eSign version 2.0 model. delegation of access to protected resources to a third party Section 5 presents eSign model proposed in [4] to improve by using digital tokens referred to as access tokens. Access amortized performance of eSign. Section 6 presents pro- tokens are issued to Clients by Authorization Server after posed Privacy Aware eSign model using privacy enhancing taking permission from Resource Owner. An access token and fine-grained access controlled eKYC. Section 7 presents can be of two types, viz., a bearer token and a MAC token. formal security analysis of the proposed model using BAN A bearer token is an opaque string which can be used to logic and finally section 8 concludes the paper. claim access to a resource by any entity who presents the www.astesj.com 348 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) token. A MAC token is essentially a shared symmetric key scope, purpose and recipient. which is used to sign a challenge by the client to prove its possession of the token to authorization server. OAuth2 uses URL: digital tokens e ectively for access delegation and is used https://<host>/kyc/<ver>/<ac>/<uid[0]>/<uid[1]> by many organizations for data sharing. /<asalk> Bitcoin [8] is a decentralized digital currency which can be transacted over peer-to-peer bitcoin network. A bit- Input Data: coin network is composed of cryptographically secure linear <Kyc ver="" ra="" rc="" lr="" de="" pfr=""> chains of blocks with each block containing a header and <Rad>base64 encoded fully valid Auth XML for a collection of transactions. A transaction is essentially a resident digital token that changes ownership of bitcoins from one </Rad> entity to another. Each transaction in bitcoin network is </Kyc> broadly composed of three parts, viz., input, output and Response Data: amount. Input refers to the previous owner of the bitcoins, <Resp status="" ko="" ret="" code="" txn="" ts="" output refers to the new owner of the bitcoins and amount err=""> encrypted and base64 encoded KycRes refers to the amount of bitcoin that is transacted. Bitcoins element uses cryptographically secure digital information containers </Resp> (similar to digital tokens) e ectively for the realization of digital currency. <KycRes ret="" code="" txn="" ts="" ttl="" actn="" Although Attribute Based Encryption (ABE) is also err=""> <Rar>base64 encoded fully valid Auth response evolved to protect privacy of user data, it is based on Identity XML for resident Based Encryption (IBE). An agency may not shift from PKI </Rar> to IBE framework for a number of reasons. <UidData uid=""> <Poi name="" dob="" gender="" /> <Poa co="" house="" street="" lm="" loc="" 3 Aadhaar based e-KYC service vtc="" subdist="" dist="" state="" (v2.1) country="" pc="" po=""/> <LData lang="" name="" co="" house="" Aadhaar based eKYC service is available to general citizens street="" lm="" loc="" vtc="" only through certain empaneled agencies such as eSign Ser- subdist="" dist="" state="" country="" pc="" po=""/> vice Provider (ESP) and the infrastructure network is secured <Pht> base64 encoded JPEG photo of the by certain designated agencies known as Authentication Ser- resident vice Agency (ASA) and KYC User Agency (KUA). eKYC </Pht> service is hosted as a stateless REST based web service <Prn type="pdf"> base64 encoded signed over HTTPS and the details are sent as input data encoded Aadhaar letter for printing in XML. Figure 2 depicts Aadhaar’s eKYC webservice as </Prn> specified in eKYC v2.1 specification [9]. The specifica- </UidData> tion provides following information about element rc which <Signature/> represents the resident consent. </KycRes> “rc – (mandatory) Represents resident’s explicit consent for accessing the resident’s identity and address data from Aadhaar system. Only valid value is “Y”. Without explicit Figure 2: Aadhaar’s eKYC 2.1 API consent of the Aadhaar holder application should not call this API [9].” 4 Present model of eSign in India As can be seen from the specification, rc is a boolean con- sent and assumes that it has been transferred from resident In eSign version 2.0 [10], a resident first registers itself with to UIDAI unaltered. Although intermediate communication a front end application specific agency viz. a viz., Applica- channels between various entities from resident to UIDAI tion Service Provider (ASP). A resident can use either OTP are well secured and access to eKYC data is provided only based authentication or biometric based authentication. In after receiving explicit consent from resident, this way of case of OTP based authentication, OTP generation request taking consent from resident has two shortcomings. First is forwarded to UIDAI via ASP and ESP. UIDAI generates is that the consent is taken by a non-UIDAI entity and does an OTP and sends it to resident’s registered mobile number. not encode in itself a proof from resident that it is (s)he In case of biometric based authentication, resident gets his who provided the consent. This is because residents do not fingerprint/iris scanned through a registered device. After have any registered tamper proof crypto device which can be authentication phase, resident now initiates an eSign request used to encrypt user consent using resident specific PIN or through ASP by providing it the consent to use his/her eKYC, password. Second is that providing a boolean consent is too the document to be signed and his/her Aadhaar number. ASP broad, either an unconditional access is given to the whole calculates cryptographic hash of the document and sends eKYC information or no access is given at all. A resident it along with the resident’s consent and resident’s Aadhaar may wish to have a better privacy enhancing fine-grained number to ESP. ESP takes authentication proof from resi- access control to his/her eKYC data indicating details on dent, creates a random symmetric key S K and a ES P U I DAI www.astesj.com 349 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) Personal Identity Data Object (PI D). PI D encodes in itself based authentication). Other than that, in some use cases the resident’s authentication proof and the cryptographic such as Create Birth Certificate, Create Death Certificate, hash of the PI D object (S H A256(PI D)). ESP first encrypts Student Enrollment, etc., the application is most heavily used PI D with S K , second encrypts cryptographic hash during a certain time period (nearing the end of a deadline) ES P U I DAI of PI D (S H A256(PI D)) with S K and third en- which puts a sudden nationwide load on UIDAI services. ES P U I DAI crypts S K with public key of UIDAI (PB ). ES P U I DAI U I DAI 5 eSign model as proposed in [4] ESP now wraps them in a new object called “Auth” and sends it to UIDAI in eKYC request. UIDAI provides eKYC In [4], author explained two limitations of present eSign information to ESP. Using received eKYC information, ESP model and proposed a mechanism to address the same. The generates a Digital Signature Certificate (DS C) and provides first limitation is that in present model of eSign, eKYC data it to ASP. ASP provides the digitally signed document to the access reflects a restrictive self-only, full-resource and un- resident. limited access control. Author pointed out that the resident may wish to have a better access control mechanism re- ESP/KUA/KSA Resident ASP UIDAI flecting third-entity-also, partial resource, use-limited and time-limited. Generate Generate O OTP TP Aadhaar Number Generate OT P Resident Consent (use eKYC for eSign) Version ::: ::: Generate OT P f S K g ES O U I DAI PB U I DAI PID Generate OT P Biometric OTP ::: ::: S K ES P U I DAI OT P f S H A256(PI D) g S KES P U I DAI ::: Retrie Retriev ve e eKYC eKYC information information S ign Document Figure 4: Auth Object (eSign 2.0) Aadhaar Number S ign Document Resident Consent (use eKYC for eSign) Resident Consent (Gen Access Token) Version ::: ::: eKYC(Auth) f S K g ES O U I DAI PB U I DAI eKYC PID Biometric OTP ::: ::: S K ES P U I DAI Use Use ekYC ekYC to to prepare prepare DSC DSC and and sign sign document document f S H A256(PI D) g S KES P U I DAI U se eKYC to generate ::: digital signature Figure 5: Auth Object as proposed in [4] Digital S ignature The second limitation is that a resident has to authenti- S igned Digital cate himself/herself for each eSign request and include the Document corresponding authentication proof in each eSign request. If a resident wishes to eSign a large number of docu- ments, the initial authentication phase will comprise most of the overall eSign time. After taking necessary consent from the resident, his/her authentication proof be stored with ESP Figure 3: Sequence diagram of eSign 2.0 in first request and is reused in rest of the requests. In practice, the initial authentication phase in eSign re- A digital access token [figure 6] can be used to include quest is most time consuming since it involves either the claims from participating entities (ESP and UIDAI). A new manual text input (in case of OTP based authentication) or service named GenerateAccessToken is proposed to be intro- the physical scan of the fingerprint/iris (in case of biometric duced by UIDAI. www.astesj.com 350 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) ESP Data ESP/KUA/KSA Resident ASP UIDAI ESP Private Claims ::: ::: ::: ::: S K ES Pi ESP Public Claims Generate Generate O OTP TP Aadhaar No Generate OT P Resident Consent I D AS Pi I D ES P AS P Transaction ID Generate OT P ES P Transaction ID ::: ::: PR ES P ESP DSC Generate OT P PB ES Pi OT P UIDAI Data UIDAI Private Claims ::: ::: ::: ::: S K U I DAI UIDAI Public Claims eSign eSign document, document, generate generate Access Access T Tok oken en Aadhaar No Resident Consent S ignDocument I D AS P I D ES Pi AS P Transaction ID ES P Transaction ID GenerateAccessT oken(Auth) UIDAI Transaction ID Token ID Token Expiry Time eSigns Granted Access T oken ::: ::: PR U I DAI UIDAI DSC PB U I DAI Retrie Retriev ve e eKYC eKYC information information PR U I DAI eKYC(AccessT oken) Figure 6: Access Token Structure as proposed in [4] eKYC In this proposed model of eSign [figures 7, 8], resident first authenticates himself/herself using OTP or biometric based authentication and sends eSign request to ASP. ASP forwards this eSign request to ESP. ESP takes OTP and per- Use Use ekYC ekYC to to prepare prepare DSC DSC and and sign sign document document mission to generate access token from resident and creates an “Auth” object. This “Auth” object is created as before but U se eKYC to generate additionally including ESP claims as well. ESP sends Gen- digital signature erateAccessToken request to UIDAI including “Auth” object. After receiving this request, UIDAI creates an access token Digital S ignature including its own claims as well as claims received from ESP. UIDAI sends this access token back to the ESP. Now, ESP sends eKYC request to UIDAI including this access S igned Digital token instead of the “Auth” object. After receiving eKYC Document ; information from UIDAI, ESP generates Digital Signature Certificate (DSC) from it and provides the same to ASP. ASP embeds DS C in the document and sends the digitally signed document to the resident. For all rest of the eSign requests, ESP can reuse the same access token in eKYC requests and Figure 7: First call to eSign in eSign model proposed in [4] avoid the initial authentication phase. The paper also presented two usability scenarios, based 6 Privacy Aware eSign model on whether the eKYC information can be cached by ESP or not. If ESP is permitted to reliably and securely store In earlier proposed model [section 5] digital access token is eKYC information of the resident, even the repeated eKYC used to increase amortized performance of eSign by storing requests from ESP to UIDAI can be avoided. necessary claims from UIDAI and ESP. The same token can The paper also presented performance comparison anal- be enhanced to include claims from resident as well. A resi- ysis of proposed model with present model and found sub- dent can encode claims related to privacy and fine grained stantial improvement in amortized performance of eSign. access control of his/her eKYC data. A stricter PEaFGAC statements may be enforced centrally at UIDAI level and an www.astesj.com 351 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) overriding less strict rule can be supplied with each eKYC also encodes in it the purpose for which eKYC can be ac- request to grant access to the requesting entity. cessed (Purpose), required (eKYC) attributes of information seeker (AP) and eKYC information which can be provided to the requester (scope). If required, a user can have multiple ESP/KUA/KSA Resident ASP UIDAI privacy statements for his/her eKYC data represented by di erent tags. eSign eSign document, document, generate generate Access Access T Tok oken en S ignDocument AadhaarNo POI: name, dob Check f or Access T oken POA: U se Access T okeni f valid co, house, street, lm, loc, vtc, subdist, dist, state, country, pc, po LData: lang, name, co, house, street, lm, loc, vtc, subdist, dist, state, country, pc, po Retrie Retriev ve e eKYC eKYC information information Pht: <Base64 encoded JPEG photo of resident I f Access T oken is valid; Org: eKYC(Access T oken) dep, desig Other: email eKYC Figure 9: Least information assumed to be available from eKYC for this paper Use Use ekYC ekYC to to prepare prepare DSC DSC and and sign sign document document PS.ID: U se eKYC to generate PS.Tag: digital signature eSignDoc PS.Purpose: eSign Digital S ignature PS.AP: (email = *@finance.iitg.ac.in) OR (org = IITG AND org.dep = finance) OR S igned Digital (desig >= director) Document ; PS.Scope: poi.name, poi.dob, poa.country, Ldata.lang Figure 10: Example of a PEaFGAC statement Figure 8: Second call to eSign in case eKYC needs to be fetched again It is assumed that all entities which request eKYC data also have their eKYC information available with UIDAI. 6.1 Privacy and Fine-Grained Access Con- This include not just the users but the organizations such as trol (PEaFGAC) Statements for eKYC ESPs as well. To better know an entity (both users and orga- data nizations), it is proposed that eKYC fields are expanded to include more details such as entity type (indicating whether A PEaFGAC statement encodes in itself the scope of infor- the subject is a human or an organization), resident’s orga- mation which can be provided, the purpose for which the nization, resident’s department, resident’s designation, etc. information can be provided and attributes of recipients to When an entity attempts to access eKYC data of a resident, whom the information can be provided. These statements entity’s eKYC data and purpose for which the eKYC data is are comprised of small sub-statements which are combined sought are verified against PEaFGAC statement protecting using relational operators. Each statement is identified by a eKYC data to decide whether the requisite access can be numeric id and an alphanumeric tag. granted or not. Only if the access can be granted, will the An example of a PEaFGAC statement is presented in eKYC data be provided to the requesting entity. The eKYC figure 10. This statement encodes in it that the purpose for data provided to the entity is limited in scope by PEaFGAC seeking eKYC information should be eSign, seeking entity statement. For rest of this paper, eKYC data is assumed to must either have the email in domain finance.iitg.ac.in, or consists of at least the information presented in figure 9. must be working in finance department of Indian Institute of Technology, Guwahati (IITG), or must have a designation 6.2 PEaFGAC Token of director or above. The statement is uniquely identified by a statement identifier (ID) and has a small alphanumeric The token structure introduced in [4] can be enhanced to representational string (TAG). Other than these, the staement include resident claims including PEaFGAC statement [fig- www.astesj.com 352 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) Login to ASP ure 11]. Before sending an eSign request, resident creates a Generate nonce n1 DataR1 = I DRkPWRkPBBkn1R PEaFGAC token by sending a token generation request to i i i i T G M1 R ! AS P S ignR = fH(DataR )g 1 1 PRB UIDAI through ASP and ESP. During token generation pro- f loginReq(DataR ; S ignR ) g 1 1 PB AS P DataA = C  (n1 + 1) 1 R R i i cess, resident is redirected to UIDAI web page where (s)he T G M2 R AS P S ignA1 = fH(DataA1)gPR AS P provides OTP value for authentication and PEaFGAC state- f loginRes(DataA ; S ignA )g 1 1 PBB Generate OTP ment for privacy and fine-grained access to his/her eKYC Generate nonce n2 DataR2 = AadhaarNoRkCRkn2R data. Subsequently UIDAI verifies the OTP value and signs i i i T G M3 R ! AS P S ignR = fH(DataR )g 2 2 PRB cryptographic hash of the statement with its private key and f getot pAS PReq(DataR ; S ignR ) g 2 2 PB AS P Generate nonce n1 AS P stores the signed hash in resident’s private claims and stores DataA = AadhaarNo kI D k 1 Ri AS Pi the statement in plaintext in resident’s public claims section T G M4 AS P ! ES P License kT I D kn1 AS P AS P AS P i i i S ignA = fH(DataA )g 1 1 PR AS P of PEaFGAC digital access token. f getot pES PReq(DataA ; S ignA ) g 1 1 PBES P Generate nonce n1 ES Pi ESP Data DataE = AadhaarNo kI D k 1 R ES P i i License kT I D kn1 ESP Private Claims T G M5 ES P U I DAI ES P ES P ES P i i i ::: ::: ::: ::: S ignE = fH(DataE )g 1 1 PRES P S K ES P f getot pReq(DataE ; S ignE ) g i 1 1 PB U I DAI T G M6 R U I DAI f OT P g S ecureCellularNetwork ESP Public Claims DataU = returnS tatuskT I D k 1 ES P Masked MobileNok(n1 + 1) ES Pi Aadhaar No T G M7 ES P U I DAI S ignU = fH(DataU )g 1 1 PR U I DAI Resident Consent f getot pRes(DataU ; S ignU )g 1 1 PB ES P I D AS P DataE = returnS tatuskT I D k 2 AS P I D ES Pi Masked MobileNok(n1 + 1) AS P AS P Transaction ID i T G M8 ES P AS P S ignE = fH(DataE )g 2 2 PRES P ES P Transaction ID f getot pES PRes(DataE ; S ignE )g 2 2 PB AS P ::: ::: PR DataA = returnS tatusk ES Pi 2 Masked MobileNok(n2R + 1) T G M9 ES P R ESP DSC S ignA = fH(DataA )g 2 2 PRAS P f getot pAS PRes(DataA ; S ignA )g 2 2 PB PB ES P Generate Token Generate nonce n3 Ri DataR = C kn3 3 R R i i T G M10 R ! AS P S ignR = fH(DataR )g 3 3 PR UIDAI Data B f gentokAS PReq(DataR ; S ignR ) g 3 3 PB AS P UIDAI Private Claims Generate nonce n2 AS Pi ::: ::: ::: ::: DataA = AadhaarNo kI D kLicense k 3 Ri AS P AS P i i T G M11 AS P ! ES P T I DAS Pkn2AS P i i S K U I DAI S ignA = fH(DataA )g 3 3 PRAS P UIDAI Public Claims f gentokES PReq(DataA ; S ignA ) g 3 3 PB ES P Aadhaar No Generate nonce n3 ES P Resident Consent DataE = AadhaarNo kI D k 3 Ri ES Pi I D License kT I D k AS Pi ES Pi ES Pi T G M12 ES P ! U I DAI I D n3 ES P ES P i i AS P Transaction ID S ignE3 = fH(DataE3)gPR i ES P ES P Transaction ID f gentokU I DAIReq(DataE ; S ignE ) g i 3 3 PB U I DAI UIDAI Transaction ID Generate nonce n1 U I DAI Token ID DataU = U I DAIRedirectU RL (ForT akingPrivacyS tatement s)k Token Expiry Time T G M13 U I DAI ES P eSigns Granted PBU I DAIkT I DES Pkn1U I DAI S ignU = fH(DataU )g ::: ::: 1 1 PRU I DAI PR U I DAI f gen psU I DAIReq(DataU ; S ignU ) g 1 1 PB ES P Generate nonce n4 UIDAI DSC ES P DataE = U I DAIRedirectU RL PB U I DAI (ForT akingPrivacyS tatement s) T G M14 ES P AS P kPB kT I D kn4 U I DAI AS P ES P i i S ignE = fH(DataE )g 4 3 PR ES P f gen psES PReq(DataE ; S ignE ) g 4 4 PBAS P Generate nonce n4 Ri Resident Data DataA = f Present U I DAIRedirectU RL to Resident Public Claims Resident which request s him T G M15 AS P R to provide OT P V alue and Privacy statement skPB kn4 g U I DAI Ri ID, Tag, Purpose, AP, Scope PS1 S ignA = fH(DataA )g 4 4 PR AS P f gen psAS PReq(DataA ; S ignA ) g 4 4 PBB T G M16 R ! U I DAI f PEaFGAC PrivacyS tatement s g ID, Tag, Purpose, AP, Scope PBU I DAI PS2 PEaFGAC Token Generation Request DataR = C k(n4 + 1) 4 Ri Ri S ignR = fH(DataA )g T G M17 R ! AS P 4 4 PR PS3 ID, Tag, Purpose, AP, Scope B f gen psAS PRes(DataA ; S ignA ) g 4 4 PBB PR U I DAI DataA = (n4 + 1) 5 ES Pi T G M18 AS P ES P S ignA = fH(DataA )g 5 4 PR Resident Private Claims AS Pi f gen psES PRes(DataA4; S ignA4) gPB ES P H(PS1) i DataE = (n1 + 1) 5 U I DAI H(PS2) T G M19 ES P U I DAI S ignE = fH(DataE )g 5 5 PRES P H(PS3) i PRU I DAI f gen psU I DAIRes(DataE ; S ignE ) g 5 5 PB U I DAI Create PEaFGACT okenAT Ri DataU = AT k(n3 + 1) 2 Ri ES P T G M20 ES P U I DAI S ignU = fH(DataE )g 2 5 PR ES P f gentokU I DAIRes(DataE ; S ignE ) g 5 5 PB U I DAI DataE = (n2 + 1) Figure 11: Proposed PEaFGAC Token Structure 6 AS Pi T G M21 AS P ES P S ignE = fH(DataE )g 6 5 PRES P f gentokES PRes(DataE6; S ignE6) gPB AS P Figure 12 depicts the sequence and details of communi- DataA = (n3 + 1) 5 R T G M22 R AS P S ignA = fH(DataE )g 5 5 PRAS P cation messages among participating entities for generation i f gentokES PRes(DataA ; S ignA ) g 5 5 PB of a token. First column indicates the message identifier, second column indicates the participating entities and the Figure 12: Proposed PEaFGAC Token Generation protocol direction of communication and third column indicates what message is sent and how it is constructed. www.astesj.com 353 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) 6.3 Proposed Privacy Aware eSign model us- [11]. Because of space limitation, it is assumed that PEaF- GAC token has already been generated securely.Analysis of ing PEaFGAC statement for eKYC data the token generation request can be done similarly.BAN logic and PEaFGAC token is a well-known model used to find beliefs of participants in This section presents how PEaFGC statement for eKYC a cryptographic protocol. data and PEaFGAC token can be used to implement Pri- vacy Aware eSign. It is assumed that PEaFGAC token has O perator U sage Description already been generated as explained in section 6.2. It is also P j= X P believes statement X assumed that the communication channel between resident P C X P sees statement X and ASP is secured using SSL/TLS, between ASP and ESP P 7 ! X P controls X is secured using SSL/TLS and between ESP and UIDAI is #(X) Message X is fresh secured using dedicated secure leased lines. P $ Q P and Q share key K Figure 13 depicts the sequence and details of communi- K 7! P P has K as its public key cation messages transferred in eSign request in case eKYC P Q Formula X is a secret known needs to be fetched again. only to P and Q fXg Formula X is encrypted using K Login to ASP Generate nonce n1 hXi Formula X is combined with DataR = I D kPW kPB kn1 1 Ri Ri Bi Ri M1 R ! AS P formula Y S ignR = fH(DataR )g 1 1 PR f loginReq(DataR ; S ignR ) g 1 1 PB AS P DataA = C  (n1 + 1) Figure 14: Fundamental BAN operators 1 R R i i S ignA = fH(DataA )g M2 R AS P 1 1 PR AS P O perator U sage Description f loginRes(DataA ; S ignA )g 1 1 PBB Initiate eSign request M eSign of message M is done by eS ign R ES P CC A Generate nonce n2 Resident R through ES P DataR = M kconsent k 2 i use ekyc approved by CC A consent kC kn2 M3 R ! AS P genuse at R R i i eS ign R ES P CC A S ignR = fH(DataR )g 2 2 PRB = MkDS C f signdocAS PReq(DataR ; S ignR ) g R M 2 2 PB AS P = MkfeKYC kH(M)g k Generate nonce n1 R PR AS P R DataA = H(M )kAadhaarNo kI D k PB kS ignChain 3 i R AS P R i i License kT I D k AS P AS P i i = MkfeKYC kH(M)g k R PR M4 AS P ES P consent kconsent k use ekyc genuse at PB kfPB g k R R PR ES P n1 AS P fPB g ES P PR CC A S ignA = fH(DataA )g 3 3 PR AS P i secure f signdocES PReq(DataA ; S ignA ) g P j= E ! E P believes that communication 3 3 PB i j ES P Retrieve eKYC (reusing access token) and sign document from entity E to E is secure i j secure Generate nonce n1 ES P P j= E E P believes that communication i j I f AT is valid use it from entity E to E is secure j i M5 ES P ! U I DAI DataE = AT kH(M )kn1 5 Ri i ES Pi secure S ignE = fH(DataE )g P j= E ! E P believes that communication 5 5 PR i j ES P f kycES PReq(DataE ; S ignE ) g 5 5 PB between entities E and E is U I DAI i j Retrieve eKYC ES P secure in both directions Retrieve AT ! UC ! AP i ACT Perm P j= E ! E P believes that entity E has V eri f y whether access can be granted i j i based on above two parameter s: given permission for action M6 ES P U I DAI eKYC = eKYC o f resident sco ped i ACT to entity E by AT ! UC ! sco pe P j= C { E P believes that cookie C is R i R DataU = eKYC k(n1 + 1) 3 R ES P i i associated with logged-in entity E S ignU = fH(DataU )g 3 3 PR U I DAI C ! I D E E R R f kycES PRes(DataU ; S ignU ) g 3 3 PBES P i E j= E ! E E believes that it has securely R R R R Generate key pair PB PR using eKYC Ri Ri Ri communicated its identity I D S ignChain = f PB g k R PR i ES P to entity E through cookie C R E f PB g ES P PR i CC A DS C = f eKYC kH(M ) g k R M R i PR i i i R Figure 15: Extended BAN operators M7 AS P ES P PB kS ignChain Delete PR DataU = DS C kT I D k(n1 + 1) 2 R M AS P AS P i i i i S ignU = fH(DataU )g 2 2 PR ES P The security environment is assumed to be based on f signdocES PRes(DataU ; S ignU ) g 2 2 PB AS P Delev-Yao model in which all messages are communicated fM g = M kDS C i eS ign R ES P i R M i i i i DataA = fM g k(n2 + 1) over public channels and an attacker can see, modify, com- 6 i eS ign R ES P R i i i M8 R AS P S ignA = fH(DataA )g 6 6 PR AS P i pose and replay messages but cannot break cryptographic f signdocAS PRes(DataA ; S ignA ) g 6 6 PBB principles. The security environment also assumes that an V eri f y correctness o f eKYC; H(M) and M9 R $ R S ignChain in fM g i eS ign attacker can decipher messages if he has a valid decryption key. Some of the fundamental operators used in BAN logic Figure 13: Proposed Privacy Aware eSign model are defined in figure 14. An extension to BAN logic, defined in figure 15 is required to analyse the proposed model. 7 Formal Security Analysis of the Rules of Inference proposed model using BAN Logic [R1:] Message meaning rules concern the interpretation This section presents formal security analysis of the pro- of messages. They all derive beliefs about the origin of posed scheme using Burrows-Abadi-Needham (BAN) logic messages. www.astesj.com 354 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) PB For shared secrets, the inference rule is E j= 7! E , R R E j= C { S , R R P j= Q P, P ChXi E j= #n , Y R R E j= ffYg g = Y P j= Q B X R PR PB R R E C f CommM sgReq ( That is, if P believes that the secret Y is shared with Q and XkC kn ; R R sees hXi , then P believes that Q once said X. Y fH(XkC kn )g ) g R R PR PB R E i R S ecure E j= R ! E , R R [R2:] The nonce-verification rule expresses the check that E j= R B X a message is recent, and hence, that the sender still believes in it: P j= #(X), P j= Q B X [R8:] If receiver entity E believes that PB is pub- R E P j= Q j= X lic key of receiver entity E , n is a fresh nonce R E generated by E , E receives message of the form R R That is, if P believes that X could have been uttered only f CommM sgReq (Xkn ;fH(Xkn )g )g , then E be- E E PR PB R R R E E R R recently and that Q once said X, then P believes that Q lieves that X is sent by entity E and communication channel believes X. from E to E is secure and no message is observed, modi- R R fied or replayed by an intruder. [R3:] The jurisdiction rule states that if P believes that Q has jurisdiction over X, then P trusts Q on the truth of X: PB E j= 7! E , R R P j= Q ) X, P j= Q j= X E j= ffYg g = Y , R PR PB E E R R E j= #n P j= X R E E C f CommM sgReq ( Xkn ; [R4:] The seeing rule states that if a principal sees a for- fH(Xkn )g ) g E PR PB R E E mula, then he also sees its components, provided he knows R R S ecure the necessary keys: E j= E ! E R R R E j= E B X R R Pj=Q$P(;)PCfXg PC(X;Y ) PChXi K , , , PCX PCX PCX [R9:] If receiver entity E believes that communication Pj=7!P, PCfXg from all possible sender entities E to E (8i = 1:::n) is Pj=7!P, PCfXg 1 R R K K i , . PCX PCX secure, then E believes that communication channel to E R R is secure and no message is observed, modified or replayed by an intruder. Note that if P sees X and P sees Y it does NOT follow that P sees (X; Y ) since that means that X and Y were uttered at [R10:] If resident R believes that C is a cookie associ- the same time. ated with a unique session from resident R, PB is public key of entity E , n was a fresh nonce generated by R and R R [R5:] The fresh rule states that if one part of the formula is used in a previous request call from R to E , R receives a fresh, then the entire formula must be fresh. message of the formfCommM sgRes(Xk(n + 1);fH(Xk(n + R R 1)g )g , then E believes that X is sent by entity R P j= #(X) PR PB R E E R R and communication channel from R to E is secure and no P j= #(X; Y ) message is observed, modified or replayed by an intruder. [R6:] The belief rule states that if P believes one part of the [R11:] If sender entity E believes that PR is private key R E formula, then it also believe part of the formula. of sender entity E , PB is public key of receiver entity E , R E R n was a fresh nonce generated by R and used in a previous P j= (X; Y ) request call from E to E , E receives message of the form R R R P j= (X) fCommM sgRes (Xk(n +1);fH(Xk(n +1)g )g , then E E PR PB R R E E R R E believes that X is sent by entity E and communication R R channel from E to E is secure and no message is observed, R R Extended Rules of Inference modified or replayed by an intruder. [R7:] If receiver entity E believes that C is a R R [R12:] If sender entity E believes that communication cookie associated with a unique session from resident from all possible receiver entities E (8i = 1:::n) is secure, R, PB is public key with browser used by resident R, then E believes that communication channel to E is secure R R PB is public key of receiver entity E , n is a fresh E R R and no message is observed, modified or replayed by an nonce generated by R, E receives message of the form intruder. fCommM sgReq(XkC kn ;fH(XkC kn )g ) g , then R R R R PR PB B E i R E believes that X is sent by entity R and communication [R13:] An electronic signature (M ) is a valid signature R ieS ign channel from R to E is secure and no message is observed, only when resident verifies that three main parts in signature, modified or replayed by an intruder. viz., eKYC, H(M) and S ignChain are as expected. www.astesj.com 355 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) secure Assumptions AS P j= R ! AS P i i i secure R j= R ! AS P i i i The protocol makes several assumptions. The assumptions secure AS P j= AS P ! ES P i i i relevant for the discussion of this paper are listed below. secure ES P j= AS P ! ES P i i i secure [A1:] It is assumed that all sessions from all residents R ES P j= ES P ! U I DAI i i secure keeps their cookie C secret. U I DAI j= ES P ! U I DAI [A2-A6:] The scheme makes several assumptions about [G7:] Resident R must be sure that at the end what he public keys. For example, R believes that PB is public receives is indeed a digital signature on message M , signed i AS P i i key of AS P . Similar to this, other entities also make similar by resident’s private key and generated by the genuine ES P . i i assumptions. These assumptions are listed below. R j= M = M i i eS ign R ES P CC A eS ign i i PB AS P R j= 7! AS P :::(A2) i i PB Idealization AS P ES P j= 7! AS P :::(A3) i i PB ES P BAN idealization of communication messages in communi- AS P j= 7! ES P :::(A4) i i cation phase is shown in table 1 PB ES P U I DAI j= 7! ES P :::(A5) PB Table 1: BAN Idealization of Proposed Protocol (Part I: M1-3) and (Part II: U I DAI ES P j= 7! U I DAI :::(A6) M4-8) M1 AS P C flogin ( [A7:] AS P assumes that all valid cookies C i R I D kPW kPB kn1 R R B R i i i i are associated with a valid ongoing session from a fH(I D kPW kPB k R R B i i i unique valid user R already logged in to AS P portal. i i n1 )g R PR i B AS P j= C { I D 8i = 1::n i R R g i i PB AS P M2 R C floginRes ( [A8-A15:] R and AS P assumes that all nonce n (where i i i R C  (n1 + 1) is any integer used in the scheme) are fresh. Similar to R R i i fH(C this, other entities also make similar assumptions. These R (n1 + 1))g assumptions are listed below. R PR i AS P PB R j= #n :::(A8) i R M3 AS P C fsigndocAS PReq ( AS P j= #n :::(A9) i R M kconsent k i use ekyc AS P j= #n :::(A10) i AS P consent kC kn2 ); genuse at R R i i ES P j= #n :::(A11) i AS P fH(M kconsent k i use ekyc ES P j= #n :::(A12) i ES P consent kC k genuse at R U I DAi j= #n :::(A13) ES P n2 )g R PR i B U I DAI j= #n :::(A14) U I DAI ES P j= #n :::(A15) i U I DAI PB AS P M4 ES P C fsigndocES PReq ( H(M )kAadhaarNo k i R [A16:] It is assumed that when AS P receives message I D kLicense k AS P AS P i i of the form CommM sg(DataA ; S ignA ) from ES P , j j PB i AS P T I D kconsent k AS P use ekyc it has verified the validity of data, i.e., fS ignA g = j PB ES P consent kn1 ; genuse at AS P H(DataA ). The same assumption is made for all entities f H(H(M )kAadhaarNo k i R receiving messages of this form. I D kLicense k AS P AS P i i T I D k AS P Goals to be achieved. consent k use ekyc consent k genuse at Following are the goals which are envisaged to be achieved n1 ) g AS P PR i AS P by the proposed model. i PB ES P [G1-G6:] Sender entity must be sure that the data received M5 U I DAI C fkycES PReq ( by receiver entity is same as what was sent by it and is not AT kH(M )kn1 ; R i ES P i i modified, observed or replayed by an intruder after it was fH(AT kH(M )k R i sent by the sender entity. Similarly, receiver entity must n1 )g ES P PR i ES P be sure that the data received by it is same as what was i sent by sender entity and is not modified, observed or re- PB U I DAI played by an intruder after it was sent by the sender entity. www.astesj.com 356 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) M6 ES P C fkycES PRes ( Using I5 and I6, secure eKYC k(n1 + 1) (G3 : Proved) R ES P ES P j= AS P ! ES P i i i i i fH(eKYC k (n1 + 1))g ES P PR i U I DAI Using M4, R11, g secure PB ES P (I7) AS P j= AS P ! ES P i i i M7 AS P C fsigndocES PRes ( Using M7, R8, feKYC kH(M )g k R i PR i R secure (I8) AS P j= AS P ES P i i i PB kfPB g k R R PR i i ES P fPB g k Using I5 and I6, ES P PR i CC A secure (G4 : Proved) T I D k(n1 + 1); AS P j= AS P ! ES P AS P AS P i i i i i fH(eKYC kH(M )g k R i PR i R PB kfPB g k R R PR i i ES P Using M5, R7, secure fPB g k ES P PR i CC A (I7) U I DAI j= ES P ! U I DAI T I D k AS P Using M6, R11, (n1 + 1))g secure AS P PR i ES P (I8) U I DAI j= ES P U I DAI Using I7 and I8, PB AS P i secure U I DAI j= ES P ! U I DAI M8 R C fsigndocAS PRes ( M kfeKYC kH(M )g i R i PR i R (G5 : Proved) kPB kfPB g k R R PR i i ES P Using M5, R11, fPB g k(n2 + 1) ES P PR R secure i CC A i (I9) ES P j= ES P ! U I DAI i i fH(M kfeKYC kH(M )g i R i PR i R Using M6, R8, kPB kfPB g k R R PR i i ES P secure (I0) ES P j= ES P U I DAI fPB g k i i ES P PR i CC A (n2 + 1))g R AS P Using I9 and I10, i i secure (G6 : Proved) ES P j= ES P ! U I DAI i i PB [P7:] Using message M9 and rule R13, it can be de- duced that R believes that fM g is a valid elec- i i eS ign Analysis tronic signature. [P1-P6:] Using messages M1, M3 and rule R7, it can Using M9 and R13, be deduced that AS P believes that communication R j= fM g = fM g i i eS ign i eS ign R ES P CC A i i from R to AS P is secure. Using messages M2, M8 i i (G7 : Proved) and rule R11, it can be deduced that AS P believes that communication from AS P to R is secure. From i i these two deductions, it can further be deduced that 8 Conclusion AS P believes that communication between R and i i AS P is secure in both directions. This work is an extension of the work [4] on enhancing amor- tized performance of eSign by using digital access tokens Using M1, M3, R7, R8, secure including claims from ESP and UIDAI. In this work, the (I1) AS P j= R ! AS P i i i digital access token introduced in [4] is extended to include Using M2, M8, R11, secure privacy and fine-grained access control statements for access (I2) AS P j= R AS P i i i to resident’s eKYC data. This enhanced token can be used Using I1 and I2, by third entities to access the protected eKYC data with secure (G1 : Proved) better privacy and fine-grained access control rules enforced AS P j= R ! AS P i i i by the resident. A formal security analysis of the proposed model using BAN logic is also presented. Using M1, M3, R10, R11 secure (I3) AS P j= R ! AS P i i i Using M2, M8, R8, References secure (I4) AS P j= R AS P i i i [1] UIDAI, “Unique Identification Authority of India”, [Online]. Avail- Using I3 and I4, able: https://uidai.gov.in (2017). secure (G2 : Proved) AS P j= R ! AS P i i i [2] Wikipedia, “Aadhaar”, [Online]. Available: https://en.wikipedia.org/wiki/Aadhaar (2017). Using M4, R7, [3] Reserve Bank of India, “Master Direction - Know Your secure (I5) ES P j= AS P ! ES P Customer (KYC) Direction, 2016”, [Online]. Available: i i i https://rbidocs.rbi.org.in/rdocs/notification/PDF Using M7, R11, s/18MDKYCD8E68EB1 3629A4A82BE8E06E606C57E57.PDF, secure (I6) 2018. ES P j= AS P ES P i i i www.astesj.com 357 P. Bakshi et al. / Advances in Science, Technology and Engineering Systems Journal Vol. 4, No. 4, 347-358 (2019) [4] Bakshi, Puneet, Neelakantan Subramanian, and Sukumar Nandi. “Us- [13] Merkle, Ralph C. “A digital signature based on a conventional en- ing digital tokens to improve amortized performance of eSign.” 2018 cryption function.” Conference on the theory and application of IEEE 16th Intl Conf on Dependable, Autonomic and Secure Comput- cryptographic techniques. Springer, Berlin, Heidelberg, 1987. ing, 16th Intl Conf on Pervasive Intelligence and Computing, 4th Intl [14] Paquin, Christian, and Greg Zaverucha. “U-prove cryptographic spec- Conf on Big Data Intelligence and Computing and Cyber Science ification v1. 1.” Technical Report, Microsoft Corporation (2011). and Technology Congress (DASC/PiCom/DataCom/CyberSciTech). IEEE, 2018. [15] Chaum, David. “Blind signatures for untraceable payments.” Ad- [5] Paquin, Christian, and Greg Zaverucha. “U-prove cryptographic spec- vances in cryptology. Springer, Boston, MA, 1983. ification v1. 1.” Technical Report, Microsoft Corporation (2011). [16] Hardt, Dick. The OAuth 2.0 authorization framework. No. RFC 6749. [6] Chaum, David. “Blind signatures for untraceable payments.” Ad- vances in cryptology. Springer, Boston, MA, 1983. [17] Nakamoto, Satoshi. “Bitcoin: A peer-to-peer electronic cash system.” [7] Hardt, Dick. The OAuth 2.0 authorization framework. No. RFC 6749. (2008). [18] PKIA2017, “Development of Smart Authentication and Identifica- [8] Nakamoto, Satoshi. “Bitcoin: A peer-to-peer electronic cash system.” tion in Asia”, [Online]. Available: http://pkiindia.in/pkia/#preceding, (2008). [9] UIDAI, “Aadhaar e-KYC API Specification - Version 2.1”, [Online]. [19] CCA, “Pki framework in India”, [Online]. Available: Available: http://www.cca.gov.in/cca/sites/default/files/file http://www.cca.gov.in/cca/?q=pki˙frame work.html (2015). s/eSign-APIv2.1.pdf, 2017 [20] CCA, “Public key certificate classes”, [Online]. Available: [10] CCA, “eSign Service”, [Online]. Available: http://www.cca.gov.in/cca/?q=node/45 (2017). http://cca.gov.in/cca/?q=eSign.html (2017). [11] Burrows, Michael, Martin Abadi, and Roger Michael Needham. “A [21] CCA, “Empanelled eSign Service Providers”, [Online]. Available: logic of authentication.” Proceedings of the Royal Society of London. http://www.cca.gov.in/cca/?q=service-providers.html (2017). A. Mathematical and Physical Sciences 426.1871 (1989): 233-271. [22] Jones, Michael, John Bradley, and Nat Sakimura. Json web token [12] Rivest, Ronald L., Adi Shamir, and Leonard Adleman. “A method (jwt). No. RFC 7519. 2015. for obtaining digital signatures and public-key cryptosystems.” Com- munications of the ACM 21.2 (1978): 120-126. [23] Jones, Mike, et al. Cbor web token (cwt). No. RFC 8392. 2018. www.astesj.com 358

Journal

Advances in Science, Technology and Engineering Systems Journal – Unpaywall

Published: Jan 1, 2019

There are no references for this article.