IAM’s Time Problem: Why Digital Attestation Needs Work

Identity management has a time problem. Discussions in the hallways and conference calls for various identity and security standards focus on immediate, point-in-time requirements. Can this person or thing authenticate itself at the moment they need to? Are they authorized at that moment to access the system, service, or data they need to get their job done? Don’t get me wrong; those are big, important questions that need to be addressed. But sometimes, you need more. You need to dig into the past to determine responsibility for specific actions or the provenance of digital material. This area is called attestation and verification and is at least as complicated as proper authentication and authorization, especially when considered over longer time frames.

Understanding Modern Digital Attestation

Modern digital attestation is the process of proving or verifying the authenticity and integrity of a system, device, or data, often through the use of cryptographic techniques. Has the data been tampered with? Can it be trusted to be what it is supposed to be? Or have conditions changed such that you cannot immediately trust what you have?

The process of attestation has, of course, been around longer than computers. If you’ve used a notary service, you’ve encountered a non-digital attestation process. The notary verifies the identity of the person via official identity documents (such as a passport or driver’s license). They then witness the signature and provide a stamp that attests the signature is genuine, and the person has been identified, and then they record the whole transaction in a ledger.

In principle, digital attestation is much the same: an identity is verified, a credential is issued (or an existing one is used), signed, and an entry is made in an electronic ledger. In practice, however, the requirements around identity verification change based on context. Different industries, jurisdictions, and services all have different rules. (Discussing identity verification is a different blog post.) The signature attesting to the verification is where cryptographic magic comes in, and that’s where time becomes a challenge.

The Role of Electronic Ledgers in Attestation Over Time

Some people see “ledger” in the world of online data and think “blockchain.” That’s certainly one way to go about handling a ledger. Advocates argue that blockchain technologies are the One True Way to properly handle attestation over time. Everything is recorded, nothing can be deleted or changed, and everything is transparent to the entities that can access that blockchain. Of course, there are issues—such as the GDPR’s ‘Right to be Forgotten‘ that states certain data must be deleted when requested—that make using blockchain technology a bit more complicated than anyone would want (great paper about that here).

All that said, ledgers do not need to exist in any particular blockchain format. In fact, for the purposes of this discussion, the format of the ledger (beyond it being digital instead of a dusty book somewhere) doesn’t matter. What matters is that signature and the associated attestation that’s being stored.

Cryptography’s Critical Role in Digital Attestation

You can’t talk about cryptographic signatures without understanding a few salient points about cryptography. Cryptography is used to enhance the security, scalability, and manageability of systems and data, from individual devices to large-scale distributed systems. Cryptography relies on keys that encrypt data. Symmetric cryptography allows the key that encrypts the data to also decrypt the data. Asymmetric cryptography requires one key for encryption and a different key for decryption. The amount of math involved in making all this work is staggering and entirely out of my pay grade. Fortunately, there are people in the world who think developing the math for advanced cryptographic systems is amazing. Thank you for your service.

You don’t have to know the math to use the systems (whew!). But you do have to give some thought to how to manage the keys used for encryption and decryption. Securely generating, using, storing, and revoking keys is a Very Big Deal and enough to keep any IT administrator or security practitioner on their toes. While there are several models to follow, including Public Key Infrastructure (PKI), the Key Management Interoperability Protocol (KMIP), Hardware Security Modules (HSMs), and several others, when you think about those being used over the course of decades, you’ll start to see some critical weaknesses in the system.

Today’s Attestation, Tomorrow’s Cipher

As people create digital attestation and verification specifications, they focus on the technologies available today. They also presume those technologies will be available tomorrow. And they’re right. Technologies will be available tomorrow. They will probably be available next year. Ten years from now, though? Twenty? One hundred?

Now for a different consideration: if you use a model that has one key signing all the things for a few years, how hard will it be to dig through the data to find any particular signing instance? How do you identify the point in time a key might have been compromised (i.e., copied and used by an unauthorized party) and then determine all the things signed with the compromised key? Now think about this exercise for data that’s a decade old.

This isn’t a scenario that will play out with everything that includes digital attestations today. Business records are often only legally required for 5-7 years. Similarly, personal tax records also only must be stored for a limited time. But there are scenarios where the time frames required are much, much longer. In the U.S., copyright protection lasts for the lifetime of the author plus 70 years. Establishing provenance for artwork is something that can span centuries.

Standards Matter

