Post-Quantum Cryptography (PQC) – Future proofing for quantum-safe encryption !

      1 Comment on Post-Quantum Cryptography (PQC) – Future proofing for quantum-safe encryption !

Everything is hackable! During the RSA Conference 2017 Crypto panel, Prof. Shamir (the letter “S” in the RSA) said, “I think there is a higher chance that RSA could be broken by a mathematical attack.” and he also wondered to note “Quantum Computers” will be a reality soon! That said, the evolution of practical quantum computers are not far away, according to a recent MIT Technology review article, which highlighted most research works on Quantum computing are closer to a solution (Google Quantum Computer!). This means quantum computations can pose some serious threats to existing public-key cryptography mechanisms in use. Are they serious or deluded? Not really, It turns out that they are right to rave.

Even NIST believes on those expert predictions that within the next 20 or so years, the emergence of quantum computers will easily break all public key cryptography and digital signature schemes (ex. RSA, ECDH, ECDSA) currently being used. The impact on symmetric key mechanisms is not that much as it can be handled through larger key sizes (verified by using Grover’s algorithm and Shor’s algorithm — Both are commonly used for breaking Cryptography).

Impact of Quantum Computing on Common Cryptographic Algorithms (Source: NISTIR 8105)

Not surprising, last year (Dec 2016), NIST launched a Post-Quantum Cryptography project initiative to develop quantum-resistant public-key cryptographic algorithms that are secure against both quantum and modern computers currently being used and can also interoperate with existing communications protocols and networks. Currently. there are about 5 algorithm proposals for public-key post-quantum cryptography considered to be quantum-safe are being evaluated.

  • Lattice-based Cryptography: Based on the construction of cryptographic primitives using computational lattice problems. They are known to be secure assuming the worst-case hardness of certain lattice problems as it has proven to be difficult to estimate of the security of lattice schemes. In 2009, Craig Gentry introduced the first fully homomorphic encryption scheme, which was based on a lattice problem. Other known lattice-based cryptographic functions are Indistinguishability Obfuscation, cryptographic maps, attribute-based functional encryption. NTRU encryption and NTRU signatures have been researched for many years without anyone finding a successful attack.
  • Multivariate Cryptography: Based on solving multivariate equations. The Rainbow scheme is based on multivariate cryptography, which could be a potential signature scheme to provide the basis for a quantum secure digital signature.
  • Code-based Cryptography: Based on error-correcting codes, such as the McEliece and Niederreiter encryption algorithms and related signature scheme. EU Commission recommended McEliece public key encryption as a candidate for long-term protection against attacks by quantum computation.
  • Hash-based Cryptography: Based on Hash-based signature schemes like Lamport signature scheme (one-time signature and Merkel signature scheme based on Hash trees (also called Merkel trees — used in Bitcoin Blockchain).They are known to be secure as long as hashes are not invertible and it certainly depends on large hash sizes.
  • Supersingular Elliptic Curve Isogeny Cryptography: Based on the Supersingular elliptic curve and it works like Diffie-Hellman Key exchange methods and its implementation, it can be an alternative to Diffie-Hellman with forward secrecy that can resist and provide protection against quantum computations.

All are quite promising developments, with NIST investing on PQC initiatives newer algorithms and their prototype implementations are evolving faster. Lately, Google Research has evolved an implementation of Lattice-based Cryptography using Ring Learning-with-Errors (RLWE) algorithm has integrated into OpenSSL, which can be potentially leveraged as a potential alternative to current public-key encryption schemes for providing post-quantum security for TLS and IPSec/IKE.

Quantum-safe Blockchain ?

Looking into the Public-key infrastructure risks with the impact of quantum computing, As we think, Blockchain is potentially vulnerable because of its reliance on PKI based digital signatures and hashing algorithms. The heavy use of Hashing algorithms will have a lesser impact as the chain can be easily enhanced by upgrading it from SHA-256 to SHA-384 to SHA-512 and so on. (For example, Bitcoin address is just an SHA-256 hash of your public key).  The interesting aspect, in the proof-of-work miners world, there will be an unfair advantage to the miner who uses the quantum computer will get the biggest miner reward 🙂

Update (Oct 16):

How Google’s Quantum Computer Could Change the World (Wallstreet Journal, Oct 16)

https://www.wsj.com/articles/how-googles-quantum-computer-could-change-the-world-1508158847

References:

NIST IR-8105 – http://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8105.pdf

NIST PQC Project initiative – https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/

https://www.technologyreview.com/s/608041/first-quantum-secured-blockchain-technology-tested-in-moscow/

 

Bye Bye Oracle !

      No Comments on Bye Bye Oracle !

Thanks for everything, indeed I feel it as an amicable separation. From Sun JavaSoft (1999)  to Oracle Cloud Engineered Systems (Sep 2017), it has truly been my privilege and honor to work with many of the great tech leaders at Oracle/Sun.

Will certainly miss you all..will do connect over the net with my new experiences… I probably will be doing something more connected to Blockchain and FinTech! Ofcourse, I will be also doing more blogging now on… It’ll be easier now as I can assume that my views will not be taken as Oracle’s anymore 🙂

Ramesh

Application Container Security Guidance from NIST (Docker Containers)

      No Comments on Application Container Security Guidance from NIST (Docker Containers)

NIST released an Application Container Security publication (SP 800-190), which delves into the major security risks and concerns related to Container images, registries, OS, orchestration, network isolation. It also presents a long-list of proactive countermeasures and mitigation recommendations for the known risks and example scenarios on how to address container security threats with the recommended countermeasures.  Although it is a quite high-level document, it details well enough for evolving security architecture using container technologies particularly securing Docker containers and Kubernetes orchestrator.

Here is the publication:

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf

Unpacking HyperLedger Fabric 1.0 – Under the hood of a Permissioned Blockchain

      No Comments on Unpacking HyperLedger Fabric 1.0 – Under the hood of a Permissioned Blockchain

It’s been a while I had been following the “HyperLedger” project initiatives under Linux foundation –  it is growing faster than I thought (Not sure, when Oracle will join HyperLedger..probably they are annoyed by HyperLedger use of RockDB, CouchDB)! I attempted to test drive HyperLedger 0.6 before — it didn’t get me anywhere with too many dependencies.  That said, a couple of months ago Linux Foundation released HyperLedger Fabric 1.0,  quite promising as it claims to be a  blockchain platform for deploying private Permissioned Blockchain.

Unlike Bitcoin and Ethereum based blockchain network which allows unknown and anonymous entities collaborate and trust each other on transactions using a “Proof-of-work” based consensus protocol,  whereas HyperLedger Fabric 1.0 allows to establish and deploy a “Trusted Members only” blockchain which means everyone knows each other and their identities. This makes it so compelling to be used within a group of legal entities or consortium of organizations using a well-established Identity management or Federated Identities over trusted networks. More importantly, HyperLedger does not support a CryptoCurrency. Certainly, it makes a great case for HyperLeger Fabric 1.0 deploying Private and Permissioned Blockchain which significantly reduces the risks of privacy and confidentiality breaches in sharing information and trusted business process collaboration without intermediaries.

HyperLedger Fabric 1.0

If we unpack and deploy HyperLedger Fabric 1,0 and it’s components, we will find the following core components :

  1.  Membership Service Provider (MSP) –  It provides the Identity management service (for establishing a member-only permissioned blockchain) that allows enrollment of members and establishes rules and access control lists (authorization of access rights and privileges). It makes use of its own PKI provider (Certificate Authority – CA) to issuing Public/Private keypairs (ECDSA) and associated X.509 certificates that can be used to identify peer nodes, Orderer (Ordering services), and for all enrolled members. It provides all required cryptographic mechanisms and CA services intended for issuing, validating, managing and till revoking certificates and validating digital signatures (cryptogen). Each participating organization peers or member can have its own MSP on a HyperLedger fabric network.
  2. Chaincode (Smart Contracts) – It holds state and ledger data by managing the lifecycle of transactions representing the business logic, rules, and policies executed within a transaction as agreed to by the participating members of a HyperLedger Fabric network. Chaincode defines endorsement policy and instantiates them and assign which peers need to endorse the transactions.  It also initializes and manages the Shared Ledgers through transactions. In HyperLedger Fabric 1.0, the Chaincode submitted by applications runs in a separate Docker container. The Chaincode can be created using APIs like Go, Node.js and Java (in the future — according to spec).           
  3. Peers – They are nodes that maintain the state and copy of a shared ledger.  Peers are authenticated by certificates issued by MSP. In HyperLedger Fabric, there are three types of peer nodes depending upon the assigned roles:
    • Endorsing Peers (Endorsers) – The endorsing peers take up the role of endorsing transactions before it is ordered and committed as per the policy defined in Chaincode. The client application creating the transaction and sends it to endorsing peers as per the policy in chaincode.  The endorsement policy is instantiated at the chaincode of the client application and forwarded to the endorsing peers. The endorsing peer evaluates and validates the transaction and produces an endorsement signature and then returns it to the application. There may be one or more pre-specified set of endorsing peers involved as per the endorsement policy. The transaction is evaluated and declared valid only if it has been endorsed by the endorsing peers as per policy.
    • Ordering Service Nodes (Orderers) – All transactions from the network are received by the orderer and it orders and groups them and then packages the transactions and creates blocks. The orderer service delivers blocks to the committing peers allowed to be part of a Channel. The orderer services do not review transaction information. The orderer makes guaranteed atomic delivery of blocks to committing peers on the channel. The orderer supports multiple channels using a publish/subscribe messaging system (based on Apache Kafka and Zookeeper). The ordered provides a practical Byzantine Fault tolerance for failures without a single-point of failure.
    • Committing Peers (Committers) – They receive blocks from Orderer service, which already endorsed by the endorsing peers. The Committing peers ultimately commit the transactional state by adding the blocks to the ledger. Before commital, the peers validate or invalidate the transaction by verifying if the endorsement policies are met, authenticate the signatures and also verify the version info (if there is any double spending).
  4. Channels – To ensure private and confidential communication between privileged member nodes, HyperLedger Fabric uses the notion of “Channel” specific to members and their shared ledger. In simpler terms, each channel corresponds to a shared ledger and intended executing a transaction on the network between peers using that ledger. Channels help to partition the fabric exchange confidential private transactions with the isolation of traffic between members and establish data privacy by separation of ledgers per channel.  The separation of the ledger by defining the specific channel for each ledger and peer node memberships are defined in Chaincode configuration (configtx). It is stored in the Genesis block of the ledger, which also stores the members, policies, and anchor peers.  The Genesis block defines the read/write access on a channel. Realistically, this is accomplished by Kafka as each channel maps to Kafka topic.
  5. Shared Ledger  –  The ledger maintains an append-only, tamper-proof sequential system of record and log of all transactions and successful/unsuccessful state changes from the beginning as “cryptographic hash-linked blocks” submitted by all peer nodes in the Hyperledger fabric network. All transaction results are committed to the ledger as a set of Key/Value pairs. The ledger stores all key/values included in the transactions specific to the channel – It is also referred to as World State Database.  HyperLedger fabric by default configures a LevelDB in all peers as Key/Value pair database, however, users can use CouchDB.
  6. Gossip Network Protocol –  The Gossip protocol is being used for “data dissemination” and to manage discovery and identification of peers, relaying new block information and synchronizing the state of ledger information to all participating peers.  As the data being sent are signed and verified at the receipt, there is no chance for spreading messages from unauthorized members.

HyperLedger Transaction Flow:

Assuming the HyperLedger Fabric 1.0 up and running, in a typical transaction flow of asset exchange:

  1. All application users and peer node members are registered in the MSP and issued with Keys/certificates from the CA for authenticating the network.  The Chaincode representing the initial state is installed on the peers and the channels are active.
  2. The application client initiates a transaction (Client A makes a request to Client B to transfer an asset). The endorsement policy states that the request must be endorsed by Peer A and Peer B.
  3. The application submits a transaction proposal to the endorsing peers A and B.
  4. The endorsing peers receive and verify the transaction proposal and its signature, then executes the transaction and return a signed proposal response back to the application client.
  5. The application client verifies the responses from the endorsing peers. It assembles the response into a transaction and sends it to the Orderer service.
  6. The Orderer services order the transactions chronologically and package those transactions as blocks specific to a channel.
  7. The Orderer service delivers the blocks of the transactions to all the peers on the channel.
  8. The peers perform the validation of the blocks for endorsement policy, signatures verification and version info,  and finally appends the block to the chain and commit the state database – Notifies the application client.

Data Protection & Crypto Key security?

Just wanted to share a known risk:

  • HyperLedger Fabric certainly assures data privacy by providing support for segregation of channels between nodes based chaincode and ledgers and data confidentiality/integrity during transit using TLS 1.2 protocol.  However, there is no assurance for data protection at rest and security of cryptographic material, particularly private keys.  Users may choose to use File system encryption options like dm-crypt (Linux) or Bitlocker (Windows) and using PKCS#11 integrating Hardware security modules (HSMs) in each peer for securing private keys.

I will post the cheatsheet of detailed steps for putting together a HyperLedger Fabric 1.0 setup for testing purposes…  Stay tuned.  Indeed,  HyperLedger Fabric 1.0 is promising.  I also noticed, HyperLedger Fabric 1.0 has an optional HyperLedger Fabric CA — Which I am yet to review, that potentially give an option for integrating HSMs.

References:

https://hyperledger-fabric.readthedocs.io/en/latest/

Deciphering Blockchain – Role of Cryptographic Hashes and Digital signatures

      No Comments on Deciphering Blockchain – Role of Cryptographic Hashes and Digital signatures

In a Blockchain infrastructure, trust is built using cryptographic hash functions and Public-key cryptography using digital signature mechanisms.  If we unpack the building blocks of a typical blockchain infrastructure – It relies on a multi-party peer-to-peer transactional network backbone without relying on a central authority. On the blockchain network, the peers create transactions, collaborate on transactions, validate and verify the transaction for correctness and may choose to endorse or reject them using a consensus protocol. Each peer node on the network collects those series of transactions, once endorsed and committed by their peers they are grouped and stored as blocks in a single system of record keeping called Ledger. The copies of the blocks are distributed to the peers by replication and then the blocks are synchronized into each of their ledgers. To ensure “Proof-of-Work” and assuring the authenticity and data integrity of the ledgers in all peers with indelible record keeping, non-repudiation, and tamper-proof immutability, the stack of transactions are validated and endorsed by a multi-party consensus protocol that applies one-way hash functions and digital signatures in each block before it is stored in the distributed ledger. As a result, every committed blockchain transaction results including valid cryptographic material in the block.

Relevance of Hash and Signatures in Blockchain

Before we delve into blockchain representation of hash and digital signatures,  for those who needed some background on the usage and the relevance:

  • Creating a Hash is a mathematical/cryptographic function which takes an input message (alphanumeric string) and converts it to a fixed-length alphanumeric string. As each hash produced for a message is unique, it acts like a signature for the provided message and the hashing process is irreversible.  With hashes, the blockchain creates a linked list of data and a hash pointers which point to its previous block and its next block, hence it results in creating the blockchain. Use of hashes in the blockchain helps to demonstrate “Proof-of-Work”, assures maintaining data integrity and keeping the ledger tamper-resistant. In Blockchain, the cryptographic hash algorithms for creating hashes are SHA-256 and RIPMD-160.
  • Creating digital signature is a mathematical/cryptographic function based on public-key cryptographic mechanisms. Using public-key crypto algorithm, we can generate a Public/Private key pair both are mathematically linked. The private key will be kept secret by the owner and the public key can be distributed publicly. To create a digital signature, the owner/signer creates a one-way hash of the message (alphanumeric string) to be signed. Then the owner uses the private key to encrypt the hash. The encrypted hash is referred to as a digital signature. Creating a hash to fixed length value and encrypting the hash makes a smaller size which is easier to verify. To verify the digital signature, the receiver uses the public key to decrypt the hash and recomputes the hash for the message and checks to match the value of the hash sent to verify if the document is modified.  In blockchain infrastructure, a Wallet software program is used to generate the public/private key pair and store the private key of the owner. Each blockchain node owner owns Public/Private key pair, where the public key is used to create the hash addresses and the corresponding private key is used for signing (encrypting the hash).  The verification of the signature using the public key can be done by decrypting the hash and verify the hash value.  In a Blockchain, the public-key cryptographic algorithm used for creating the digital signature is Elliptic Curve Digital Signature Algorithm (ECDSA).

How is it being used in BitCoin?

In the bitcoin world, typically a bitcoin address is a 160-bit hash of the public key portion of a public/private key pair of a node owner. The bitcoin address represents a destination of a payment. “Pay to Public Key Hash (P2PKH)” is the standard format for representing Bitcoin address, it refers to Pay to a hash of a public key (P2PKH)of the owner – P2PKH addresses start with “1”.  Bitcoin also supports another format which refers to P2SH (Pay to Script Hash) address – which starts with 3.  In a typical bitcoin user scenario, the bitcoin wallet collects entropy (random numbers) and then uses it to create an ECDSA private key and then derives a public key related to the private key. Using public key (as P2PKH) the owner can send and collect bitcoin payments. To create a bitcoin address, the wallet hashes the public key with SHA 256 and the result with RIPEMD-160. The waller adds the bytes 00 as a prefix which is called the version byte (as a result P2PKH addresses starts with a base58 prefix 1) and four checksum-bytes (as error checking code) added at the end of the resulting hash string. In case of P2SH address, the sender pays to the hash of a script. In case of P2SH, the wallet uses the prefix 05 (as a result P2SH addresses starts with a base58 prefix “3”).  Thus the Private Key is used to generate a signature for each blockchain transaction (cryptocurrency) the owner sends out, which confirms that the transaction is initiated by the owner’s private key and it cannot be tampered by anyone. To receive a blockchain transaction (cryptocurrency) from a sender, the sender uses the hash of the owner’s public key which corresponds to the owner’s private key.

Creating a Blockchain address using Hash and Digital Signature (ex. Bitcoin Address)

Starting with the public key K, we created the SHA256 hash and then created the RIPEMD160 hash. As a result, it will produce a 160-bit (20-byte) number., where K is the public key and BA is the bitcoin address.

Bitcoin address BA =  RIPEMD160(SHA256(K))

In addition, we will add the Version Prefix and Checksum.  The resulting Bitcoin address is delivered to the users in “Base58Check” encoding.

An example P2PKH address would look like this:

1J43KLMCxcochXpLhjM7g3MxMMTHPj3zLXc

How about Ethereum?

Like Bitcoin, Ethereum also uses ECDSA algorithm for creating digital signature but for creating hashes Ethereum uses Keccak-256 as its hashing algorithm. Both Bitcoin and Ethereum use Cryptocurrency wallets programs to store public and private keys and interface with the blockchain network to enable users to send and receive cryptocurrencies.

How simple is a CryptoCurrency Wallet?

Blockchain is the most popular wallet that supports both Bitcoin and Ethereum networks.

Here is an example:

Example – BitCoin Wallet

Anatomy of the Blockchain and understanding “Proof-of-Work”

      No Comments on Anatomy of the Blockchain and understanding “Proof-of-Work”

We keep hearing the hype about Blockchain particularly its guarantee for securely providing tamper-resistant immutable record keeping. What it basically means that Blockchain records every transaction on the network, whether it is a single transaction of a payment or multi-step transaction of a workflow — Each transaction is represented as a block. Typically, the resulting blockchain ledger will be represented as a series of blocks connected together, where each block is made up of a header block that contains its metadata information, which includes its previous “parent” block HASH, Merkel root HASH and a NONCE, then followed a list of transactions. The blockchain in the ledger is established by referencing the “parent” block HASH.  The first block in the chain is referred to as “Genesis Block”, which is identified as “0”.  Any invalid block off of the chain, are referred as “Orphaned blocks”, which will be removed by the consensus protocol.

Genesis Block “0” of BTC (Source: www.blockchain.info)

For better understanding, you may visit www.Blockchain.info and take look at the “Block 0” (just type 0 in the search box), you should able to see the genesis block – the number of the transaction occurred was just ONE, you should see the HASH for this block, previous block HASH as “0000000000000000000000000” and you should see the HASH of Merkel root and the next HASH of the next block. Now, if you look at the “Block No. 150000” — You should see the number of transactions as 10, and see the HASHes of this block, previous block, next block and the hash of the Merkel root.

Block #150000 of BTC. (Source: www.blockchain.info)

So what is “Proof-of-Work”?

Based on my review, in a Bitcoin chain usually, it takes about 10 – 15 minutes for creating a block. In the Ethereum (TestNet), it takes about 5 seconds to create a block. If we look at the underlying process, in the blockchain network there are peer-to-peer nodes on the network who are intended to perform mining, who process by collecting the transactions relayed on the network and add them into a block – This process is referred to as proof of work.

Building the blockchain

Typically a block will represent one or more transactions. There is a Block reward attached to each block.  When the miner finishes building the block, the miner must solve a HASH puzzle applied on the transactions.  Only when a miner successfully solved the puzzle will be allowed to broadcast the block relayed on the network.  The block will include the solution to the puzzle in the block header, which is called a NONCE. Once the block is relayed on the network, the other peer miners on the network will receive the block and validate the block and append to their blockchain ledger. This assures only valid blocks are added to the chain and all other blocks are left as “Orphaned blocks”. To avoid orphan blocks, miners should always work on the longest chain as shorter chains usually have the stale blocks called “Orphaned blocks”.  The process of mining ultimately validates, finalizes and endorses the new transactions as a new block and append them to the blockchain ledger.

How can I test-drive Bitcoin or Ethereum?

To test drive Bitcoin or Ethereum blockchain, I would recommend using TESTNET of Bitcoin or Ethereum networks. The cryptocurrencies mined on the test networks (TESTNET coins) has no real value. The TESTNET is intended for testing purposes and it provides a sandbox environment for testing Bitcoin or Ethereum frameworks. You can try mining your own test BitCoins or Ethereum TESTNET coins by setting up a BitCoin or Ethereum nodes. Usually, the HASH complexity is low and it is easy to solve the puzzle and obtaining a reward on the TESTNET.

https://en.bitcoin.it/wiki/Running_Bitcoin  (Follow the instructions for downloading bitcoind and make sure to use -testnet runtime option)

https://testnet.etherscan.io  (Follow the instruction for downloading Ethereum and using testnet)

For reviewing your mined blocks on the TESTNET, check out the following URLs (based on your choice):

https://testnet.blockexplorer.com  (For BitCoin TESTNET)

or

https://kovan.etherscan.io (Ethereum TESTNET Kovan)

https://ropsten.etherscan.io (Ethereum TESTNET Ropsten)

Goodluck

 

The Internet of Money – Getting excited about Bitcoin and Blockchain

      No Comments on The Internet of Money – Getting excited about Bitcoin and Blockchain

 

“Money is as old as our civilization” !  How technology has transformed the concept of money from exchanging rocks, metals, paper, plastic, and plastic to Bitoin..Andreas M. Antonopoulos breaks down everything to layman terms even I can understand!  How people and network-centric and protocol form of cryptocurrencies will dominate the next centuries allowing a new financial integration that the world has never seen before..

If are curious to know more, this book is a collection of talks by Andreas and aims at getting people excited by the possibilities of Bitcoin, the platform, the blockchain and decentralized, network-based currencies.

Read this book.

Blockchain – Cutting through the hype !

      No Comments on Blockchain – Cutting through the hype !

First, I am not a BitCoin investor or miner (perhaps in the future)…but it’s been a while I had been following BitCoin’s underlying technology called “Blockchain”!  In fact, Bitcoins value hangs on the trust provided by Blockchain technology! Quite fascinating – Blockchain facilitates a way where multiple parties who remain anonymous can trust and collaborate each other using a consensus-based protocol and without using a central authority. Certainly, it introduces us to a brave new IT world relying on programmable transactions on a network using distributed ledgers built using PKI based cryptographic mechanisms!  The distributed ledger fabric assures a shared system of trusted record keeping for a business process where multiple business stakeholders can participate and the ledger is shared between the members and each maintains their own copy of the ledger.  As it is a distributed ledger over the network, there are no intermediaries or central authority, and the process is very transparent, auditable, tamper-resistant and there is no risk of ledger tampering and fraud.

In a typical scenario, when a transaction occurs, each transaction is added to a block. Each block is connected to one before and after in the ledger as a chain. This means groups of transactions blocked together and fingerprinted using hashing mechanisms and appended to the ledger as part of the chain.  The blocks are irreversible. More importantly, no transactions can be added to the chain without the participating members’ consensus. The consensus is built using a set of policy checks that provide full-circle validation including identity verification, versioning and endorsement for the correctness of the transaction flow since the beginning of the transaction and till its commitment. Once committed to the ledgers, blockchain provides a single system of record for the business.

Not just Cryptocurrencies…Blockchain can have other deployment Models!

Blockchain is usually deployed in one of the following three different deployment models —

  • Permissionless Public Blockchain – Deployed over Internet accessible by anonymous entities (ex. Bitcoin world)
  • Permissioned Private Blockchain – Members trusted based on Identity management process within or a group of organizations or a consortium of legal entities using their Federated Identities over Trusted networks.
  • Private Blockchain – Typically deployed within an organization’s Intranet

Just not because I am passionate about its cryptographic underpinnings, by design the data exchanged and stored in Blockchain network remains trusted and tamper-resistant by distributing them with a shared set of business processes and rules using smart contracts and a consensus protocol that builds on endorsement policies and correctness of committed transactions, assuring they are authenticated, authorized and cryptographically signed and verified using hashing and multi-signatures.

We may think now that Blockchain may not solve all the problems for all IT business models…however, it is NOT a hype as there are many viable use cases for this technology, where trust of business transactions and data are deemed critical. Indeed, sooner in the blockchain we all trust!

Before I get started, I found the BBC story on “Bitcoin and Blockchain” very helpful:

BBC Story: Bitcoin and Blockchain

Good old memories from Java Keystore (JKS)

      No Comments on Good old memories from Java Keystore (JKS)

Thanksgiving holidays! Had great time meeting with a bunch of my old friends from Javasoft! Back in the days (~1998) I was working at Sun Microsystems and was part of a team working on Java Keystore.  It was a lot of fun..still remains fresh on my mind! It’s been a while I played with Java. Can’t believe JKS still remains as part of every JDK install to support storing keys and certificates.

Here is the poster that summarizes Java Keystore on one page:

Image credit – JKS team!!

Enjoy.

Automating Security and Compliance Assessments using SCAP – On-demand Scanning and Compliance Reporting with Remediation

      No Comments on Automating Security and Compliance Assessments using SCAP – On-demand Scanning and Compliance Reporting with Remediation

Manually assessing security controls, host and application configuration, access control policies, software patch levels and creating on-demand compliance readiness reports has always been a daunting task, especially when it is critical to adhere standards and regulatory mandates.  Not only those processes are very time consuming and they are also highly prone to human errors.  It becomes even more complicated when Security professionals unfamiliar with the target resource often struggle to identify technical controls, particularly to find ways to answer the following questions:

  1. Does the hosted system and applications meet the organization’s security policies?
  2. Does the hosted system and applications are configured right and patched to the appropriate levels addressing all known vulnerabilities?
  3. How can we review default configuration settings, ports, protocols, and services are effective and in use?
  4. How can we perform individual checks for critical security controls and report the results of each of those checks performed?
  5. How to measure risks in terms of metrics for vulnerabilities assigning severity levels?

Answering those questions becomes, even more, harder if those processes need to be repeated for periodic reviews and to sustain compliance mandates. Thus, it is extremely critical to automate using a standards-based approach that is easily repeatable to help on-demand evaluation and reviews. This will help quickly review system configurations, installation and presence of minimum required security policies, updates, patches,  system security configuration settings and all known vulnerabilities related to unnecessary ports and protocols and finally minimization of hosted applications in alignment with industry standards (such as PCI-DSS) and regulatory mandates such as HIPAA, FISMA and others.

What is SCAP?

Based on the NIST Special Publication 800-53 (SP 800-53) controls framework, the “Security Content Automation Protocol  (SCAP)” is a NIST defined standard to enable automation of vulnerability management, vulnerability measurement, and security compliance assessment for systems.  The scripts follow standards using “Open Vulnerability and Assessment Language” (OVAL) and Extensible Configuration Checklist Description Format (XCCDF). A typical SCAP implementation will include the following components:

  • Common Vulnerabilities and Exposures (CVE) – Industry standard for Enumeration for software vulnerabilities using Common name identifiers 
  • Common Platform Enumerations (CPE) – A structured naming convention used to identify IT systems (hardware), platforms (operating systems), and packages (applications).
  • Common Configuration Enumeration (CCE) – A stand for uniquely identifying security-relevant configuration elements for applications and operating systems.

Additionally, it also includes components for Risk measurements:

  • Common Vulnerability Scoring System (CVSS) – It facilitates a standardized way to qualitatively assess and measure by capturing the characteristics of a known vulnerability and computes a numerical score specifying its level of severity (such as low, medium, high, and critical). The severity levels help to assign a score to a vulnerability and in turn, it helps security auditors to prioritize risk.
  • Common Configuration Scoring System (CCSS) – It provides a NIST standard framework for measuring the severity of software security configuration issues.

Making all these components working together,  Redhat has delivered “OpenSCAP” an Open-source implementation of SCAP standard, which is available for performing automated vulnerability management, measurement, and policy compliance evaluation on Linux, BSD, Solaris and several Web servers. Lately, there is an on-going effort for porting OpenSCAP on Microsoft Windows is available and final release in progress.

OpenSCAP provides a complete framework of libraries and tools to perform configuration (configuration scanner) and vulnerability scans (vulnerability scanner) of a local system by evaluating both XCCDF benchmarks and OVAL definitions,  generate the appropriate results with a compliance score. If anomalies exist it will provide remediation guidance. The OpenSCAP implementation also includes pre-built assessment profiles for common configuration requirements, such as DoD STIG, PCI-DSS, CJIS, and meeting Redhat recommended security for Cloud Provider standards.  The pre-built assessment profiles can be modified/tailored to create custom assessment profiles.  Once the assessment scanning is complete, OpenSCAP generates an HTML formatted report enumerating the results of the tests passed and failed to highlight the severity and the final compliance score for the system.

OpenSCAP Report: Compliance score report

List of tests: Passed/Failed and Severity levels

Remediation Script for Failure

How to install and use OpenSCAP ?

To install OpenSCAP on Linux OS, you are required to download and install OpenSCAP scanner and Security guide content:

# yum -y install openscap-scanner scap-security-guide

To customize and modify Security Assessment profiles to meet an Organizational policy, you may choose to tailor an existing profile to meet your needs. To download tailoring utility:

# yum -y install scap-workbench

To list of assessment profiles for use on an RHEL 7 server:

# oscap info /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml
Document type: Source Data Stream Imported: 2015-10-02T06:17:44

Stream: scap_org.open-scap_datastream_from_xccdf_ssg-rhel7-xccdf-1.2.xml Generated: (null)
Version: 1.2
Checklists:

Ref-Id: scap_org.open-scap_cref_ssg-rhel7-xccdf-1.2.xml Status: draft
Generated: 2015-10-02
Resolved: true

Profiles:
xccdf_org.ssgproject.content_profile_standard

xccdf_org.ssgproject.content_profile_pci-dss

xccdf_org.ssgproject.content_profile_rht-ccp

xccdf_org.ssgproject.content_profile_common

xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream

Referenced check files: ssg-rhel7-oval.xml

 

To start an OpenSCAP assessment scan on a RHEL7 server (Run the following command in a single line):

# oscap xccdf eval  –profile xccdf_org.ssgproject.content_profile_rht-ccp

                    –results-arf arf.xml –report report.html /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml

Reports

The assessment process usually takes about 15 minutes on a latest Intel Xeon server, depending on the choice of assessment profile and number of rulesets included. Using SCAP Workbench will provide you a complete overview of the results and the final reports will be available in HTML for download or it can be streamed into a dashboard (like Redhat Satellite).

Further References and Resources:

OpenSCAP.org

NIST SCAP Standards

SCAP Benchmarks for Operating Systems, Web Servers, and Applications

  • Choose Tier-III “Should work in SCAP Validated Tool”,  you should see benchmarks for Web servers, Databases, Operating Systems, and many popular software utilities.