Native X.509, RSA and HSM Support

Today, almost all computer security relies on asymmetric cryptography and X.509 certificates as file or hardware modules.
And the RSA algorithm is still used to sign the vast majority of those certificates. Even if there are better options (like ECC-256), RSA-2048 seems the actual standard, at least still allowed for a few years.

So we added pure pascal RSA cryptography and X.509 certificates support in mORMot.
Last but not least, we also added Hardware Security Modules support via the PKCS#11 standard.
Until now, we were mostly relying on OpenSSL, but a native embedded solution would be smaller in code size, better for reducing dependencies, and easier to work with (especially for HSM). The main idea is to offer only safe algorithms and methods, so that you can write reliable software, even if you are no cryptographic expert. :)

Rivest-Shamir-Adleman (RSA) Public-Key Cryptography

The RSA public-key algorithm was designed back in 1977, and is still the most widely used. In order to fully implement it, we need to generate new key pairs (public and private keys), then sign and verify (or encrypt or decrypt) data with the key. For instance, a private key is kept secret, and used for an Authority to sign a certificate, and the public key is published, and able to verify a certificate. It is based on large prime numbers, so we needed to develop a Big Integer library, which is not part of Delphi or FPC RTL.

Here as some notes about our implementation in mormot.crypt.rsa.pas:

  • new pure pascal OOP design of BigInt computation optimized for RSA process;
  • dedicated x86_64/i386 asm for core computation routines (noticeable speedup);
  • use half-registers (HalfUInt) for efficient computation on all CPUs (arm and aarch64 numbers are good);
  • slower than OpenSSL, but likely to be the fastest FPC or Delphi native RSA library, thanks to our optimized asm: for instance, you can generate a new RSA-2048 keypair in less than a second;
  • internal garbage collection of BigInt instances, to minimize heap pressure during computation, and ensure all values are wiped once used during the process - as proven anti-forensic measure;
  • includes FIPS-level RSA keypair validation and generation, using a safe random source, with efficient prime number detection, and minimal code size;
  • features both RSASSA-PKCS1-v1_5 and RSASSA-PSS signature schemes;
  • started as a fcl-hash fork, but full rewrite inspired by Mbed TLS source because this initial code is slow and incomplete;
  • references: we followed the Mbded TLS implementation (which is much easier to follow than OpenSSL), and the well known Handbook of Applied Cryptography (HAC) recommendations;
  • includes full coverage of unit tests to avoid any regression, validated against the OpenSSL library as audited reference;
  • this unit will register as Asym 'RS256','RS384','RS512' algorithms (if not overridden by the faster mormot.crypt.openssl), keeping 'RS256-int' and 'PS256-int' available to use our unit;
  • as used by mormot.crypt.x509 (see below) to handle RSA signatures of its X.509 Certificates.

For instance, if you want to access a TCryptAsym digital signature instance with RSA-2048 and SHA-256 hashing, you can just use the CryptAsym global variable with caaRS256 algorithm as factory.
If you need just public/private key support, you can use CryptPublicKey or CryptPrivateKey factories with ckaRsa algorithm.

About RSA security:

  • RSA-512 or RSA-1024 are considered unsafe and should not be used.
  • RSA-2048 confers 112-bit of security, and is the usual choice today when this algorithm is to be used.
  • RSA-3072 could confer 128-bit of security, at the expense of being slower and 50% bigger - so switching to ECC-256 may be a better option, for the same level of security.
  • RSA-4096 is not worth it in respect to RSA-3072, and RSA-7680 is very big and slow, and only gives 192-bit of security, so should be avoided.

Anyway, our library is able to support all those key sizes, up to RSA-7680 is you really need it.
See this SO response as reference about RSA keysizes.

X.509 Certificates

As we wrote in introduction, X.509 certificates are the base of most computer security.
The whole TLS/HTTPS stack makes use of it, and the whole Internet would collapse without it.

We developed our mormot.crypt.x509.pas unit from scratch, featuring:

  • X.509 Certificates Fields Logic (e.g. X.501 Type Names);
  • X.509 Certificates and Certificate Signing Request (CSR);
  • X509 Certificate Revocation List (CRL);
  • X509 Private Key Infrastructure (PKI);
  • Registration of our X.509 Engine to the TCryptCert/TCryptStore Factories.

The raw binary encoding is using the (weird) ASN.1 syntax, which is now implemented as part of the mormot.crypt.secure.pas unit.
We followed the RFC 5280 specifications, and mapped latest X.509 Certificates / CSR / CRL extensions, with some low-level but very readable pascal code using classes, records and enumerates. It features perfect compatibility with our ICryptCert high-level interface wrappers, ready to be used in a very convenient way. We support all basic functions, but also advanced features like open/sealing or text peer information in a human readable format.
When using our unit, your end-user code should not be lost within the complex details and notions of the X.509 format (like OIDs, versions or extensions), but use high-level pascal code, with no possibility to use a weak or invalid configuration.

Of course, it can support not only our new RSA keys, but also ECC-256 as implemented by our native mormot.crypt.ecc.pas, or any other algorithm, e.g. available from OpenSSL.

