The necessity to separate serialization and sending functionality for electronically represented business processes, depending on qualified electronic user signatures

[Former Member]

As promised in my last blog About Electronic Documents, Business Documents and Messages I will ponder a bit about the necessity to separate serialization from sending functionality for realization of security measures like the qualified electronic user signature (QEUS), legally required by some modern electronic business processes

My main thread will run along the following line: First I will give a typical example, where serialization and sending is not separated, but where serialization is delegated into sending functionality instead. Second I will explain what an electronic signature is and why direct access to serialization functionality is relevant for its application. Third I will outline what is special about a QEUS and last but not least I will discuss the consequences for a communication architecture, if we follow this line of thoughts.

A typical example of delegating serialization into sending functionality

A typical example, where serialization and sending are inseparably connected, occurs within every technology of remote calls of typed functions, where serialization becomes delegated into some sort of sending functionality. A typed function is a mapping between an instance of an input type and an instance of an output type. In the object oriented world, this may be extended by a second mapping of internal typed instances.

To let a typed remote function call look like a local function call in the program description, the proxy technology has been invented. It was recognized that the necessary data processing for calling a remote function follows a stereotyped scheme: Within the function consumer, the internally structured represented input data has to be serialized according to certain rules and send away. Within the function provider, this input data has do be deserialized following the reciprocal rules and feed into the actual local function. For passing the output parameters back, the same schema applies in the backward direction. So, the call of a typed remote function implies delegating serialization into functions with implicit sending semantics.

Remark: The question of synchronicity is unrelated to this issue, because it relates solely to the behavior of the function consumer. The provider is unaware whether the consumer holds its context of the function call implicitly and blocks further processing or explicitely and has to look it up when the answer comes back.

Electronic Signature

To understand what an electronic signature is, we have to understand the principles of asymmetric encryption technique first. With asymmetric encryption, there exist a pair of two keys, which relate to each other via encrypt() and decrypt() functions. Encrypting data using the first key, requires decrypting it with the second and vice versa. If we declare one key as 'private', i.e. unknown to anybody else except me, who generated the key pair and the other one as 'public', i.e. accessible to everybody who wants to communicate with me, then secure conversation becomes very easy. If someone wants to securely communicate with me, he has to have access to my public key, encrypt his data with this key, so that afterwards, it is just me with my private key, who is able to decrypt the data. Obviously, the encryption aspect of communication does relate to the receiver of the data, since it is his pubic key, which has to be used for encryption and his private key, which has to be used for decryption. A fact that makes delegation of encryption into sending functionality straight forward, creating secure transport channels.

An electronic signature denotes data which can be used to unequivocally prove that some other data has changed or remained invariant. Practically this is achieved by calculating a hash sum of some serialized data and encrypt this hash sum with the owned private key. The recipient of the data then can calculate its own hash sum of the data and has to compare this hash sum with the decrypted hash sum, provided by the sender. Signature relates exclusively to the sender of the data, since its private key is used to encrypt the hash sum and its public key is used to decrypt is again.

It is quite interesting to notify that signature relates to the logical sender system while encryption relates to the logical receiver system. I.e. both require their respective system to be well defined. Inverting this logical relation, we can say, that difficulties in providing end-to-end security with signature and encryption technique may indicate that our system notion is not well (enough) defined.

Both, encryption and signature essentially requires the data to be a string of characters, i.e. no other assumptions about the inner structure of the data are needed, which fits very nicely with the requirements for data, which has to be communicated. Any talk about encrypting or signing 'structured data' implies some sort of implicit serialization transformation. Whether the intermingling of such a transformation is compatible with the security requirements of a signature has to be decided on a case by case base. The main issue is that even the slightest change of the implementation of such a transformation, e.g. due to a minor bug fix, may invalidate every earlier signature. Another issue is that such transformations destroy the 1:1 relationship between the actual serialized data and its signature.

