What Happens if I Sign a Document Digitally? Where Does My Signature Go? - Server Signing Infrastructure Made Easy

What Happens if I Sign a Document Digitally? Where Does My Signature Go? - Server Signing Infrastructure Made Easy
Credit: Shubham Dhage

You’ve probably signed a document on your laptop before.

The world is changing fast and all of a sudden you find yourself signing a confidential document on your phone?!

The other day I even had to sign my Job Offer digitally.

How do they even know it's me?

How can sign something and within minutes the whole process is over?

What’s the infrastructure behind it?

All these questions will be answered in the next few lines.

The goal here is to explain it as easy and uncomplicated so that even the biggest imposter can get it.

Keep in mind, since it is a technical approach, I will mention acronyms but I try to minimize them as much as I can.

Don’t worry, you’ll get it.

Easy Thought Experiment

So I’m sitting in an office, and all of a sudden my boss calls me and tells me to send him a document with my signature on it. He needs it, so I can be part of a Client Deal.

Easy. I open the Preview application on my Mac and paste my signature in there.

I sent it to him. Done.

….

2 Minutes later he sends it back to me and asks if I’m kidding.

What's going on?

After an unnecessary 5-minute rant, he explains to me why this is not how it works. So I open up my laptop and try a more professional approach.

Apparently, I need to use a server signing application. Don’t know what that is but I guess I’ll find out.

He’s still on the phone, telling me what to do.

So first, I need to download a server signing app from any of the well-known vendors out there:

  • Adobe sign
  • Docu sign
  • Hello sign

Probably, anything with a sign in the back….

So that’s what I did, what now?

If I tell you, within 1 minute everything was done (after registration of course).

Here are the steps:

1. Click on “sign document” button

2. Upload the document I want to sign

3. Enter my signature and put it on the document

4. Send

5. It has MFA, so I need to pull out my phone and verify my identity

6. BOOM, done

So what's going on here??

How was this different from me manually pasting my signature on the Preview app on my MacBook?

Let’s check it out.

What Is the Difference Between My Approach and his?

The difference is, that with using the appropriate application, there is a whole different infrastructure behind it.

In this case, it's called Server Signing Infrastructure.

It is a system, specialized in providing security and authenticity to digital signatures.

The problem with signing my contract on Preview is that first off, it is less secure.

Why?

  • Lack of authentication
  • Lack of non-repudiation, meaning the recipient cannot prove that it's from you
  • The recipient could easily modify the document

Secondly, it's not legally binding, meaning it doesn’t comply with the necessary regulatory standards. There are specific standards in the industry, depending on where you live, that define clear rules on how to make it legally binding.

Anyone could paste your signature on an image file and send it out. It's just an image of your signature, nothing that proves it’s from you.

But, if you use a trusted digital signing service, as the ones mentioned above, the approach is different.

The Infrastructure of Server Signing Applications

If it gets too overwhelming at times, take a break, revise, and then keep going.

Take a look at this picture, it represents the Server Signing Infrastructure.

Source: https://bit.ly/3YTSEk0

I will explain to you how this works, based on the example I gave you earlier.

I sign the document in an unprotected environment.

What Is an Unprotected Environment?

So when I pull out my phone, there is a likelihood of any of the following being vulnerable:

  • Your network

If the network your phone/laptop is running on (maybe your home network) isn’t fully secured, a hacker could intercept the traffic.

  • Operating system

Not your phone’s or laptop’s OS, but the Operating system of the application. If your server signing app is built on an older version of a Windows Server, that’s not getting any updates, it’s vulnerable.

  • The application itself

If it's not properly programmed, contains bugs or general security weaknesses.

This is an unprotected environment.

So What Going on in there?

I open up the App and upload my document.

The interface in which I’m uploading my document is called SIC — Signer Interaction Component.

This component serves as a link between the signer, You, and the rest of the Signature process.

Easier said, the SIC is the thing that tells you what to do when uploading your document.

“Click this button”

“Drag your signature to the field”

“Click on send”

You know what I mean? It’s the interface you interact with.

You enter your password, you sign the document and then you review it again, etc.

