BlockAuth, Decentralized Authentication for the digital world.

BlockAuth, is a new light weight, password-less authentication protocol, based on the same cryptography used in the bitcoin protocol. Eliminating centralised, server-side storage of shared secrets, and drastically reducing the impact of a compromised server. While designed to support a Block Chain Ledger within a range of financial transactions, can be applied to any existing and future Internet based system requiring secure authentication, especially all mobile platforms.

The majority of computer and internet authentication systems today, are based upon username and password pairs. The username is a unique identifier (usually an email address), the password the shared secret between the user and the system to which access is being granted. Some of the more security conscious systems (HSBC, BofQ, Amazon, Google ect) offer an additional one-time-password, usually based upon something one "has" to form an authentication triple.

The problem with these, and other systems, is the need to share and protect a secret, and the aggregation of these secrets within a centralised system:

• all smart cards need a shared secret key (typically DES key) loaded, CC, SIMs ect
• MFA and all one-time-passwords need a shared "seed" secret
• passwords are a shared secret

BlockAuth is a way to achieve secure, authentication using the same elliptic-curve cryptography as Bitcoin. Instead of using a shared secret, the client signs each request using a private key and the server checks to make sure the signature is valid and matches the public key. A nonce is used to prevent replay attacks and provide sequence enforcement, every BlockAuth signature is unique.
BlockAuth additionally supports mutual authentication between the client and the remote service.

BlockAuth is designed as a light weight, secure authentication service, which leverage's the Bitcoin free software base, be it with commercial EC curves, to allow mobile platform applications(APPS) to mutually authenticate with a wide range of internet accessible services or peers.

BlockAuth make use of a Secure Identification Number, or SIN, a fully decentralized, anonymous, secure identity, based on a the same bitcoin ECDSA key pair, SIN is an integral part of BlockAuth. The SIN supports both persistent, or ephemeral identifier, as well as the ability to opt out of anonymity as required. The SIN can be given to any number of remote services and there are for all practical purposes an unlimited number of SIN's for each client. The SIN is analogous to a bit coin address, as it takes the following form: base16check( 0x01 + ripemd160( sha256( pubkey) )

Typical authentication flow..
Client Application-> Server

1. SIN Registration: register your SIN with the remote service using a mechanism of your choosing generally, this takes place with client registration
2. Submitting Requests: requests are made over HTTP, with an x-signature:
1. generate a unique, unix timestamp
2. include nonce in your request
3. concatenate and sign URI + BODY with your private key, and provide it in x-signature
3. Remote Service: 
1. extract the public key from the ECDSA message signature
2. verify the signature
3. compare the public key against the registered SIN
4. Compose Response using similar form to above, but with remote Service details.
5. Response Body to include an optional expiry, pairing codes
4. Receiving Response: 
1. extract the public key from the response ECDSA message signature
2. verify signature
3. compare public key against with Remote Service SIN, received at registration.
4. Store any one-time use paring codes

BlockAuth Detached, Time Stamped, Signature

Based upon the international standard DER signature, extended with the addition of  "curve" and "timestamp" field elements. These extensions are downgrade comparable with the standard DER signature. This signature is also used within our Secure Block Chain Ledger, so can be utilised across multiple solution sets.

The timestamp field has several objectives, a) as the nonce, b) as a distributed, higher sequence number, c) as an expiry stamp for any key compromise processing, d) secure time stamping service for the signature. The time-stamp is appended to the message hash and hence bound to the signature.
The curve field supports our algorithm agility.

As a detached signature, this design can support the application of  multiple signatures if required.

The BlockAuth signature carries the public key. This removes the requirement to find the public key and allows secure linkage to the SIN attributes as part of any transaction processing.

