The private key is the secret that turns your invoice from an ordinary file into a signed, tamper-proof document. In Saudi Arabia’s e-invoicing system, every Phase Two invoice carries a cryptographic stamp. That stamp can only be produced by a single private key that your system knows and no one else does. Whoever holds the private key can sign in your name, and whoever loses it loses the ability to issue accepted invoices.
This article is aimed at the developers and technical teams who build or integrate an invoicing system compliant with the Zakat, Tax and Customs Authority (ZATCA). Here we focus on the private key alone: its role in signing, why it must remain an absolute secret, how you protect it, and what happens if it leaks. The public key and its role in verification have a separate article, and the digital signature mechanism in full detail has its own technical reference. We only point to them here when needed.
What the private key is and why it matters in e-invoicing
The private key (Private Key) is one half of an asymmetric key pair (Asymmetric Key Pair). The other half is the public key (Public Key). The two are generated together in a single moment and are mathematically linked, so that what the private key signs can only be verified by its matching public key, and the reverse is not possible.
The essential difference is simple: the public key is distributed to everyone, while the private key stays with its owner only. This split is the foundation of the digital signature. When your system signs an invoice with the private key, any party holding the public key can confirm that the invoice was issued by your system specifically, and that it has not changed after signing.
In e-invoicing, the Authority uses Elliptic Curve Cryptography. The private key in this case is a large random integer on a curve secp256k1. Its relatively small size compared to RSA keys does not reduce its strength: a 256-bit elliptic key is roughly as strong as a 3072-bit RSA key, with faster signing and a smaller size that suits the Quick Response (QR) code on the invoice.
Why does this matter to you as a developer? Because the validity of every invoice you issue depends on a sound signature. A sound signature needs a sound, well-protected private key. Any flaw in generating, storing, or using the key is reflected directly in whether your invoices are accepted by the Authority.
Why an elliptic curve and not RSA
The choice of elliptic curve cryptography in e-invoicing is not arbitrary. The simplified invoice carries its signature inside the Quick Response code, and the space in that code is limited. An ECDSA signature on a 256-bit curve is about 64 bytes only, while an RSA signature of equivalent strength is about 384 bytes. The difference is huge when you are trying to fit the signature and the certificate into a code that the buyer’s phone reads in a second.
In addition to size, the signing operation itself is faster on the elliptic curve at high security levels. A system that issues thousands of invoices a day benefits from every fraction of a second saved by the lighter signature. This balance between strength, size, and speed is what drove modern standards, including the Authority’s specification, to adopt the elliptic curve.
| Metric | ECC secp256k1 | RSA equivalent |
|---|---|---|
| Key length | 256 bit | about 3072 bit |
| Signature size | about 64 bytes | about 384 bytes |
| Signing speed | Faster | Slower |
| Suitability for the QR code | Excellent | Poor |
The life cycle of the private key in the system
Generation on the secp256k1 curve
Requesting a CSID certificate (sending the public key only)
Signing inside the secure store
Revocation and rotation upon suspicion
The private key and the Cryptographic Stamp Identifier (CSID)
The private key does not work in isolation from the Authority. When you connect your system to a Fatoora platform, your device generates the key pair locally, then sends a Certificate Signing Request that contains the public key only. The Authority responds with a digital certificate known as the Cryptographic Stamp Identifier (CSID).
Note the important detail here: the private key does not leave your system at any step. What is sent to the Authority is the public key inside the certificate request. The Authority signs your identity and your public key, producing a CSID certificate that ties your name and tax registration to your key. For the details of this certificate and how to obtain it, see the article CSID Certificate: the Cryptographic Stamp Identifier.
The system deals with two types of certificate. The first is the Compliance CSID, used in the testing environment during the onboarding phase. The second is the Production CSID, used to sign actual invoices. Each certificate has its own associated private key, and you must not mix them up.
| Element | Private key | Public key |
|---|---|---|
| Who owns it | Your system alone | Everyone, via the CSID certificate |
| Its function | Producing the signature (the stamp) | Verifying the signature |
| Is it sent to the Authority? | No, never | Yes, inside the certificate request |
| Impact of leaking it | Catastrophic: impersonating your identity | No harm: designed to be distributed |
This table sums up the golden rule: protecting the whole of e-invoicing comes down to protecting the private key. Everything else is designed to be public.
Where the private key sits in the integration path
It helps a developer to draw the full integration path to see where the private key sits within it. The path starts with generating the key pair on your device, then building the Certificate Signing Request that contains your tax data and your public key. You send the request to the Authority through the Fatoora platform interfaces, which verifies your data and responds with the Compliance certificate first.
After passing the compliance checks on a sample of invoices, you request the Production certificate. Throughout all these stages the private key stays fixed in its place and does not move. What travels across the network is the public key, the certificates, and the signed invoices, not the private key itself. Grasping this path spares you a common mistake: thinking that integration requires uploading the private key to an external party. That never happens in a sound design.
Separating the testing and production environments here is not an administrative detail. A testing-environment key must never sign a real production invoice, and a production key must never be used in development experiments. Mixing the two environments is a recurring cause of rejected invoices, and of leaking production keys through exposed test logs.
How the private key signs the invoice step by step
The private key’s core role is to produce the invoice’s cryptographic stamp. The key does not sign the entire invoice with its long text; instead it signs a condensed fingerprint of it known as the hash value (Hash). The fingerprint is computed with the SHA-256 algorithm, which turns any input, however long, into a fixed-length value. For details, see the article The SHA-256 algorithm in the e-invoice.
The signing operation proceeds as follows:
- Your system generates the invoice representation in XML format according to the UBL 2.1 standard.
- It computes the SHA-256 fingerprint of the parts specified in the Authority’s specification.
- It signs the fingerprint with the private key using the ECDSA algorithm on the secp256k1 curve.
- It embeds the resulting signature inside the invoice, and includes the public key and the certificate in the Quick Response code.
The final output is the cryptographic stamp that proves two things at once: that the invoice was issued by your system, the owner of the private key, and that its content has not changed after signing. The full signing mechanism with its technical details can be found in the digital signature technical reference, and the article The digital signature in the e-invoice.
Practical example: generating the key and signing with OpenSSL
The following command generates a private key on the secp256k1 curve, which is the curve required in e-invoicing:
To extract the matching public key from the private key (only the public key is what gets sent in the certificate request):
When you inspect the contents of the private key file, you will notice that it begins with a clear header indicating its type:
This file is the absolute secret. Anyone who gets hold of these lines can sign invoices in your name. Note that it is textual and easily copied, which is why keeping it in an ordinary file on the server is not enough.
An example of producing the signature programmatically
The following snippet in JavaScript illustrates the principle: computing the fingerprint then signing it with the private key. This is for conceptual illustration, and the actual implementation adheres to the details of the Authority’s specification.
The principle that must take root: the private key enters the signing operation inside your environment only. It is not sent over the network, not recorded in log files (Logs), and does not appear in any API response.
Randomness: the cornerstone of key generation
The strength of the private key begins at the moment it is generated. The private key is in essence a large random number, and the more genuine its randomness, the more practically impossible it becomes to guess. Here lies a hidden risk that developers often overlook: a weak source of randomness produces predictable keys.
If your system relies on a weak random number generator, or on a fixed seed (Seed) during testing that was then moved into production by mistake, you may produce two identical keys on two different machines, or a key whose range an attacker can guess. The rule: always use a cryptographically secure random number generator (CSPRNG) provided by the operating system or the hardware security module.
Standard libraries such as OpenSSL rely on the operating system’s randomness source by default, and this is sound in a correct production environment. The risk appears in freshly booted virtual environments or lightweight containers that may lack sufficient randomness in their first moments. Make sure the key generation environment has a mature randomness source before you generate a key with which you will sign your real invoices.
An anatomy of the signing operation from the inside
To understand why no one can forge the signature without the private key, it helps to look at what happens inside the ECDSA algorithm. When signing, the algorithm takes three inputs: the invoice fingerprint, the private key, and a temporary random value known as the nonce (Nonce). These inputs produce a pair of numbers that represents the signature.
The nonce deserves special attention. It must be unique and random in every signing operation. Reusing the same nonce to sign two different messages with the same key is a well-known vulnerability that allows the private key to be computed mathematically from just two signatures. This is why you leave nonce generation to the trusted cryptographic library, and never write it yourself.
This explains the practical principle: do not build cryptography from scratch. Use mature, audited libraries, and let them handle the fine details in which a small mistake is enough to collapse the security of your key entirely. In a serious production system, the platform or the security module handles these details, so the development team never touches these sensitive parts directly.
Why the private key must remain an absolute secret
The entire e-invoicing system rests on a single assumption: that the private key is known to its owner only. If this assumption falls, trust in every invoice that key signed collapses.
The private key proves identity. When the Authority or the buyer verifies an invoice’s signature with the public key, a positive result means one sentence: this invoice was signed by whoever holds the matching private key. The system does not know a person; it knows a key. That is why whoever controls the key controls your digital identity in the system.
This is a property called non-repudiation (Non-repudiation). Since you alone hold the private key, you cannot disown an invoice your key signed. This property benefits you and your counterparty, but it turns completely against you if the key leaks: invoices you did not issue will be attributed to you.
The difference between secrecy and openness in the system
| Metric | Private key | Public key |
|---|---|---|
| Distribution | Confined to the system | Published safely |
| Function | Signing | Verification |
| Impact of a leak | Catastrophic (signature impersonation) | No impact |
How to protect the private key: firm principles
Protecting the private key is not a single step, but a set of principles applied at every stage of its life cycle. Here are the foundations on which any serious invoicing system is built.
1. Do not store the key as plaintext
Keeping the private key in an ordinary file on the server or inside a database in text form is the most common and most dangerous mistake. Any vulnerability that exposes the file system exposes the key. The minimum is encrypted storage, and best is that the key never touches the disk at all in its raw form.
2. Use a specialized secure store
Sensitive private keys are kept in Hardware Security Modules (Hardware Security Module) or in dedicated cloud key management services. These modules are designed so that a signing request goes in and the signature comes out, without the key itself ever leaving the module. This achieves the most important principle: the key does not leave its secure boundaries.
3. Apply the principle of least privilege
Not every component in your system needs access to the private key. Make signing a separate service with limited privileges that receives the fingerprint and returns the signature, and do not grant the rest of the application any direct access to the key. The fewer the components that touch the key, the smaller the attack surface.
4. Do not leak the key in logs or code
Among the most painful leaks is writing the key into a diagnostic log file, or embedding it directly in the source code and then pushing it to a public repository. Review your code: no private key in the code, no key in environment variables printed to the logs, no key in error messages.
5. Encrypt the key in transit and at rest
If you are forced to move the key or back it up, make it encrypted with a strong password or with a separate encryption key kept elsewhere. An unencrypted backup of the private key is a risk as large as the key itself.
| Practice | ❌ Avoid it | ✅ Do it |
|---|---|---|
| Storage | A text file on the server | A specialized secure store or HSM |
| Access | The whole application accesses the key | A signing service with limited privileges |
| Logs | Printing the key for diagnostics | Preventing any logging of the key |
| Code | The key embedded in the code | The key entirely outside the code |
| Transit | A raw copy over the network | Encrypted with a separate key |
What happens if the private key leaks
Leaking the private key is the worst scenario in a signing system. Imagine a malicious party obtained a copy of your private key. What can they do?
- Sign fake invoices that appear to be issued from your system perfectly soundly.
- Impersonate your identity before the Authority and buyers without cryptographic verification exposing them.
- Create a chain of invoices attributed to you, so you bear their tax and legal consequences.
More dangerously, cryptographic verification itself will not detect the forgery. The stolen private key produces a mathematically valid signature that matches the public key published in your certificate. That is why there is no technical solution to detect a leak after it occurs, and prevention alone is the protection.
Immediate response steps upon suspecting a leak
If you suspect your private key has leaked, treat the matter as an urgent security incident:
- Stop using the key immediately in any new signing operation.
- Review the certificate revocation and CSID re-issuance procedures with the Authority.
- Generate a new key pair in your secure environment, and request a new certificate.
- Audit the invoices issued during the suspect period for any unauthorized activity.
- Review how the attacker reached the key, and close the vulnerability before installing the new key.
Key rotation (Key Rotation) is not an emergency measure only. It is wise to rotate keys periodically as part of a preventive security policy, so as to shorten the time window in which any key is valid for use.
Why cryptographic verification is not enough to detect forgery
A developer might ask: can’t the Authority distinguish an invoice signed by an attacker from one signed by the original key owner? The answer is no, as long as the key is the same. The digital signature proves that whoever signed holds the private key, nothing more. The signature carries no information about the identity of the person sitting behind the device, only about the key used.
This is an essential point in understanding the threat model. The system’s security does not rest on the intelligence of verification, but on the assumption that the private key has not left its owner’s control. The moment this assumption falls, cryptographic verification becomes powerless, because it is designed to trust every mathematically valid signature. That is why the whole battle moves to the stage of protection and prevention, not after-the-fact detection.
The lesson for the developer: invest your effort in preventing the key from reaching any unauthorized party, because after a leak there is no technical solution that restores trust other than revoking and rotating the key. Do not rely on someone in the verification chain catching the forgery, for the system is designed to trust your key.
Risk matrix: who has access and when
| State | Action |
|---|---|
| Sound | Continue issuing with confidence |
| Suspected leak | Stop issuing and notify the Authority |
| Exposed | Revoke the certificate and issue a new key |
How Qoyod protects your private key
When you use Qoyod’s e-invoicing system,the platform handles the private key and its life cycle on your behalf, so you do not need to build the cryptography layer yourself.
Here is what Qoyod offers in this regard:
- Generating the key pair and managing the CSID certificate automatically when you connect your establishment to the Fatoora platform.
- Signing every invoice with the cryptographic stamp required in Phase Two, without any manual intervention from you.
- Full compliance with the requirements of the Zakat, Tax and Customs Authority in issuance and integration.
- Instant issuance of tax invoices (B2B) and simplified invoices (B2C) with the Quick Response code.
- Continuous technical support around the clock, all week, to help you with the integration steps.
This means you focus on your business, while the platform takes care of the complex cryptographic side we covered in this article. You issue the invoice, and Qoyod handles signing it, storing its key, and linking it with the Authority.
The private key and the public key: each has its role
Completing the picture requires understanding the other side. The private key signs, and the public key verifies. They are two faces of a single operation, but their roles do not overlap. The private key produces the stamp in a secret environment, and the public key inspects the stamp in a public environment.
In this article we focused on the signing and secrecy side, because it is the side you are responsible for protecting. As for the verification side and how the recipient reads the public key and uses it to confirm the invoice’s integrity, that is the subject of the separate public key article. As for the fine details of the digital signature mechanism and the fields it covers, you will find them in the digital signature technical reference.
The rule that sums it all up: treat the public key as if it were announced to the world, and treat the private key as if it were the most precious secret in your system. The first is designed to spread, and the second never leaves its secure boundaries.
Let Qoyod handle your cryptographic keys
Do not build the cryptography layer yourself. Qoyod generates your keys, signs your invoices, and links them with the Authority automatically, so you issue invoices compliant with Phase Two in a single click.
Frequently asked questions
What is the difference between the private key and the public key?
The private key signs the invoice and produces the stamp, and remains a secret with your system. The public key verifies the signature, and is distributed to everyone inside the CSID certificate. What the private key signs can only be verified by its matching public key.
Is the private key sent to the Authority?
No. When requesting the certificate, only the public key is sent inside the Certificate Signing Request. The private key does not leave your system at any step, and this is the foundation of the system’s security.
What happens if the private key leaks?
Whoever holds it can sign invoices in your name without cryptographic verification exposing them. The urgent action: stop the key, revoke the certificate, generate a new pair, and request a new CSID certificate, while auditing the invoices issued during the suspect period.
Which curve is used to generate the key in e-invoicing?
The system adopts the elliptic curve cryptography curve secp256k1 with a length of 256 bit. It provides high strength with a fast signature and a small size that suits the Quick Response code on the invoice.
How do I store the private key securely?
Keep it in a specialized secure store or a hardware security module, not in a text file. Apply the principle of least privilege, prevent it from being recorded in logs or embedded in the code, and encrypt it in transit and at rest.
Do I need to manage the private key myself with Qoyod?
No. Qoyod handles key generation, CSID certificate management, and signing every invoice automatically. You issue the invoice, and the platform takes care of the cryptographic side and the integration with the Authority.
