Skip to main content

From a secrecy model of information security to a usage authentication model

We continue to be plagued by data breaches, password and credit card dumps, healthcare records...etc.

One of the reasons many of these breaches continue to be devastating and effective
for cyber criminals is because our current information use infrastructure/architecture
relies on secrecy as the primary mode for preventing the misuse of information.

Secrecy simply means only the people who have the right to use a bit of information have access to it, when that assumption breaks down as it does with data breaches, the related information can lose some or all its value. For instance a compromised credit/debit card number means getting a new number. A compromised password database means changing the passwords...etc

Secrecy has its use as a privacy preserving mechanism but is fairly flawed as an information usage
authentication mechanism.

The idea of secrecy as the mechanism for controlling the use of information is deeply ingrained, so
much so that even people who should know better often have a reflexive reaction if you propose solution ideas that seem to not consider the secrecy of information. 

With the Certisfy service, when I tell people that a social security number is the best sort of
IRL identity anchor, the initial reaction is often incredulity because they assume my solution proposal is relying on the supposedly secrecy of social security numbers. Of course it doesn't, social security numbers as excellent as IRL identity anchors because they are unique to a person & immutable, their secrecy is irrelevant in this context.

The solution is information usage authentication at time of use, meaning proving you have the
right to use a certain bit of information at the moment you need to use. Cryptographic certificates
provide one mechanism for implementing such approaches. 

If you need to generate a cryptographic signature for a bit of information before you can use it, then it doesn't matter whether the information is in your secret vault in Iron Mountain or printed on a time square billboard, the information's user's authority is no longer based on it being secret but rather based on near real-time proof of the right to use that information.

If you get a certificate for your social security number to anchor your online identity to IRL identity for instance, it doesn't matter that the number is widely used (and misused), what matters is that before you got the certificate someone did verification to confirm it belongs to you and that no one else would be able to get a certificate for that number.

If you have a certificate for your credit/debit card, the number is just a unique identifier and
secrecy for that number might matter for privacy but no longer relevant to prevent unauthorized use.

For passwords we're slowly moving in that direction with solutions like passkey. With a cryptographic signature as the actual authentication token, the password becomes just a pass-phrase and could be
the legendary "123" without having any impact on security. 

In fact pass word/phrase becomes unnecessary with cryptographic signatures, your login client (browsers,apps...etc) can just generate a random string and sign it then forward it to the target without user involvement. If the database holding user id is compromised, the compromised system gets fixed but otherwise nothing changes in terms of the security of said information. 

Of course user device compromise would necessitate replacing keys but a user's device is such a small attack surface compared to a company's database that on net this is a non-issue.

Comments

Popular posts from this blog

Trusted URLs Via Cryptographic Signatures

With Certisfy sticker functionality, ie the ability to publish cryptographic signatures as claims, users can share trusted URLs by leveraging the verification tied to trustworthy claims. URLs can be included in trustworthy claims and posted for anything for which a user wants to project trust. They can also be restricted to sources(ie referrer) so that the link can't be fraudulently reposted elsewhere. When you include links in a claim that you want to associate trust with, users will first be able to verify the link provider via the claim and then decide whether the link and associated information is trustworthy. In an AI saturated online space, there is significant value in a link/url being able to provide a strong signal of authenticity or trust. A trusted creator or a journalist can post links tied to a Certisfy verification as a means to project trust and expand reach. With verification links backed by high quality trust projection, we can have in essence a verified web. Here...

Using .gov Email Addresses For Age And Information Verification

Over the years we've experimented with ideas that leverage what can be thought of as civic trust infrastructure to address trust related problems on the Internet.  Previously we created a browser extension and proxy service that allowed users to use access to their IRS  Get Transcript ONLINE  access as a way to procure trustworthy cryptographic ID certificates.  Essentially treating access to the Get Transcript ONLINE service as automatic ID verification and using that to issue (via a web proxy) ID certificates.  We also developed the trust relay protocol , a similar approach that leverages existing sources of trust as a means to address internet trust challenges. These experiments ultimately lead to the development of the Certisfy app and service. We have launched another significant experimental approach, leveraging .gov email addresses as a mechanism for bootstrapping a cryptographic trust chain . Think of this as a sort of  web of trust implementa...

Using Keybase and PGP To Build Certificate Trust Chains

We are expanding our previous experiment to include people who posses PGP keys hosted at certain domains. For now we are whitelisting Keybase.io, meaning if you have a Keybase PGP key it can be used to procure a trust anchor certificate via the Certisfy app. It should be noted that this is strictly experimental, meaning most certificates will likely at some point be suspended or out right revoked if it seems they are being used to issue untrustworthy certificates.  The allowance of Keybase is not ideal since there is no id proofing and there is no reason to assume the person behind the Keybase key is a suitable trust anchor. It is however something used by folks interested in cryptographic solutions related to internet trust and security, so at least for experimentation it is appropriate. To validate a certificate request with your Keybase PGP key, first use your Keybase key to sign the following text (no trailing or leading spaces): Using public key hosted at ${PGPPubkeyURL} , ...