This article discusses why cryptographically protected data exchange between the EU and Russia (and other countries) is still difficult to implement.
“Sign the meaning, not the data!”. Fundamentally, a digital signature is a mathematical function. No more. No less. If you digitally signed your will “I leave all my property to my brother, John” and “I leave all my property to my lovely brother, John” you will get two different signatures, despite the meaning being the same.
Sometimes Horton’s principle is referred to as “Authenticate what is being meant, not what is being said”. If we aim for a harmonization in Russia and EU, we have to encode data, a digital signature, a certificate absolutely identically in both areas of jurisdiction. The particular PDF document, signed in Germany on a Windows x64 machine, must be understood by a Russian “Elbrus 401-PC”, regardless of completely different architecture. So this why proper encoding rules are so important for the harmonization. To accomplish such a state of identical interpretation, we need two additional rules, one about encoding, one about encapsulation.
The first method which is required should establish a set of encoding rules, independent of a geographical location, a computer architecture, OS etc. We made lots of efforts already: ASN.1 DER/BER, XML canonization. For harmonizing digital signatures, the PAdES, XAdES and CAdES formats are good examples of digital signature standards that are widely accepted. These standards are implemented throughout the EU and and beyond.
The next method should then “encapsulate” cryptographic operations among the group of absolutely identical computers. The OS, CPU architecture, word size - all are the same. An integer value means a 32-bit unsigned data, less meaning byte first. If equipment, OS etc are identical, there is no risk to interpret data differently, therefore no need for complex encoding schemes.
To many, developers Horton’s principal is difficult to grasp or even completely unknown. I have seen XML documents with PKCS-7 signatures, binary data and signatures in a custom, application-specific format etc.
Let's imagine two business entities - Cheese Inc of Latvia and Whole-Russia-Retail of Russia. The first produces a very good cheese and the second sells it. It is good and profitable business for both sides. These two enterprises have some software to handle accounting, logistics, resource management, etc. The software uses digital signatures (RSA-based), an encryption (AES, Twofish), and other security mechanisms. Everybody’s happy - this is private business.
On the other hand, if you sell gas or oil, you have to submit to local authorities - like the Russian government. Oil sales is an “official” business. Consequently, you have to follow rules, procedures, certifications, even in cryptography. If you are based in Russia, you have no rights to use RSA or AES - only certified Russian cryptographic tools.
The consequences can be inefficient. Let me give you two examples from my own experience.
Example 1 - I have seen a gas transition point between Belarus Republic and Russia. At this point, there is a network computer with two cryptographic modules - one module decrypts Belarus data stream (encrypted by Belarusian encryption) and another encrypts by Russian GOST. That’s it. The law is satisfied.
Example 2 - Some time ago I consulted a company developing a trading platform - a site where goods are sold and purchased. Transactions have to be digitally signed (and timestamped). The platform should be used by many countries; unfortunately, every country has its own CSP - Crypto Service Provider.
Every CSP is locally certified. Every CSP has its own signature algorithm. We found a solution - we used a Trusted Third Party protocol. Each participant uses their own cryptographic algorithm to sign data. TTP has it all. TTP validated the signature, composed responses and sent it with the locally legal signature. The law is satisfied, but it made the processing very slow.
The only exception in “official” cryptography is SWIFT interbank exchange. It is widely used. SWIFT is permitted to be with algorithms “as is”. As far as I know, there is only one company in Russia with exclusive rights to sell and support SWIFT. As you probably guessed, this company is tightly controlled by the Federal Security Service (FSB) of the Russian Federation.
Russia tends to keep some cryptographic “independence”. This is certainly a legacy of the Cold War. The idea is that in case of hostile confrontation, Russian systems would not be affected by “hidden” RSA and AES vulnerabilities.
Russians fear that RSA, AES and other western algorithms:
Russian cryptographers have reasons to think that way. Decades of the Cold War forced them to mistrust western technologies. Revelations shown by Mr. Snowden and WikiLeaks substantiated the fear of many Russians, that statement 3 could be real.
We can indeed harmonize digital signing and EU and Russian data exchange but, as outlined above, there several areas that need to be addressed before this is possible. What needs to be done to achieve this goal?
1. Bury fears about RSA and AES. The algorithms are reliable - explored by thousands of cryptologists.
2. If Russians want, they can create locally certified RSA/AES cryptographic service providers/hardware modules. No back doors, no foreign components - everything is local, potentially even the chip topology.
3. The locally made solution could be certified by respected and independent international organizations.
4. EU should accept elliptic curve[s] used by Russians as a valid digital signature algorithm.
5. Accept CAdES, XAdES, PAdES widely. CAdES for binary data, XAdES for XML, PAdES for PDF. If PKCS-7 is used, the data to be signed should be ASN.1 DER/BER encoded too.
6. Use timestamping
7. Make educational efforts, explain Horton’s principle to software developers.
8. Create reliable timestamping authorities.
9. Create and maintain some central registry of business entities.
10. Develop the “digital mandate”.
11. Create and ratify international agreement on the points described above.
The impact of such harmonization would be significant, perhaps even disruptive, with consequences like:
1. Legal harmonization of two large internal markets. If you question the validity of a digital signature, you can get legal support - in Moscow, in Geneva, in Berlin - no difference. The law is the same in ANY location in ANY country. If you are right - you are right everywhere. Your digital signatures are equally effective and of high probative value everywhere, and accepted everywhere, like your handwritten signature.
2. It will accelerate and potentially fertilize business transactions within these twinned areas of jurisdiction.
3. Cryptographic equipment manufacturers could compete freely without artificial borders, to the benefit of efficiency, security and cost.
4. Absence of fear for businessmen: you would not be worried about “uncertified cryptographic software” - being able to choose between RSA or GOST or other included standards. In fact, it will help very much to “unhide” many businesses from a black market.
More generally speaking, the harmonization can pave way for further peaceful cooperation between East and West.
One Swedish sociologist says that in next 50 years there will be no “countries” anymore. There will be about 600 big cities around rural societies, but countries as a phenomena will be forgotten. Remember that EU always had tendencies to be united in the past. Remember e.g., Deutsche Hanse or Düdesche Hanse, where Russian Novgorod was a regular member - around 400 years, folks!.
- REGULATION (EU) No 910/2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC(2014) by the European Parliament and the European Commission
Electronic Signatures and Infrastructures Activities (2017), by ETSI