Smart Cities, AI, Blockchain, and Hedera

May20
by Shahid Sharif on May 20, 2018 at 8:00 am
Posted In: Blockchain, Privacy

Title Graphic

Introduction

Smart cities, AI, Blockchain, are the new buzzwords these days.  In this post will be talking a bit about these technologies and their relationship to blockchain.I have been to a few meetups at The Blockchain Hub at York University in Toronto. The Blockchain Hub folks seem to be contributing a lot to the blockchain action in the Toronto area.  Of the meetups worth mentioning following come to my mind:

  • Smartcities, IoT, and Blockchain
  • AI and Blockchain
  • Hadera, a public version of the Hashgraph

Smart cities, IoT, and Blockchain

I totally understand smart cities and the use of internet of things, but the whole proposition becomes questionable where people throw the word blockchain in the mix.  There were claims of money saving and energy efficiency, what escapes me is what does blockchain have to do with all this.  It would have made sense if the presenter had spoken about a specific blockchain use case, apparently not.  The way I see it is that what makes a city or a home smart is the deployment of various sensors and control systems performing actions in unison.  IoT comes into play where all the control systems and sensors are connected together over IP.  This  central hub processes all the information flowing in from the IoT devices, and signals IoT devices to perform certain activities.

 

The only use case I see of the blockchain is when monetizing is involved.  IoT devices effectively could be charging other IoT devices and control systems for providing them the data they have collected.  For this collection, sharing, and charging for data a very fast blockchain technology has to be utilized.  The only blockchain that is capable of accomplishing such speed is IOTA Tangle, which is designed for this very purpose.  There is nothing stopping anyone from using existing database technologies such as MySQL, Oracle, etc.  It really depends on the architecture and requirements that the platform needs to address.

AI and Blockchain

This is the area where people have done presentations saying data is being stored on blockchains. As far as I know, current blockchains are not capable of storing a lot of data to begin.  Then comes the issue of data privacy.  Is the blockchain going to be private or public.  To date none of the private blockchains are robust enough.  AI and ML need very fast storage as well, and to date no blockchain based storage technology exists that can quench the needs of the AI/ML processing.

 

Hadera Platform

Hadera is a public blockchain platform that is based on the hashgraph consensus algorithm.  Swirlds is a US based company and developed hashgraph, and now Hadera. The blockchain is based on a Directed Acyclic Graph (DAG) algorithm, it is very close to IOTA Tangle blockchain.  Main difference in my eyes is that while IOTA Tangle does not have any transaction costs, Hadera transactions will incur some costs.  Charging for transactions is a great SPAM and DDOS protection approach.  Hadera will be operated by a board of directors from 39 large organizations, across the globe in multiple verticals.  Although the main principle of blockchains is de-centralization, this idea of Hadera being managed by a group of elders is totally negating it.  For a platform to be purely de-centralized, the platform decisioning should also be on chain just like Tezos is attempting to do.

 

Properties of Blockchains

The main properties of a blockchain are:

  • Distributed-highly available as there are multiple nodes.
  • Immutability– Data cannot be modified.
  • Replicated-all data is replicated across multiple nodes.
  • Transparency-all data written to blockchain is available to everyone to read. When it comes to crypto currencies, this property is questionable, hence introduction of privacy tokens that are trying to address the issue of privacy and fungibility.
  • Consensus-a mechanism to agree on writing data to the blockchain even though nodes are owned by parties who have no trust relationship with each other. While this aspect of trust is true for public blockchains, private blockchains operate in trusted environments. And the consensus mechanisms are usually monetary based for public blockchains and for private there are none.

 

Conclusion

Although blockchain is a cutting edge technology, it is not a solution to all problems. Always ensure you document the requirements first, and then look for a solution, and blockchain may well be the solution. So far teams are building blockchain based solutions looking to solve a problem, which is great for an ICO and collect money from poor souls who are just looking at it from “nice and shiny” aspect, and the fact that it is a great money multiplier.  Of all the ICO’s I have seen, almost 95% have been failures.

References

└ Tags: , , , , , , , , , , , , ,
Comments Off on Smart Cities, AI, Blockchain, and Hedera

Brief Introduction To Self-Sovereign Identity

May13
by Shahid Sharif on May 13, 2018 at 5:53 pm
Posted In: Blockchain, Encryption, Identity, Passwords, Privacy, Security

Brief Introduction to self-sovereign identity

Introduction

In this brief introduction to self-sovereign identity, we will talk about how we build identity systems to create trust.  Trust was something that was local and useful for establishing trust in a single domain.  The only issue with existing identity systems is that they are not trust worthy.  Still there is no good way to prove that you are a certain age, you have an account with a certain bank, etc.  It is very difficult for someone else to vouch for you.