That’s why these arrows are there:

This all happens locally, on your device.

When does it communicate with the rest of the infrastructure?

Right after you authenticated via MFA.

But Where Does All the Magic happen?

The process:

Start App → Upload document → Sign document → Authenticate via MFA → SEND (now we’re here)

Now we communicate the signed document with the SAD and SAP.

SAD — Signature Activation Data

SAP — Signature Activation Protocol

The SAD has all the information that is required to create a valid signature.

The SIC (Signer Interaction Component) uses the SAD’s parameters, to customize your signature in a way that is aligned with security and legal guidelines.

After applying the SAD requirements to your signature, the activation data is ready to interact with the SAP to activate your signature creation process.

The Signature Activation protocol (SAP), takes the activation data (SAD) from the SIC and forwards it to the SSA — Server Signing application.

More acronyms in one sentence than I wanted to.

But again, the SAP brings everything into motion, since it takes the SAD to the next station, the Server Signing Application (SSA).

Now we are in the TSP — Trusted Service Provider protected environment.

Feel free to take a break here and revise what we’ve been going through, so you know exactly what going on.

The TSP Protected Environment

So, this zone is not in your control anymore.

It's a trusted provider that implemented security measures to ensure that all the services, like the digital signature creation services you’re using, are safe.

It has physical and logical access control:

  • Physical: A service provider company has its servers physically stored somewhere.

That would be the protected environment and they would have to secure it in a way.

  • Logical: The network includes Firewalls, Encryption, Intrusion detection system (IDS), etc.

Back to the SSA.

As you can see, the SAD goes straight through SSA.

But what does it do?

It’s responsible for the coordination of the signature process. When receiving the activation data, it does the following:

  • Ensures that activation data is valid and not modified
  • Verifies your identity, through an authentication method provided by the signing application

This is what happens in the SSA.

What now?

So SSA sends the data to the Signature Activation Module (SAM)

The activation module securely transfers the data to the Cryptographic Module, and keep in mind, in every step the authenticity of the SAD, your data, is verified.

A Cryptographic Module is also called SCDev — Signature Creation Device

This is what the device can look like:

Source: https://www.trustpro.eu/go-green/

When the data has arrived at the last station, the Signature Activation Device finally generates the signature.

It is a cryptographic device that is the only one that stores the private key. Since it has the private key, it can therefore generate the signature.

Look one last time at the graphic.

The arrow pointing from the SAM to the Crypto Module (SCDev), says hash.

This is because the hash is created in the SAM and sent to the SCDev.

The hash is unique to the original data, so in case of a modification, we know that it’s not the right version anymore.

Also, you see that the SAM and SCDev are in a tamper protected environment.

Both are hardware devices that are dependent on each other.

SAM gives access to SCDev and SCDev stores the private key.

What Is a Tamper Protected Environment?

It’s a zone that has additional security features implemented, logically and physically.

So when you enter a data center, you are in a trusted provider environment. But when you want to access the SAM or SCDev, they are in another cage, that is locked. This is the extra layer of security (tamper protected environment)

It would look like that.

Source: https://rackandshelf.com/product/safety-products/wire-mesh-partitions/wire-server-cages/

This is the same for the logical aspect, you have an extra layer of protection, through IDS, access control, and encryption.

This layer of protection lies in a zone that is separated from the rest.

So basically, the TSP zone is a secured network that manages the signing infrastructure, but the tamper protected zone only protects the SCDev and SAM from attacks, since they are extremely sensitive.

Lastly

The SCDev sends the signature back to the SIC and that’s it.

Almost.

The application that sent out the signature checks if the signature is still original. It verifies if someone modified the signature, with the public key.

How? Well with a hash value.

As you know the message is decrypted with the public key that corresponds to the private key in the SCDev.

This message is then compared to the hash value of the original message.

If they are the same, the whole process has been completed.

Conclusion

Now I can use my signature for my Client Deal.

All of this happened within seconds, crazy right?

We covered the whole process of the Server Signing Infrastructure and how you properly sign your next documents.

I hope that this gave you some insight and a better understanding of digital signatures.