Integrators

Integrate AxiomaticId in your systems

Home

Why open source?

Typical integration

Protection against attacks

Integrators of AxiomaticId can find all the information they need, in here.

AxiomaticId is a set of open source applications developed in C#, which work on any system with DotNet (at least version 4.0).

AxiomaticId doesn't work on Mono because this doesn't support the graphical user interface from DotNet.

AxiomaticId is designed to handle most of the work required to implement an action processing service compatible with AxiomaticId. Of course, action processing services still need to develop the code which processes AxiomaticId documents inside their system, but that is all they need to do. They don't need, for instance, to implement a user interface (or rather, they need to implement only a minimal user interface, one which would simply display messages to the user).

Integrating AxiomaticId is necessary only for automated services, like currency operators. However, merchants could either integrate automatic verification of the AxiomaticId documents they receive, or they could have employees who manually perform the verification (using AxiomaticIdManager). In fact, having employees could be better because there might be some need for special interpretation of the data sent by customers (in AxiomaticId documents).

Why open source?

It's a business model.

AxiomaticId is open source because we, the AxiomaticId Entity, want clients to trust (by analyzing the source code) that AxiomaticId does what we say, we want clients to be able to change the source code so that it does what they want, we want programming and cryptography experts to analyze it for weaknesses.

For us, open source is the business model which can bring the highest reputation to AxiomaticId. As its reputation and usage increase, so does the profit that it earns for us and for our clients. Profit is not necessarily measured in money, but for certain in reach, reputation and in the strength and freedom it gives to people who want to fight for their Life, Liberty and Property.

If you want to share your ideas with the AxiomaticId Entity, in hope that they would be integrated in AxiomaticId, please consider that the core must be simple enough so that the developers could maintain a high level of reliability of the source code. Also consider deriving the existing code for the specialization you may need, instead of trying to push specializations into AxiomaticId.

Typical integration

A typical integration, for an online service provider, of AxiomaticId consists of a library which executes (in the database) the actions requested by the service's users.

The service uses direct socket connection and therefore it doesn't need either ASP.Net or IIS.

For details, see the source code of AxiomaticId.

Protection against attacks

Processing asymmetrically signed and encrypted documents is a very slow operation. This fact exposes an AxiomaticId service provider to potential attacks where someone would try to suffocate the service with many requests for document processing.

Using an automated process, an attacker could succeed to effectively shut down the service provider's ability to process the documents of legitimate users.

There are two main types of attacks which can be launched against an AxiomaticId service:

DDOS.
Sending the same document repeatedly.

AxiomaticId reduces the effects of DDOS attacks by letting service providers specify a list of processing (or traffic redirecting) URIs in the service descriptor. The effects could even be eliminated if the attack is not against all processing URIs. Of course, this requires the URIs to point to different physical servers.

An attacker could repeatedly and quickly send to the service provider a document which was properly signed and encrypted. To protect against this type of attack, an IP filter has to be used to reject the requests which are coming from the same location, too many in a given time frame.

Documents

The AxiomaticId documents are in XML format.

Here are a few examples AxiomaticId documents:

Account identity document. Aside from the obvious stored account identity, this document stores another account identity in a form which makes it impossible to see if it has valid content or just random data..
Person presentation identity document.
Group presentation identity document.
Claudia-Bob certification powers delegation.
Age certification document. The certification is granted by Bob, but "AxiomaticId.Tester" checks if the certification was granted by Claudia. Normally, this would cause "AxiomaticId.Tester" to say there is a missing signer, but the signature verifies because there is an attached (age certification) delegation (Claudia -> Bob), and it appears that the certification was indeed granted by Claudia.
Action request.
Action response.
Asymmetrically encrypted document.
Full hash serializer output. A normal hash serializer is used for signing to guarantee binary identical output, regardless of platform. A full hash serializer includes the unsigned data (like the signatures themselves).

The documents which contain encrypted data (the account identity document, the action request, the asymmetrically encrypted document) also contain the unencrypted data so that you could see what is actually stored.

Performance

Here are the results of test for cryptographic operations.

The cryptographic algorithms are also open source, adapted from Mono (and from Classless for some hashes). They are written in C#.

The XML serializer (both serialization and deserialization) is custom made, using reflection. This guarantees the same serialization output, regardless of the platform it runs on, which is critical for signatures.

All tests have been performed with the GUI edition of the "AxiomaticId.Tester" on a computer with a 1.73 GHz Intel Mobile Core i7 processor, on Windows 7 64 bits (with a real-time antivirus).