Initially identity was siloed, then came federated identity, and now it is time for user centric identity, this is what self-sovereign identity is.

Siloed Identity

In early days of Internet you had separate credentials for every site on the internet.

 

Federated Identity

Then came Facebook, and Google where websites enabled authentication using your Facebook or Google credentials.

 

User Centric Identity

In user centric identity, aka self-sovereign identity, user is in control of their identity. Open and flexible, interoperable and portable, viable and sustainable.

Verifiable Claims

Verifiable claims allow us to digitally do what we would do at a bar, pharmacy, hotel with a driver’s license.  For example attributes on a driver’s license are called claims.  A claim can be a JSON document that has been signed in a specific way holding certain attributes. Important properties of verifiable claim are:

  • They are decentralized and contextual
  • Anybody can be a issuer, owner, or verifier
  • Verifier does not need to have any kind of relationship with the issuer, not commercial, contractual, or technical.
  • Verifiers make their own trust decisions
  • Credential owner decides what credentials they want to carry around

 

Decentralized Identifiers(DIDs)

Decentralized Identifiers (DIDs) are a new type of identifier for verifiable, “self-sovereign” digital identity. DIDs are fully under the control of the DID subject, independent from any centralized registry, identity provider, or certificate authority.[From <https://w3c-ccg.github.io/did-spec/>]

Some key characteristics of DID’s are:

  • DIDs are a string of digits , cryptonyms derived from the elliptic curve private/public keys.
  • The DID is written to the ledger
  • DIDs provide pairwise identifiers for every relationship to prevent correlation.  DID Descriptor Objects link DIDs to public keys and end points.
  • Verifiable claims allow third parties to provide identity owner with credentials they can use just like we do offline
  • Once the other system has your DID, they can lookup your public key, take a nonce sign it with their private key, send it to you, and then you can then sign the nonce with their public key and this way they can confirm that the person they are talking to is the person in control of the private keys.
  • They can then ask you for claims about information, create accounts associated with your DID.
  • Every DID has a unique Private keys, and something the user holds.
  • Every claim has a link to a schema , and the schema are written to the ledger. The claims schema tells you what the claim is about and what do the fields mean.
  • Anybody can write a claims schema and write that claim.

 

Key requirements

Any system that plans to implement self-sovereign identity, has to implement following mandatory requirements.

  • No data visible to network operators
  • No central database, which eliminates the issue with honeypots
  • Because it is distributed, there are no points of failure
  • Allows total privacy
  • Cannot track users across relying parties

 

Implementations

These are some of the implementations of self-sovereign identity

  1. uPort is using Ethereum blockchain.
  2. Blockstack is using bitcoin blockchain.
  3. SecureKey is using  Hyperledger Fabric blockchain.
  4. Sovrin is using Hyperledger Indy blockchain.

 

Conclusion

Current self-sovereign identity systems are still very crude, they are still missing some essential tooling.  Which will show up as the current platforms evolve due to learning from implementations.

└ Tags: , , , , , , , , , , , , ,
Comments Off on Brief Introduction To Self-Sovereign Identity

GDPR Impacts On Service Providers

May06
by Shahid Sharif on May 6, 2018 at 7:36 am
Posted In: Audit, Compliance, GDPR, Privacy, Risk Management

Title graphic for GDPR Impacts on Service Providers

Introduction

GDPR(General Data Protection Regulation) impacts on service providers seems to be a very popular topic.  I have published two shows, one explains What is GDPR? and the other about Privacy By Design principles.  The idea behind this series is to bring awareness about GDPR and this show focuses on service providers, as they seem to be very confused when it comes to GDPR compliance.  They are getting questions from their customers and are not sure how to respond.

Types of Service Providers

There are three types of service providers

  • IaaS: Infrastructure as a Service
  • PaaS: Platform as a Service
  • SaaS: Software as a Service

Roles

For each of the Service Provider types above, following roles can be assumed:

  • Role A: Storing info about EU citizens as a result of providing the service.
  • Role B: Storing info about EU citizens as they are your employees.
  • Role C: A regular service provider role, as in providing services to customers who might be handling EU resident data.

 

How am I impacted?

If you are a service provider assuming Roles A & B, you have to comply with GDPR Compliance.  Service providers assuming Role C will be impacted depending on what king of service they are providing.  If they are providing:

  • IaaS: This type of service providers will have not be directly impacted as a result of GDPR.  The customer consuming the service will have to ensure that the service provider is engaged in all processes that involve GDPR data.  For instance when it comes to data backups, the service provider does not know the exact location of the data, hence has no idea which backup has what data.  The customer will have to provide instructions to the service provider on which backup’s to destroy and provide a confirmation that the activity was indeed completed. The customer is purely responsible for GDPR compliance. The customer is the Data Processor & Data Controller.
  • PaaS: In this scenario, the platform has to be designed as per “privacy by design” principles to ensure all GDPR requirements are addressable such as data locations, data export format, retention, backups, etc.  The customer is responsible for ensuring that the platform they select is GDPR compliant. The service provider is the Data Processor and customer Data Controller.
  • SaaS: In this scenario, the software has to be designed as per “privacy by design” principles to ensure all GDPR requirements are met.  The software should be able to address following Rights of the Data Subject, Consent, Access, Deletion, Modification, Portability, not to be subject to automatic data profiling. As far as Breach notification goes, Data Processor will immediately notify Data Controller, and the Data Controller will notify the authorities and Data Subjects of the breach within 72 hours

 

Conclusion

The bottom line is that a service provider has to ensure the products they offer in the market are GDPR compliant and are designed as per  “privacy by design” principles.  There is no GDPR compliance or certificate that a independent 3rd party issues.  It will only become an issue when a breach is reported.  Furthermore, it might be easy for GDPR regulator to enforce it within EU, but it is a totally different story how it will be enforced or enacted outside of EU jurisdiction.

└ Tags: , , , , , , , , ,
Comments Off on GDPR Impacts On Service Providers

SOC2 Audit Planning

Apr28
by Shahid Sharif on April 28, 2018 at 3:45 pm
Posted In: Audit, Compliance, Risk Management

 SOC2AuditPlanningTitleGraphic

Introduction

When planning a SOC2 audit you have to ensure that all stakeholders are in agreement with participating in this audit.  Then you can start planning the audit.  You have two choices:

  • Hire the audit firm to create the control framework and also conduct the audit.
  • Your internal team creates the control framework and the audit firm conducts the audit against those controls.

In my eyes, the second option saves a lot of money and control owner fatigue, provided you have internal staff capable of undertaking these activities.

Planning

It is highly recommended that SOC2 Audit Planning team considers following areas below.

Trust Services Criteria

Previously called Trust Services Principles & Criteria, the new name is Trust Services Criteria.

Decide on which Trust Services Criteria to include

  • Security: The system is protected against unauthorized access, use, or modification
  • Availability: The system is available for operation and use as committed or agreed
  • Processing Integrity: System processing is complete, valid, accurate, timely, and authorized
  • Confidentiality: Information designated as confidential is protected as committed or agreed
  • Privacy: The system’s collection, use, retention, disclosure, and disposal of personal information are in conformity with the commitments in the service organization’s privacy notice and with criteria set forth in the Generally Accepted Privacy Principles (GAPP) issued by the AICPA and CICA

Key Business Areas

To ensure the success of this audit, ensure following stakeholders are in agreement with participating in this audit.

  • Business line VP
  • Product managers
  • Human resources
  • Change management
  • Corporate security
  • Incident Management(both technical and security)
  • Network Support
  • Server Support
  • Database Support
  • Storage Support

 

Audit Artifacts

Once you have identified all the stakeholders and you have their buying following items should be completed.

  • System description should be created by the product managers as it should outline what the system being audited does. The information should be enough to describe the system to the external party who is consuming the service and aligns with whatever service you are offering.
  • Control framework should be designed with input from the control owners. Controls owners must be informed that this audit focus is on Design and Operating effectiveness of the controls.  Hence the controls must be designed in such a manner that they can also be operated without any issues addressing the requirement. Once the controls are designed, the operational documentation will need to be created and team members trained to operate the control as documented.  This whole activity of control design and implementation can take upwards of six months in a large organization.

 

Conclusion

It is crucial that the control framework and system description are key to the success of your audit if you can ensure these are done correctly, half of the battle is already been won. Since this is going to be the year one of the audit, a SOC2 Type 1 will be conducted, where design effectiveness of the controls is required. To avoid year two becoming a challenge ensure that the teams start operating the controls as soon as they are designed.

└ Tags: , , , , , , ,
Comments Off on SOC2 Audit Planning

Blockchain Security Tools

Apr22
by Shahid Sharif on April 22, 2018 at 9:22 pm
Posted In: Blockchain, Security, Smartcontracts

Season 2 Episode 4: Blockhain Security Tools

Introduction

Basic blockchain architecture as it pertains to block creation and consensus mechanisms is very sound.  The algorithms used to accomplish the cryptographic functions might be questionable. Hence special consideration should be given to key management, key length, hashing algorithms, and the environment that activity is conducted in.  To date, none of the block chains have been hacked or maliciously modified, hence from that aspect we are safe. If you consider blockchain mechanisms to be the foundation, which is unhackable at this point, the next few layers above is where the problems start. In this show, I talk about various blockchain security tools currently available.

 

Basic Blockchain Ecosystem

The illustration below depicts the different layers that in my opinion comprise a blockchain ecosystem.

Blockchain Security Depicted in Layers

 

Layer 1: Consensus and Cryptographic functions.

Layer 2: Virtual processor executing code that executes smart contracts.  For Ethereum this would be Ethereum Virtual Machine(EVM) executing compiled solidity code. For bitcoin blockchain, this would be Virtual Processor executing script code.

Layer 3: Application Programming Interface(API) this performs multiple functions such as:

  • Converting smart contract code to bytecode
  • Wallet requests for transaction processing
  • Exposing blockchain explorer capability

Layer4: This is where outside world interacts with Layers 3, 2, and 1.

Weakest Link

The weakest link is Layer 4.  This is where all the problems start.

First, the wallets, if the owner does not protect the private key and passphrase or they are exposed, all the crypto held in that wallet can be lost.

Second, the smart contracts, if the smart contract code is not written properly then the inherent compiled bytecode that lives on the blockchain will have vulnerabilities.  If someone is able to exploit this particular vulnerability the impacts can be very damaging.  Just like the DAO hack which leads to over $60m getting stolen.

Some solutions

Since a smart contract is just code, it has to follow secure coding practices.  Although there are a lot of secure coding methodologies, and tools available for conventional programming languages such as C, C++, C#, Java, JavaScript, etc., there was nothing available for newly created smart contract languages such as solidity and script.  With the lack of secure coding practices & tools, coupled with inexperienced programmers in these new languages, it was a disaster waiting to happen.

Tools

Various organizations are now bringing out blockchain security tools to address this void.  Here is the list:

  • A platform should support conventional programming languages to ensure existing secure coding practices can be leveraged.
  • OpenZeppelin has created an open framework of reusable and secure smart contracts in the Solidity language.
  • Trailofbits has created following tools:
    • A repository that contains examples of common Ethereum smart contract vulnerabilities, including real code.
    • “Slither combines a set of proprietary static analyses on Solidity that detect common mistakes such as bugs in reentrancy, constructors, method access, and more. Run Slither as you develop, on every new check-in of code.”
    • “Echidna applies next-generation smart fuzzing to EVM bytecode. Write Echidna tests for your code after you complete new features. It provides simple, high coverage unit tests that discover security bugs. Until your app has 80+% coverage with Echidna, don’t consider it complete”.
    • “Manticore uses symbolic execution to simulate complex multi-contract and multi-transaction attacks against EVM bytecode. Once your app is functional, write Manticore tests to discover hidden, unexpected, or dangerous states that it can enter. Manticore enumerates the execution states of your contract and verifies critical functionality”.
    • They have also created some reversing tools just like Porosity below which converts bytecode to solidity code.
  • NCC Group had compiled a DASP (Decentralized Application Security Project) Top10 list
  • Porosity, a decompiler and smart contract auditing tool for Ethereum smart-contracts.

Other approaches

These are some of the attempts to address security in blockchains.

  • Ivy is a declarative language to provide Bitcoin Script developers “a high-level language that adds instructions to support additional functionality, including loops, state transitions (through transaction introspection), and program evaluation”.
  • Simplicity has been released by Blockstream. It is a “typed, combinator-based, functional language without loops and recursion, designed to be used for crypto-currencies and blockchain applications. It aims to improve upon existing crypto-currency languages, such as Bitcoin Script and Ethereum’s EVM, while avoiding some of the problems they face. Simplicity comes with formal denotational semantics defined in Coq, a popular, general purpose software proof assistant. Simplicity also includes operational semantics that are defined with an abstract machine that we call the Bit Machine. The Bit Machine is used as a tool for measuring the computational space and time resources needed to evaluate Simplicity programs. Owing to its Turing incompleteness, Simplicity is amenable to static analysis that can be used to derive upper bounds on the computational resources needed, prior to execution. While Turing incomplete, Simplicity can express any finitary function, which we believe is enough to build useful “smart contracts” for blockchain applications.”
  • DAML(Digital Asset Modeling Language) by Elevence, is a financial service industry focused smart contract language.
  • Microsoft Coco is a framework which allows “arbitrary blockchain networks to be integrated with it to achieve its benefits”.
└ Tags: , , , , , , , , , , , , , ,
Comments Off on Blockchain Security Tools