Qualified electronic user signature (QEUS)

The possible semantics of a signature not only depends on its technical implementation and algorithms but very much on the question to which system the key pair can be attributed and how high the probability and the costs of a false attribution are. These questions are addressed by the European legal frameworks based on the EU directive ‘On a Community framework for electronic signatures’ from Dec. 1999 , which was cast into the German signature law (SigG) 2001 and its supplement from 2005. Additionally and equally important, Germany has taken legal action to make the handwritten and the electronic signature legally equivalent by adapting the relevant laws. (§ 126 a BGB: electronic form, § 126 b BGB: text form, § 292 a ZPO: evidence facilitation (“Beweiserleichterung“) and § 3 a VwVfG: electronic communication)

For a qualified electronic signature, the law requires that the private key is

• Exclusively assigned to an identifiable human key holder who therefore must have exclusive control over the means to create the signature.
• Based on a qualified certificate, issued by certified agencies
• Created by a secure signature device, providing a signature API (e.g. PKCS#11).

In other words, making a qualified electronic signature, which is supposed to be relevant in a business process, a software system signs as a representative agent. This representative role of the computer imposes a certain obligation to exercise diligence in the handling of the private key of the business users. One of the resulting requirements is that it is not allowed to save private keys of the users on a permanently installed hard disk. Since the encrypt and decrypt functionality is provided by the signature device, the private key of a QEUS will not even be accessible to the computer at all. The signing has to happen, where the signature device is known, i.e. at the user frontend system. And since the private key is under the exclusive control of the human key holder, the signature functionality is only available if this key holder decides to do so and not the computer.

Remark: I do not discuss all the issues related to the question on how the relation between the electronically signed (character) data and the displayed (pixel) data is guaranteed.

Consequences

To cut a long story short: what are the practical consequences for electronic business processes? As we have seen, a signature in general requires the data to be already serialized and renders them immutable. This imposes the necessity of the following steps on business processes, which comprise viewing and signing business data by human users.

1. The business data has to be serialized into its final form, to be processed by its logical recipient
2. This serialized data has to be viewed by the business user
3. Now it can be signed with the temporary available business user key via the generic API of the signature device at the user frontend.
4. It can be sent away at some later point in time by some generic or untyped sending functionality.

As a first consequence we easily see, that serialization of the data and its sending is separated by the necessity to access the serialized data from a process level for viewing it. I.e. the serialized data becomes a fist level item of the business process itself. This means, that any technique for calling remote functions, like Java RMI or typed web services, which are intended to hide the serialized data representations are not appropriate for this sort of business process communication, where a computer acts as a representative of a human being.

It is quite obvious that business documents with the meaning I presented in my earlier blog do fulfill all requirement that stem from these kind of processes.

The second consequence is that QEUD guides us in answering partly the question on what it means if we say in a B2B process, "we have to know the logical partner". It means that we have to serialize our data according to the format and content needs of our logical business partner. And it means that we have access to a generic sending function, which will transport our (serialized) data enveloped as messages to him (eventually encrypted). We could say that QUES together with encryption provides the magic to make some aspects of the invisible bond visible that structurally ties us to our loosely coupled logical (business) partner.

What are the practical consequences for a B2B communication design, even in case that QEUS is not yet really required? What should we do today? It is my conviction that communication should be designed from the beginning so that security results more or less of its own volition. It should not be designed so that the communication model becomes invalidated by stricter security requirements like QEUS. It's more the other way around: Fulfilling strict security requirements easily is a good indicator for a good communication architecture. E.g. it does not make sense to describe business collaboration without assuming that the logical partners know each other. A communication architecture for collaborative business applications which is designed along a model of acquainted partners will probably have much less end-to-end security issues than a communication architecture, which is designed against it. In this sense, a communication architecture, which is designed along a process model based on the exchange of business documents is probably much simpler to adapt to the requirements of QEUS than any other one.