The service performs processing in parallel, on all the available processors. To test this, simply run the "Payment service endurance" test with multiple instances of "AxiomaticId.Tester" (at the same time). If you run too many instances, there may be communication timeouts.

Legend:

MB = megabyte.
s = seconds.
ms = milliseconds.

The tests with results expressed in seconds (instead of bytes / second) are made from real life applications, and exclude theoretical values.

For instance, the verification of a signature includes:

The loading of the verified document from a byte array.
The serialization of the data to be verified. The data has to be serialized in order to create the same data buffer like the one which was used during signing.

Values:

Sha256 generation: 45 MB / s.
Ripe256 generation: 68 MB / s.
Sha512 generation: 61 MB / s.
Whirlpool512 generation: 11 MB / s.
Rijndael256-256 encryption: 37 MB / s.
Document signature generation for a 2048 bits key pair: 30 ms.

Document signature verification for a 2048 bits key pair (the signature of a presentation identity): 3.3 ms.
Passphrase blender performance: 149 operations / s.
Storehouse speed (for 300'000 documents, 3.6 GB database): 2500 s, 120 operations / s. Seek speed 1'100 operations / s, random seek speed 2'140 operations / s, search filter speed 1'700 operations / s.
Generation of an identity with two 2048 bits key pairs, batch of 50 identities, 6 rounds for the Miller-Rabin test: 2.4 s (but individually it varies wildly, even 3 times more).
Generation of an identity with two 4096 bits key pairs, batch of 50 identities, 4 rounds for the Miller-Rabin test: 34.5 s (but individually it varies wildly, even 3 times more).
Transaction duration, 2048 bits keys (using the service endurance test): 0.25 s (with 1 instance of the tester), 0.084 s (with 8 instances). This includes local round-trip processing. The network communication is local. The data is encrypted and signed in all relevant ways. Action requests, responses and charged fees are not saved, but the new status of the accounts is saved.
Service endurance, 9 instances of the tester, batch test: 80'000 transactions. This test is meant to show any weaknesses in the used programming techniques, memory or resources retention or leaks, problems which may arise due to the use of random numbers, etc. The test indicated no weaknesses. The last major test had 8.5 millions cycles (and was stopped by external causes), but significant changes were made to AxiomaticId since then.

The generated pseudo-random numbers pass the Ent and DieHard batteries of tests. Use the "Work \ Generate entropy file" menu to generate a test file.

Source code

The source code of AxiomaticId is released under a Common Sense License. See the license terms for details.

The source code for AxiomaticId can be downloaded from here.

The AxiomaticId libraries can be used (independently) on both WindowsForms and ASP.Net, and for both the full and compact DotNet frameworks.

The source code for AxiomaticId is published as open source. The code is heavily documented, but given the nature of applied cryptography, you should try to understand the inner workings only if you have significant cryptographic experience. For examples see the source code of "AxiomaticId.Tester", from which you can understand the functionality of the core documents.

However, here are a few notes:

AxiomaticId could change significantly until it will be released to the public. Therefore, DO NOT base important operations on the it, use it only for testing.
Although the content of the documents is separated from the serializer, the serializer itself is bound to XML and so if you want to serialize the documents to another format you have to implement the entire serializer.

Testing the service

You can test the payment service which is part of AxiomaticId. This service was designed to be as scalable as the underlying database engine. Even more, the service can run distributed in different geographical locations, if the underlying database engine supports distributed transactions.

You must have installed on your computer:

"AxiomaticId.Tester".
AxiomaticId.PaymentServiceOps.
This step is not necessary for now. MS SQL Server 2005. You can use the Express edition.
This step is not necessary for now. Create a database named "AxiomaticIdPaymentService". Create a SQL Server login and database user named "AxiomaticId" with the password "opensesame". If you have the source code, you can execute the "AxiomaticId.PaymentServiceOps \ DatabaseScripts \ MsSql.sql" SQL script.

Here is what you have to do in order to test the service:

Start "AxiomaticId.Tester".
To modify the database connection string, click the "Work \ Create settings" menu and close the application. Edit the "AxiomaticId.Tester \ App.aist" file and modify the "ConnectionString" setting. Start the application again.
Click the "Do all test" menu.
Wait until a message box says that all tests have been performed.
Start "AxiomaticId.PaymentServiceOps".
Click the "Open service vault" button. In the dialog which is opened, navigate to the "AxiomaticId.Tester \ Documents \ service_vault.aid" file and double-click it. Now the service is started.
From the "AxiomaticId.Tester", double-click the "Service endurance" test. This will start an infinite test of the service, simulating the interaction between a user and the service. Note that the first time you try this you might get a timeout error because various lengthy operations must be executed by the operating system (like starting the database engine service).