DER ECDSA Extended Signature
C# Example Code
int recId
BigInteger r
BigInteger s
BigInteger unixtime
string  x-signature

            using (MemoryStream der = new MemoryStream())
            {       
                DerSequenceGenerator seq = new DerSequenceGenerator(der );
                seq.AddObject(new DerInteger(r.Value));
                seq.AddObject(new DerInteger(s.Value));
                // extensions
                seq.AddObject(new DerInteger(version.Value);
                seq.AddObject(new DerInteger(unixtime.Value);
                seq.AddObject(new DerOctetString(pubkey));
       
                seq.Close();
                x-signature  =  BytesToHex(encoder .ToArray());
         }

Example
pubkey:
"02326209e52f6f17e987ec27c56a1321acf3d68088b8fb634f232f12ccbc9a4575"
SIN:
"Tf3yr5tYvccKNVrE26BrPs6LWZRh8woHwjR"
x-signature: 
"304d02207693ad890971718ac5061a9abfdc2a699835e01cb296da8102a6b7d3c7b77e45022009f2b47605c01453d683ef4995660dcaff6e9927864d1bb016af67dc2787f40902011c0204557c38b2"

Note: Hex is used for clarity above, normally base64 encoding would be used for all byte[] structures.

BlockAuth Sessions

While one can  use the above dialogue to support a "stateless authentication" scheme, many existing systems make use of a "session" in which the above process is the initial handshake or login process. In order to support these types of systems, BlockAuth can optionally make use of ECDH key derivation process,  to derive an out-of-band shared session secret between the client and remote service or peer. This shared secret can be combined with the return "expires" time stamp to generate a secure "session token" for all subsequent requests. A typical usage is to combine this ephemerial secret with the HOTP protocol to produce a secure One Time Password solution.
Schemes which could make use of this shared secret are:

1. JSON Web Token scheme

2. AWS scheme

Signature = URL-Encode( Base64( HMAC-SHA1( DHSecret, UTF-8-Encoding-Of( StringToSign ) ) ) );

StringToSign = HTTP-VERB + "\n" +
    Content-MD5 + "\n" +
    Content-Type + "\n" +
    Expires + "\n" +
    CanonicalizedBitAuthHeaders +
    CanonicalizedResource; 

Pairing Token
BlockAuth supports the use of a paring token, this is a one-time-use token which can be used to access specific resources, via a specific role and or device ( mobile phone, tablet ect). This may be bond to a specific device Identifier, such as an IMEI code ect..

Replacing Usernames and Passwords

Simply replace username with a SIN, and password with x-signature, this provides a one time password approach, with no pre-shared secret.

Backward comparability: key the BlockAuth processing from the username SIN keyword prefix  "01" (base16 encoded)  which should be sufficiently unique, given most usernames are human related today.

BlockAuth is available for all Cognition API users, and SIN's will be provided along with the free ECDSA, and ECDH  keys and secure key pool chain available for all subscribers from the 1st July 2015.

C# Code
1. SIN Generation
                // Get sha256 hash and then the RIPEMD-160 hash of the public key.
                byte[] pubKeyHash = PubKeyHash;

                // Convert binary pubKeyHash, SINtype and version to Hex
                String SINversion = "10";
                String SINtype = "1"; //static
                String pubKeyHashHex = Utils.BytesToHexString(pubKeyHash);

                // Concatenate all three elements
                String preSIN = SINversion + _SINtype + pubKeyHashHex;

                // Convert the hex string back to binary and double sha256 hash it leaving in binary
                byte[] preSINbyte = Utils.HexStringToBytes(preSIN);
                byte[] hash2Bytes = Utils.DoubleDigest(preSINbyte);

                // Convert back to hex and take first four bytes
                String hashString = Utils.BytesToHexString(hash2Bytes);
                String first4Bytes = hashString.Substring(0, 8);

                // Append first four bytes to fully appended SIN string
                String unencoded = preSIN + first4Bytes;
                byte[] unencodedBytes = new BigInteger(unencoded, 16).ToByteArray();

                String encoded = Base16WithCheckSum.Encode(unencodedBytes);

Also see
1. Free hardware generated and protected Bitcoin Private key and key-chain.
2. Identity Theft and the Digital World..


Disclaimer The contents of this site should not be understood to be accounting, taxation or investment advice but rather as general product related educational information that may or may not meet your specific requirements.

Identity Theft and the Digital World..

Ones identity is something we take for granted (after all it is you), and expect the various organisation, including governments we deal with to protect our identity. Yet these same organisation are at the heart of the identity theft problem.

“Digital identity“ is the sum of all digitally available information about an individual. It is becoming increasingly complete and traceable, driven by the exponential growth of available data and the big data capabilities to process it. The issue addressed within this article is the ability to link both the Digital and physical worlds, and how a compromise within the digital world can affect the physical identity, i.e Identity Left..

The data elements which underpin, most widely used "personal" identifying data, are birth dates, names and addressees, and drivers licence numbers. The aggregation of this data, under pins our "identity", with regard to many Digital Transactions. Many organisations routinely collect this information, some like banks, use birth date continuously, even when precluded by the Privacy Act.
Today the collection of personal identifying data, has become epidemic, and grows each and every day, routinely night clubs, and hotels (with zero security protection, or regulations in place), photo copy an individuals drivers licence.  Banks photo copy drivers licences, birth certificates, even though not required under any legislation. With a drivers licence, a birth date and data readily available from a postbox or even available online, almost anyone can open a bank account online as "you" today.

Once your Identity is lost, it can become impossible to participate within today's digital and physical world, many have taken years to address their Identity after being stolen, properties have been sold from under owners.

In most of these cases, and almost all commercial transactions, within the digital world we all live in "Identity" is actually not required, what is required is positive "authentication".

A typical example is buying and selling or commerce, for most of history, this has been done via stored value tokens, or "money". Coins or notes issued by national banks have zero linkage to any Individual, they simply circulate within the community and are exchanged for goods or services.

The majority of commercial contracts are finalised with a "Signature" which also has zero identity requirements, the thrust of a signature is to support non-repudiation.


Enter The Digital World..
In this world everything changed, all of the previous 1000+ of years of  commerce was thrown away..
All of a sudden (in relative time), there was introduced the need to "Identify", primary due to an Orwellian need by governments and organisations to track various "individuals and their activities in the digital world, the infamous "Australia Card" was perhaps the best example, yet while rejected by the population, has been introduced via TFN's and drivers licences, and data aggregation, without the individuals informed consent.

Putting aside these "political" issues, and looking at the real risks associated with the wide ranging collection, centralized storage and sharing  of "identity" information, without even the most basic security.

There is simply no reasons for any individual to provide anyone with their birth date, ever, unless one wants to celebrate such an event.
If a bank wants to verify a client, then they need to preferably allow the client to provide an authentication "token" or they should provide one to the customer, in no case should a personally and irrevocable birth date be used, its simple... one cannot change ones birth date if the usage is compromised.

The key to securing any Identity, is the removal of the need for any "centralized solution, and to ensure the control of any "identity" remains solely with the Individual.

The solution to Identity Theft, is not complicated,
STOP:

• Collecting personal identifying data which is not required to perform the immediate activity, by the requesting entity.
• Storing any personal identifying data in any centralized system.
• Sharing or accessing any personal data without the explicit approval, on a per request basis by the Individual
• Storing aggregated personal identifying data in any System 
• Sharing personal data, outside of the initial receiving entity and system
• Routinely requiring personal identifying data as apart of an authentication process.

In order to prevent Identity theft, in all cases the Customer should be able to provide the "authentication token" to be used by any organisation when requesting authentication. This is very basic security and privacy requirement, and a part of the digital world today.

Authentication in the Digital World.
The most common form of authentication in usage today is the "user name" "password" duple.
The username is not required to identify the user, but rather to be used as a "synonym" and the shared secret is the "password".

The fundamental security flaw with this scheme, is the need to have a "shared" secret the password. if the "secret" is not keep secret or managed correctly then the authentication scheme will fail, read can be compromised. A credit card is a simple variant, i,e a CC number is the synonym and the Pin is the shared secret. there is nothing secret about the CC number.

A digital Solution for the Digital World..
As Identity theft is a by product of the increasing use of the digital world, then the same digital world needs to provide a solution.

The fully decentralized, anonymous, secure identity.
Enter the Secure Identity Number(SIN), this is a totally digital identity that may be securely used for any type of transaction within the digital world, including replacement of the traditional username/password.
A SIN(s) is the unique record identifier by which this identity will be known, the key concepts are:

• there is no centralized infrastructure or entity required
• the secure identity is under the total control of the Individual
• can securely support the full range of Identity and authentication requirements

Attributes:

• Ownership can be digitally proven with high assurance, and possible non-repudiation
• Disposable
• Optionally attach sequence of key-value pairs (public proof) and hashes (private proof) to your SIN record. 
• Start out as anonymous identity, and as required, support opt out of anonymity on a per SIN basis, by attaching identifying key-value pairs (real.name = "John Smith").
• All key-value pair updates digitally signed by SIN owner (private key holder)
• Third parties may offer digital attestations:
• Identity Verification, Inc. digitally signs a SIN as passing their 100 points check.
• Auction Provider, digitally signs a SIN as having a certain reputation score, on their website.
• Decentralized market users, digitally sign one another's SINs, building a decentralized reputation, social media.

Within the Cognition Public Block Chain Ledger, these signed  "attributes" are stored within industry standard DNS "TXT" records for the entity identified by the SIN. This is just one of the many possible options for securely linking and distributing public attributes to the World.

The technical bits

The solution makes use of existing global software and infrastructure, a simple add-on..

SIN, is a new form of identity based on a cryptographic key pair. SINs were originally proposed by Bitcoin Core Developer Jeff Garzik,

The SIN is analogous to a Bitcoin address, as it takes the following form:

base16WithCheckSum( 0x01 + 0x02 + ripemd160( sha256(k1) )

Where k1 is your public key from an ECDSA keypair. 0x0F is the special byte for SINs, and 0x02 is the type of SIN; in this case, an ephemeral or standalone identity.

This SIN can be shared openly with the world, as the corresponding private key is kept on the client-side and never transmitted over the wire, and never shared with any entity.

How does Secure Identity Number(SIN)  based  authentication work?
The general flow to authenticate a request is as follows.

• Key generation: Individual generates a key pair k using ECDSA (use a free ECDSA key chain service).
• SIN construction: with public key k1, concatenate the SIN version byte and hashed public key, then encode this in the base16WithCheckSum format.
• SIN sharing: register your SIN with the remote service using a mechanism of your choosing generally, this takes place with client registration.
• Submitting Requests: requests are made over light weight HTTP/JSON, with the x-signature and x-identity header:
• generate a unique, higher-than-previous nonce, we recommend using a "unix time" integer, and include in as the  nonce HTTP parameter of your request
• include your compressed bitcoin public key (hex encoded string)  in the  x-identity header 
• if JSON body is included, set content type to  "application/json"
• concatenate and sign base URL + URI + JSON with your private key, and provide the resulting bitcoin message signature as a hex encoded string in x-signature
• Receiving System: will validate request using x-signature and x-identity header:
• check x-identity against stored SIN
• use x-identity header and posted data to validate x-signature
• optionally check any attributes linked to the registered SIN.

The server will now verify the signature against the public key you've provided and the SIN you've shared previously (does not need to be a secret), confirm that the signed nonce is greater than this SIN’s previous nonces (preventing replay attacks), and subsequently authenticate the request.

Replacing Usernames and Passwords
The authentication scheme is directly compatible with the familiar username (or email) and password mechanic. The primary difference is that the password is never sent over the wire, in any format.
Using this mechanism, you can still provide the user with the experience of entering a username and a password, but locally use that password to decrypt the private key and subsequently use it to sign the request.

Advantages over existing authentication mechanisms
Gone are the days when a single hacker, can compromise an entire customer base's credentials, the removal of all shared secrets, is the key to improving on-line security. In the above, passwords are only used locally, to encrypt the private key.

• Support for per transaction (ephemeral)  as well as persistent SIN's to manage scope of any compromise. 
• Only a compromise of the client machine can endanger the system, and hardware backed ECDSA keys can readly address this possibility.
• Because the private key is never revealed to the server, it does not need to be exchanged between the server and client over a side channel, there is No Shared Secret to compromise.
• Piggy backs on the global, and freely available Bitcoin protocol infrastructure, no central PKI is required.
• Decoupled from Bitcoin addresses, allowing for a more explicit separation from financial transactions and allowing for greater privacy, also allows support for algorithm agile solutions
• Support for persistent, and ephemeral SIN's to manage compromise
• Identity becomes portable the same identity can be used on multiple services, letting you take your identity with you.

It's time, for Individuals to take control over their digital Identity and how or when their data is used and stored.

What if I need to prove my identity?
Within a community, there are situation where is is required provide an assurance of "identity", a simple fact of living in a community.
The SIN framework has been designed to allow an opt in to a "set of signed attributes" on a per SIN basis and still under the total control of the individual.

Why should Corporations and Governments world wide, care about personal data?
BCG estimates that two-thirds of the potential digital identity value – or about €440 billion in 2020
alone – is at risk if stakeholders fail to protect personal data.
Nor is it digital identity value alone, the additional revenues or efficiency gains derived from personal data applications are at risk: Mishaps in handling consumers‘ data can go much further, causing damage to an organisation‘s brand, its client relationships and its reputation. Privacy is increasingly becoming an area of competitive differentiation.

Usage today

All Subscribers to VillageMall have a hardware generated and secured ECDSA key, and type 1 SIN incorporated, for free, with their subscription.
The worlds first Global Digital Identity Service with SIN attributes is now operational, and publicly available (see DNS domain blockchainledger.net)

The first usage is to secure our Cognition API, including BYOD management system, used to manage lost, stolen or compromised Mobile Devices and access to Cognition Suite of Services.  

See Free hardware backed ECDSA Keys and SIN

References:
1. Data from fraud prevention service Cifas shows ​​34,151 confirmed instances of identity fraud were recorded in the first quarter of ​2015​.
2. Prevent identity theft 
3. Number of identity theft victims 'rises by a third'

Disclaimer The contents of this site should not be understood to be accounting, taxation or investment advice but rather as general product related educational information that may or may not meet your specific requirements.