X.509 Private Key Infrastructure (PKI)

Our unit features a full Private Key Infrastructure (PKI) implementation.
In fact, X.509 certificates are as weak as the PKI they are used on. You can have strong certificates, but a weak verification pattern. In end-user applications, it is typical to see all the security being lost by a poor (e.g. naive) implementation of the keys interaction.

This is why our unit publishes a 'x509-pki' ICryptStore as a full featured PKI:

  • using our TX509 and TX509Crl classes for actual certificates process;
  • clean verification of the chain of trust, with customized depth and proper root Certificate Authority (CA) support, following the RFC 5280 section 6 requirements of a clean "Certification Path Validation";
  • maintaining a cache of ICryptCert instances, which makes a huge performance benefit in the context of a PKI (e.g. you don't need to parse the X.509 binary, or verify the chain of trust each time).

We tried to make performance and usability in the highest possible standards, to let you focus on your business logic, and keep the hard cryptography work done in the mORMot library code.

Hardware Security Modules (HSM) via PKCS#11

The PKCS#11 standard is a way to define some software access to Hardware Security Modules, via a set of defined API calls.
We just published the mormot.crypt.pkcs11.pas unit to interface those devices with the other mORMot PKI.

Once you have loaded the library of your actual hardware (typically a .dll or .so) using a TCryptCertAlgoPkcs11 instance, you can see all stored certificates and keys, as high-level regular ICryptCert instances, and sign or verify any kind of data (some binary or some other certificates), using the private key safely stored on in the hardware device.
This is usually slower than a pure software verification, but it is much safer, because the private key is sealed within the hardware token, and never leave it. So it can't be intercepted and stolen.

You are Welcome!

With those mORMot cryptography units, you now have anything at hand to use standard and proven public-key cryptography in your applications, on both Delphi or FPC, with no external dll deployment issue, and minimal code size increase.
We can thank a lot my employer for needing those nice features, therefore letting me work on them.
Open Source rocks! :)


Pascal In The Race: TFB Challenge Benchmarks

Round 22 of the TechEmpower Frameworks has just finished.
And this time, there was a pascal framework in the race: our little mORMot!

Numbers are quite good, because we are rated #12 among 302 frameworks over 791 runs of several configurations.

Continue reading


End Of Live OpenSSL 1.1 vs Slow OpenSSL 3.0

mormotSecurity.jpg, Sep 2023

You may have noticed that the OpenSSL 1.1.1 series will reach End of Life (EOL) next Monday...
Most sensible options are to switch to 3.0 or 3.1 as soon as possible.

mormotSecurity.jpg, Sep 2023

Of course, our mORMot 2 OpenSSL unit runs on 1.1 and 3.x branches, and self-adapt at runtime to the various API incompatibilities existing between each branch.
But we also discovered that switching to OpenSSL 3.0 could led into big performance regressions... so which version do you need to use?

Continue reading


Meet at EKON 27

EKON27.png, Sep 2023

There is still a bit more than one day left for "very early birds" offer for EKON 27 conference in Germany, and meet us for 3 sessions (including a half-day training/introduction to mORMot 2)!

EKON27.png, Sep 2023

Join us the 6-8th of November in Düsseldorf!

Continue reading


mORMot 2.1 Released

We are pleased to announce the release of mORMot 2.1.
The download link is available on github.

The mORMot family is growing up. :)

Continue reading


The LUTI and the mORMot

RegressTests.png, Jul 2023

Since its earliest days, our mORMot framework did offer extensive regression tests. In fact, it is fully test-driven, and almost 78 million individual tests are performed to cover all its abilities:

RegressTests.png, Jul 2023

We just integrated those tests to the TranquilIT build farm, and its great LUTI tool. So we have now continuous integration tests over several versions of Windows, Linux, and even Mac!
LUTI is the best mORMot's friends these days. :)

Continue reading


New DNS and (C)LDAP Clients for Delphi and FPC in mORMot 2

DNS and LDAP are the two protocols on which the Internet and the Intranet are built.
Most of the time, you don't have to care about them. But sometimes, you need to access them directly, especially in a corporate environment.

We just introduced in our Open Source mORMot 2 framework two client units to access DNS and LDAP/CLDAP servers.
You can resolve IP addresses and services using DNS, and ask for information about your IT infrastructure using LDAP.

Continue reading


New Command Line Parser in mORMot 2

For most projects, we want to be able to pass some custom values when starting it.
The command line is then used to add this additional information.

We have ParamStr and ParamCount global functions, enough to retrieve the information. You may also use FindCmdLineSwitch for something more easy to work with.
The Lazarus RTL offers some additional methods like hasOption or getOptionValue or checkOptions in its TCustomApplication class. Their are better, but not so easy to use, and not available on Delphi.

We just committed a new command line parser to our Open Source mORMot 2 framework, which works on both Delphi and FPC, follows both Windows and POSIX/Linux conventions, and has much more features (like automated generation of the help message), in an innovative and easy workflow.

Continue reading

- page 1 of 50