There are efforts that are starting to poke at the edges of the problem of digital attestation and verification. One example is the Coalition for Content Provenance and Authenticity (C2PA). That’s an effort coming out of the Joint Development Foundation, a non-profit that brings together the efforts of the Content Authenticity Initiative (CAI) and Project Origin. They are focusing on the provenance of media for publishers, creators, and consumers. Another effort, coming from a different angle, is the Supply Chain Integrity, Transparency and Trust (SCITT) initiative in the IETF. Their focus is on “the ongoing verification of goods and services where the authenticity of entities, evidence, policy, and artifacts can be assured and the actions of entities can be guaranteed to be authorized, non-repudiable, immutable, and auditable.”

But in both those cases, the focus is a bit more on today and less on decades from now. This is understandable when you think about it. If you can’t solve for today, then you might not even get to next year, so focusing on immediate needs is a necessary step. Of course, that doesn’t mean you can ignore the longer term and given the state of existing efforts, the longer term is a space ready for attention.

Exploring Solutions: Hierarchical Deterministic Keys for Scalable Attestation

OK, so no, I don’t have answers, but I was definitely inspired to learn more on this topic during IETF 120. I had the best hallway conversation about the issues of time, key management, and how identity practitioners really needed to think harder about the long-term viability of the specifications under development. People were developing specifications and protocols that allowed for secure digital attestations (yay). They weren’t (aren’t) thinking about the fact that, over time, a significant percentage of the signatures will be revoked, and that has to go in the ledger as well. Long story short: ledges won’t be scalable over any length of time.

The solution to this we discussed most was Hierarchical Deterministic Keys. HDKs can be used in attestation processes to create derived keys for specific operations or time frames. This allows the system to maintain a secure and scalable method of attestation by ensuring that each key is only valid for a particular purpose or time, minimizing the risk of compromise and reducing the need for frequent key revocation. Basically, every time you wield a key, you create a derived key so you can more easily identify when that key was used. Revocation becomes less of an issue when the scope of key use is constrained. Of course, if your master key is compromised, you’re kind of doomed, but that’s the case in any key management scenario.

A Use Case: Refugees

If you’ve read this far, you probably think this is an interesting problem, but you might want a realistic example. So let’s talk about Maria.

It’s the year 2045. Maria fled her home country 20 years ago due to a conflict. She arrived in a host country, where she was granted asylum and eventually settled. It’s become home, and now she wishes to apply for citizenship. As part of the application process, she needs to prove her identity and submit a birth certificate from her country of origin.

Maria’s original birth certificate was lost during her escape, but she had a digital copy of the document stored in a digital identity wallet issued by an international organization that assists refugees. This digital birth certificate was issued with a cryptographic signature attesting to its authenticity at the time of issuance. Digital credentials ftw!

But wait. That was 20 years ago. While they used the best cryptographic techniques at the time, the quantum apocalypse happened. The agency that issued Maria’s birth certificate has had to revoke many keys used for signing documents, either due to suspected compromise or the routine expiration of cryptographic keys. Each revocation must be recorded in a ledger, which has grown significantly over time. The host country has to search through the records for millions of refugees using old credentials; not exactly a trivial exercise.

But wait, there’s more!

The digital birth certificate’s provenance must be established across multiple jurisdictions, as Maria’s host country requires confirmation from the original issuing country (which has undergone significant political and administrative changes over the years). This requires coordination between different governments, each with their own systems and cryptographic practices. 

According to the United Nations High Commissioner for Refugees (UNHCR), “By May 2024, more than 120 million people were forcibly displaced worldwide as a result of persecution, conflict, violence or human rights violations. This includes: 43.4 million refugees. 63.3 million internally displaced people.” There are many Marias in the world today, and there will only be more in the coming years.

The Data Deluge: Preparing for the Future of Digital Attestation

According to Exploding Topics, 402.74 million terabytes of data are created daily. Not all of it will be kept. Not all of it will involve digital attestations as to its authenticity. But if even 1% of that data does require digital attestations that last for at least a decade, you’re looking at 14,700.01 exabytes of data in 10 years. That’s … a lot of data.

As we’re developing specifications that allow us to do very smart things to attest to today’s data authenticity, we really need to start thinking about what that means after 10 years of new data, new signatures, data revocation, and more.

As always, I’m hoping this post will be the start of a conversation. If you have more information on the scalability of long-term attestation, please let me know!