Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Verifiable Logs and DLT: A recipe for smashing UCC using hashing

Fifth Elephant Conference Presentation

  • Be the first to comment

  • Be the first to like this

Verifiable Logs and DLT: A recipe for smashing UCC using hashing

  1. 1. Verifiable Logs and DLT: A recipe for smashing UCC using hashing RAKSHA M P
  2. 2. RAKSHA M P - Blockchain Developer @ CTO Office,Wipro Limited. - 2 years experience in Blockchain world. - Worked on platforms like, Ethereum, Multichain, Bitcoin, Zero Knowledge Proof, Hyperledger. - Have worked on different blockchain projects and have published multiple medium articles online. - Presented paper on TRAI UCC Solution @ Third Blockchain Workshop, IIT Bombay. Contact Info: rakshamp95@gmail.com raksha.p82@wipro.com Find me on: https://www.linkedin.com/in/raksha-m-p/ https://medium.com/@raksha.p82
  3. 3. • UCC - Unsolicited Commercial Communication. • TRAI – Telecom Regulatory Authority of India. • DLT – Distributed Ledger technology/Blockchain. • TSP – Telecom Service Provider. • TAP* – Terminating Access Provider, Subscriber is registered with. • OAP* – Originating Access Provider, a RTM is registered with. • IR – Independent Registrar, a custodian for data store in the eco-system of commercial communication. • RTM – Registered Telemarketer which sends out Commercial Messages. • UTM - Unregistered Telemarketer which sends out Commercial Messages. • Auditor** – Entity which audits the validity of message delivery as per user preference and in common user preference. • Headers/ HeaderId - Identifier identifying the sender of the message. • Template/ TemplateId – Identifier identifying a particular category of message. * For a message, TAP and OAP might be same. ** An auditor might be an organization like TRAI or even other Originating Access Provider a RTM is registered with Glossary
  4. 4. UCC OVERVIEW
  5. 5. What is UCC??
  6. 6. © 2017 Wipro wipro.com confidential 6 Key ecosystem Stakeholders TRAI’s Ask THIRD TRAI REGULATION FOR UCC The Telecom Regulatory Authority of India (TRAI) has come up with the new guidelines for curbing spam calls and messages demanding the applicability of Blockchain technology.TRAI Content providers Customers/ Users Telecom Service Providers Scrubber Entities Telemarketers The focus of this proposed regulation is to strengthen the whole ecosystem, and to bring all the participants together where exchange of information will be seamless, the customer preference & convenience is taken care of, the processes across systems is streamlined and leads to reduction in fraudulent activities  Perform a regulatory role and exit the day-to-day operational activities.  Fine grained permission system that will allow customers a choice based on evolution and allow customers to explicitly grant consent.  An easier way to help block UCC both from RTM and UTM.  A DLT system that will enable various players to exchange above information.
  7. 7. The need for a system including DLT: • The business case for DLT is the following : Cost of Regulation is high ( manual, time consuming, expensive, judicial complaints , victimization etc.) • Other business cases are : a) Regulator is part of the system and does parts of the job. b) Unbundling TRAI so that it can be leaner and better. NEED FOR AN ECO-SYSTEM INCLUDING DLT
  8. 8. © confidential 8 DLT’s promise to UCC problem • Offers a revolutionary solution to fundamentally improve the regulation and delivery of commercial communications. • Allows all players in the ecosystem to share customer information and transaction histories securely over a distributed data infrastructure. • Authentic records of data. • Content providers and principal entities can be sure about regulatory compliances and safety of their data along the delivery chain. I. DLT Replicates data with security and accuracy – Entries Replicated to many Institutions in seconds. II. Granular Access Control - DLT has potential to offer solution with better management and control. III. Transparency and Privacy - Data maintained cryptographically through keys and signatures. IV. Automation - Adaptability of DLT to meet evolving requirements, intelligent and programmable contracts. CAPABILITIESVALUEADD
  9. 9. LIFECYCLE OF A COMMERCIAL COMMUNICATION SEARCH FOR A RTM NEGOTIATE RATES REGISTER HEADER'S SEND OUT MESSAGES For a Small Enterprise who wants to reach its customer, DEAL WITH COMPLAINTS
  10. 10. NEGOTIATE RATES REGISTER HEADER'S SEND OUT MESSAGES DEAL WITH COMPLAINTS 1. SEARCH FOR AN RTM
  11. 11. • RTM register's with National Telemarketer Register(NTR) maintained by TRAI, the centralized authority regulating the whole eco-system of commercial communication. • No way for a content provider to validate an RTM's not registered with TRAI. • Content Providers are not part of the commercial communication eco- system. • It is very difficult to take action against such RTM's in case of non- compliance. SEARCH FOR AN RTM : Current Eco-System
  12. 12. • RTM's to be registered with Independent Registrars(Private custodian of Customer data). • IR's maintains RTM Registration Entity and records the registration of RTM's in the DLT. • RTM's can ensure that the Customer data is maintained securely. • Content Provider also part of the decentralized, distributed eco-system of communication can view and identify the registered RTM's. • Content Providers, can base their selection of RTM's based on reputation scores associated with them, etc.. SEARCH FOR AN RTM : Proposed Eco-System
  13. 13. NEGOTIATE RATES REGISTER HEADER'S SEND OUT MESSAGES DEAL WITH COMPLAINTS 2. NEGOTIATE RATES SEARCH FOR A RTM
  14. 14. • No transparency in the relation between Content Providers and RTM's they are tied up with. NEGOTIATE RATES : Current Eco-System NEGOTIATE RATES : Proposed Eco-System • DLT, establishes transparency and auditability in the relationship of a Content Provider and an RTM.
  15. 15. REGISTER HEADER'S SEND OUT MESSAGES DEAL WITH COMPLAINTS 3. REGISTER HEADER'S SEARCH FOR A RTM NEGOTIATE RATES
  16. 16. • No concept of Header Registry. • RTM's used Header's provided by TRAI for message deliveries: • Sender IDs (Headers/Mask) for Promotional messages XY-NZZZZZ Where X stands for the code allotted to the Access provider; Y stands for the service area; N is the serial number (1-7) of partially blocked category; ZZZZZ indicates five digits allocated to particular telemarketer by an access Provider. • Sender IDs (Headers/Masks) for Transactional messages XY-ZZZZZZ Where X stands for the code allotted to the Access provider; Y stands for the service area; ZZZZZZ indicates six alphabets for company or organization sending transactional SMS. HEADER REGISTRATION : Current Eco-System
  17. 17. • IR's with business relationship with Telecom Access Provider's, is an authorized entity under regulation hosting Header Registration Facility(HRF). • HRF is an entity hosted for registration and de-registration of the header of a Content Provider. HRF also provides the Content Provider's, suggestion over available header's for registration. • The header registered are committed/written to DLT which keeps records of header(s), its purpose of sending commercial communications and details of sender to whom it is assigned in a safe and secure manner. • Privacy maintained in DLT for the committed header(s). HEADER REGISTRATION: Proposed Eco-System
  18. 18. Header Registration: Approach Against Conflicts • Conflicts here refers to two different content providers competing for the same header's while registration. • The traditional solution would be to provide a DNS like service and register the headers but these leads to land grabbing cases as we have. • A better option using DLT is as follows: • The header requested will be time-locked and broadcasted on DLT. • IR listening to the broadcast will check if there is already a prior registration of the same header for a different content provider. • On receiving any conflict from other IR's before the time locked period, that header allotment will be discarded. • If no conflict raised, after the lock time the header is committed to the DLT.
  19. 19. SEND OUT MESSAGES DEAL WITH COMPLAINTS 3. DELIVERY OF MESSAGES SEARCH FOR A RTM NEGOTIATE RATES REGISTER HEADER'S
  20. 20. • There are 2 types of messages in the eco-system: 1. Transactional message 2. Promotional Message • The Customer's have 3 choices for receiving commercial communication: 1. Fully Blocked 2. Partially Blocked 3. Not Registered in NCPR • The Content Provider needing to send message will send the subscriber list and message to their registered RTM. • The registered RTM will download the National Customer Preference Register(NCPR) data and filters the recepient subscriber list based on the NCPR data. • On filtering, the RTM forwards the Scuscriber list and intended message to the OAP which will route the message to the TAP's and from TAP's to respective Subscribers. MESSAGE DELIVERY IN CURRENT ECO-SYSTEM OAP Scrubbed List +Messages TAP Subscriber Number + Messages UserMessage
  21. 21. What is NCPR?? - A DND(Do Not Disturb) Registry hosted and governed by TRAI, where a subscriber can register/deregister his or her preference. Ways to Register Your Preference: • Dailing toll free number 1909 • Sending SMS to 1909 CUSTOMER PREFERENCE REGISTRATION(NCPR)
  22. 22. • Customer Data Not Private. • TeleMarketer's can misuse the NCPR data. • No filtering/scrubbing done at TAP's or OAP's end. • TeleMarketer's may share the NCPR data with any unregistered third party. • No Incentivization for the RTM's to stop misuse. DRAWBACKS OF CURRENT ECO-SYSTEM
  23. 23. • There are 3 different types of messages in the proposed eco-system: 1. Transactional messages 2. Promotional Messages 3. Service Messages • Message Delivery Mechanism includes concept of virtual Identity. • Content provider who wants to send any message, will send the message and subscriber list to IRs. • Based on the header of the message, the Scrubber functionality in the IR will filter out the subscribers based on the preference or consent registered by them. • IRs will create virtual IDs for filtered numbers & generates access tokens for the entities(TAP's and OAP's) to access mapped VIDs and writes it to the DLT. • The message with the Scrubbed list containing VIDs is forwarded to RTM. MESSAGE DELIVERY IN PROPOSED ECO-SYSTEM
  24. 24. • RTM's then forwards the message and Scrubbed list to its associated OAP which remaps the VID's to actual numbers for routing using the access token provided to it and later forwards the message to respective TAP's. • TAP using the access tokens provided to it, will do remapping of numbers and deliver's the message to respective Subscribers. • RTM have no access to the actual numbers and hence has no way to misuse the Subscriber data. MESSAGE DELIVERY IN PROPOSED ECO-SYSTEM IR Subscriber List + Message RTM Scrubbed VID's + Message +TxId OAP + Access Token Scrubbed VID's + Message +TxID TAP VID + Message +TxId SubscriberMessage
  25. 25. • IR in a business relationship with the Subscriber's TAP hosts the Customer Preference Registration Facility(CPF). • CPF is an entity hosted for registration and de-registration of Subscriber Preference. • IR also hosts Customer Consent Registration Facility(CCF), an entity for registration/deregistration of Subscriber Consent. • IR who is a custodian for Subscriber data store, periodically commits the Subscriber data to the DLT. • IR uses an approach involving Verifiable Logs which ensures the data privacy of the Subscriber data in an entity hosted for registration and de-registration of Customer Preference in the DLT. CUSTOMER PREFERENCE REGISTRATION(IN DLT)
  26. 26. Approach for Privacy using Verifiable Data Structure Verifiable Data Structure: • Establish transparency in DLT. • Builds eco-system of pure trust. Verifiable Logs: • Merkle Hash Tree, an append only log structure to store user preference and consent. • Merkle Root Hash, with Signature of IR committed to DLT. • Data will be logged in a tamper proof system(DLT), discouraging insider fraud. • Transparency established leads to accountability. • Feature of proofs provided by Merkle Hash tree is used to construct verifiable audit trail.
  27. 27. What are Merkle Trees?? • Merkle trees are a hash based data structure, where in each leaf node is a hash of a block of data and each non leaf node is a hash of its children. • The root hash(root of the tree), is a hash representing the whole tree. So if we want to know where data change has occurred then we can check if data is consistent with root hash and we will not have to traverse the whole structure but only a small part of the structure. • The root hash is used as the fingerprint for the entire data. • Merkle trees in a distributed setup is efficient for data verification and to check inconsistencies. • It maintains data integrity and uses hash functions for this purpose.
  28. 28. 3- LAYERED APPROACH FOR DATA PRIVACY USING MERKLE TREES At the first level user preference are hashed and stored in Sparse Merkle tree. The root hash is signed and hashed along with the timestamp (termed as SCT). Second level is the Merkle Tree representing the state of the all the customer of the Independent Registrar. The third level is a structure containing all the above Merkle Tree Hashes which are signed and stored in the DLT, shared across Independent Registrars and TSP’s.
  29. 29. Layer 1: • A Sparse Merkle Tree to store consent and preferences. • Each data hash appended at the leaf of the sparse merkle tree is signed and hashed along with the timestamp. • All modifications to the tree would be signed by the Independent Register • Multiple modifications in a single day produce one Root Hash. • The Merkle Tree helps in proving that only the consent for the entity under consideration is modified while the rest is untouched. • Each Sparse Merkle Tree would produce a Signed Root Hash. 3- LAYERED APPROACH FOR DATA PRIVACY USING MERKLE TREES
  30. 30. Layer 2: • A Merkle Hash Tree representing the state of the all the customer Preferences. • The leaves of this Merkle Tree are the Signed Root Hashes produced in layer 1. • The Root of the Merkle Hash Tree is calculated periodically (e.g.) once in 24 hours. • These Root Hashes are used to provide audit trails to prove the inclusion and exclusion. Layer 3: • The root of Merkle Hash Tree is signed and stored in the DLT, shared across Independent Registrars and TSP’s. • This entry would be a block in the DLT. • Each block would also contain the link to the previous entry made by the same entity. • This ensures there is no dropping of entries and the consistency of the DLT is maintained. 3- LAYERED APPROACH FOR DATA PRIVACY USING MERKLE TREES
  31. 31. Merkle Tree for Preference Store
  32. 32. Merkle Tree for Consent Store
  33. 33. DEAL WITH COMPLAINTS 3. COMPLAINT MECHANISM SEARCH FOR A RTM NEGOTIATE RATES REGISTER HEADER'S SEND OUT MESSAGES
  34. 34. • In a current eco-system the complaint can be registered by: • Dialling toll free number 1909; or • Sending the SMS to 1909 Drawbacks of the Current Compliant's flow: • Increase in cases of victimization. • Lots of manual intensive labor. • Long time window for UCC complaint resolution and action against defaulter. COMPLIANT REGISTRATION : Current Eco-System
  35. 35. • API facility operated by each entity to provide the proof of validity of data and hashes in the DLT. How Merkle Tree helps in auditing?? Merkle tree provides feature of proofs like consistency proof and audit proof to verify the data stored in the tree. • To provide the proof of authenticity of user registration, the IR can present an Audit proof which validates the inclusion of user's registration in the tree. • Additionally, Proof of Inclusion and Exclusion provides the proof of a specific preference or consent registered by the user. • Consistency proof validates the newer version of the tree is consistent with earlier version i.e. the earlier version is subset of new tree. AUDITING : Proposed Eco-System
  36. 36. Merkle Consistency
  37. 37. Proof Of Inclusion • For a particular user, Proof of inclusion includes two steps: 1. An audit proof over the Trusted Merkle Hash tree which verifies that a user actually exists in the tree. 2. Another audit proof which proves that a specific preference category is part of the Preference Sparse Merkle tree.
  38. 38. Proof Of Exclusion • Feature of Sparse Merkle tree, is to store in its index, all possible preference categories • This is used to provide proof on exclusion for a data. • For a proof of Exclusion, IR just has to just prove that the data at index for the given specific preference category is null.
  39. 39. Audit Proof Includes • Root of Trusted Preference Merkle Tree. • Merkle Path of Trusted Preference Merkle Tree to the user leaf. • Root of Sparse Merkle Tree of Preference store. • Merkle Path of Sparse Merkle Tree of Preference store to the specified preference leaf. • Data at the leaf of the specified preference(true for inclusion and null for exclusion).
  40. 40. COMPLAINT MODEL : Proposed Eco-System Complaint registered through an app, provided by the IR and hosted by the TAP. **Verifying the validity of the complaint before logging it. • If Complaint is valid: • Log the complaint in the DLT and notify the IR of the same. The Independent Registrar on getting a notification of a complaint does the following : • Check the dates from the SMS and then extract the Root Hash from DLT. • Constructs proof of the user's preference registered at its end. • On approval of proof from Content Provider, write the complaint into DLT and close it.
  41. 41. COMPLAINT MODEL : Proposed Eco-System How a complaint, logged in the DLT? • Every complaint is an asset in the DLT. • And these assets are bounded by endorsement policies which guides the state change of these assets. • If a complaint is valid, TAP invokes the chaincode to create a complaint asset(Open State). • The creation of an open state complaint asset follows a Multi-sig kind of a mechanism wherein the signature of both user and TAP are required. • The IR later processes the complaint involving the content provider. And once done, will write back to DLT and moves the complaint from open state to closed state. • The closing of complaint also includes a Multi-Sig mechanism, wherein the signatures of TAP, IR and Content Provider are required.
  42. 42. COMPLAINT MODEL : Proposed Eco-System • What happens if the IR does not respond in time ? -- IR's reputation is hit and reduced as per the rules. • What happens if the complaint is false/invalid ? -- If the complaint is invalid, Reputation of user is hit and reduced as per the rules. • What happens if this complaint is valid? -- Reputation of content provider is hit and reduced as per the rules.
  43. 43. COMPLAINT MODEL : Proposed Eco-System
  44. 44. GDPR ISSUES
  45. 45. GDPR Compliance • The current developing and upcoming world demands a data protection regulation like GDPR(General Data Protection Regulation). • Justice Srikrishna committee report on data protection claims that "Protection of personal data holds the key to empowerment, progress, and innovation." • Hence when building a futuristic solution for the UCC problem, one should also consider how it will pan out in the world of GDPR and privacy. • According to the GDPR regulation, any business processes that handle personal data must be designed and built with consideration of the principles and provide safeguards to protect data. • No personal data may be processed unless it is done under a lawful basis specified by the regulation
  46. 46. CONCLUSION
  47. 47. Comparison between the current and proposed ecosystem # Current Ecosystem Proposed Ecosystem 1 Privacy of Customer data Not private. Accessible to all in the central DND registry. Private in DLT using Verifiable logs 2 Consent Registration. No provision for Consent Registration. • Consent of the Customer recorded. • Consent over-rules preference during message delivery. 3 Eco-system set up. Centalized eco-system governed by TRAI. Decentralized, distributed eco-system with numerous players. 4 Filtering of message at TSP's There is no filtering functionality at TSP's end Filtering done at TSP's end before forwarding the messages to Subscribers. 5 Incentive model No incentive model. Incentive model involving reputation mechanism. 5 Content Provider's not respecting preferences Penalized based on complaint raised. • Content Provider's reputation decreased. • Reputation Scores < Threshold, then penalized. 6 Auditing messages by TRAI / TSP's Manual intervention to construct audit proofs. • Merkle Audit and Consistency Proofs
  48. 48. THANK YOU

×