⬆️ ⬇️

SAP's electronic signature is just

Increasingly, I receive requests from customers about the use of electronic signatures in their decisions. Often, the very idea of ​​introducing an electronic signature already raises many questions, both technical and general - in connection with a collision with a very specific area of ​​information security, which has many nuances and references to legislation. With this article I want to show that the use of electronic signature is easy.



image





')

A bit of history



In 1977, Ronald Rivest, Adi Shamir, and Len Adleman publish their article “The method of obtaining electronic signatures and public-key cryptosystems” (hereinafter my translation):



Probably the era of email is near. We need to be sure that we can keep two important properties of the current “paper mail”: letters must remain personalized and can be personally signed. In our article, we will demonstrate how to implement these properties in an email system. The heart of our proposal will be a new encryption method. He applies the elegant concept of “public-key cryptosystems” proposed by Diffie and Hellman.


“The elegant concept of Diffie and Hellman,” which the authors write about, was indeed an important step in the field of cryptography. By the mid-seventies, the NSA (National Security Agency) had already controlled the widespread use of cryptography by controlling the means of distributing encryption keys. However, the principle of distribution of public keys proposed by Diffie and Hellman allowed to get away from it, and now individuals and legal entities have gained a way to securely exchange encrypted messages without receiving a shared secret (“symmetric”) encryption key from a third-party government organization.



The principle proposed by Diffie and Hellman can be illustrated by the example of “colors”. Each party has its own “secret” paint, but exchanges with a partner only a mixture of colors (Alice - orange and Bob - blue as a “greeting”; the second time - brown as an encryption key). It is assumed that to find the “secret” paint in the mixture is not possible.







In the original, of course, the cryptographic robustness of the algorithm proposed by Diffie and Hellman is based on mathematics - namely, the complexity of the problem of discrete logarithm ( https://ru.wikipedia.org/wiki/Discrete_logging )



This was not an electronic signature, but in the same article, Diffie and Hellman suggest using a private key (“secret paint”) to encrypt messages and issue a public key to check messages:

If user A wants to send a message to user B, he “decrypts” him with his private key and sends the result of “decryption” to the partner. User B can read the message and be sure of its authenticity (authenticity) using the public key encryption function. Anyone can use this function and get the original message as a result.

The world-famous RSA algorithm in the field of electronic signature (following the first letters of the names Ronald Rivest, Adi Shamir, and Len Adleman) fully implements the principle proposed by Diffie and Hellman.



In fact, the two articles mentioned in 1976–1977 laid the foundation for 95% of the cryptography used today. Client-server encryption, cross-server encryption, electronic signature, etc., are all the result of using the principles proposed 39 years ago.



Electronic signature in Russia



Ironically, but despite the fact that almost 40 years have passed since the publication of the RSA algorithms, we still have to keep an absolute majority of documents in paper form.



However, the world does not stand still, and every year the law allows more and more documents to be translated into electronic form using an electronic signature to give documents legal value. There is no doubt that in the future for 20 years ahead, all legislative barriers will be removed and the need to store paper documents will disappear altogether. The experience of Estonia, in which electronic signature functions are used even in such subtle areas as during voting (including parliament), is a good example.



Today, the field of application of electronic signature in the Russian Federation can be divided into five large areas:



The main advantages of using electronic signatures are a significant acceleration of document circulation (especially in the scale of global corporations) and an increase in the security of information exchange in general.



If your company already has an electronic document flow, then with the help of an electronic signature you can give it legal significance. In the case of communication with customers, contractors and government agencies, the use of electronic signatures speeds up the interaction, ultimately reducing costs.



SAP Electronic Signature



One of our clients in the field of oil and gas saves 4 million rubles annually only on a single printing of documents, replacing the printout of inventory cards with the storage of documents in the form of an electronic signature. SAP recommended using the sapcryptolib library as a means of cryptographic information protection (CIPP). Along with commoncryptolib, it can be installed in the standard delivery package of most SAP solutions. It should be noted that since these libraries have the implementation of cryptographic tools, they are subject to the regulators. Ask if your organization can import them.



The standard SAP cryptographic provider has already been connected to the FI (Finance), SD (Sales), HR (Personnel), and other modules:



image



Thus, the ES function is already implemented at the SAP NetWeaver platform level, which means that the functions of document signing and verification are already available for the enterprise business processes. It remains only to connect them.



As is known, Russian legislation (No. -63 “On electronic signature” of April 6, 2011) defines three types of electronic signature:



Simple and unskilled ES can be implemented in the standard delivery of SAP NetWeaver. At the same time, the range of available functions is quite wide:

  1. Signature and verification on the server and on the thin client
  2. PKCS # 7, XML, S / MIME, Adobe PDF Forms Support
  3. NetWeaver ABAP and NetWeaver Java support
  4. Work in SAP GUI and Web Applications
  5. Cyrillic certificate support
  6. Using Microsoft Keystorage secure certificate store (Windows OS level)
  7. Using USB Tokens and Smart Cards
  8. Verification of the signature of a trusted issuing certifying authority (verification of the certificate chain)
  9. Verification of certificates for revocation (by Certificate Revokation List - CRL)
  10. The possibility of archival storage of electronic signature (with versioning)
  11. Getting Active Directory Certificates (via LDAP)
  12. Certificate Management (Public Key Infrastructure - PKI)


(some features may require additional licenses)



Speaking about the qualified EP, it is necessary to understand that the requirements for this type of EP differ from country to country. For example, the German Electronic Signature Act (“Signaturgesetz”) of 1997 requires that certificates used in an ES are issued by a qualified certification authority, only individual devices, smartcards or tokens, are used for signing, and the signed electronic documents themselves must be written only to unchangeable media (for example, on optical discs).



Therefore, in questions of the implementation of a qualified ES, SAP relies on the assistance of the developers of CIPF.



The principal requirement of the Federal Security Service for software certification for qualified electronic signature is the use of GOST 28147-89, GOST R 34.11-94, GOST R 34.10-2001 in the implementation of cryptographic algorithms (as of June 2015, the requirements for the use of GOST R 34.10-2012 and GOST R 34.11-2012 not fully regulated)



Technically, the use of GOST cryptographic algorithms in SAP is achieved by simply switching the “wrapper” of the SKZI. “Wrapper” replaces the use of the standard sapcryptolib library by referring to any third-party SKZI built on GOST. For example, LISI-CSP, CryptoPro CSP, Validata CSP - if we are talking about the MS CSP interface; PBZI "SKZI LirSSL" if the OpenSSL interface is used; ruTokenETSP / eTokenGOST if we are talking about tokens / smart cards with a PKCS11 interface. In particular, the solution of LISSI-Soft LLC, called FoxSSF, allows you to use ICPS with the support of all three of the above interfaces. In our next article we will talk more about solutions that allow you to sign SAP documents with a qualified electronic signature.



In conclusion, it is necessary to mention the problem of archival storage of documents signed by ES. Since Unlike paper signatures, algorithms and certificates of electronic signatures tend to become obsolete, you must take care to obtain long-term certificates from the most stable and respected certificate authorities. If more than five years of storage is planned, then a time stamp must be put on the documents to be signed. This approach allows you to record the time signature, therefore:



If time stamps are not used, then after a certain period of time there will be a need to re-sign documents, which, of course, is a rather costly procedure for large organizations. From the point of view of the legislation, the subtleties of long-term storage have not yet been fully worked out, for example, the question of whether it is possible to re-sign all documents just once by one signature remains open.

In this case, technically, in what form you store the signature: in the form of a database table, archive or file - it does not matter. SAP has three repositories for archival storage: the ArchiveLink, the Archive Development Kit and the Knowledge Warehouse. For documents (PDF, DOC, etc.) we recommend using ArchiveLink, and for database tables - Archive Development Kit. In turn, only Knowledge Warehouse allows you to record data in a background job. All three options can provide data for verification (auditing) and work with external devices in order not to burden the application server.



The author - Daniel Luzin

Consulting subdivision of SAP CIS LLC

Kosmodamianskaya emb. 52/7, 113054 Moscow

T. +7 495 755 9800 ext. 3045

M. +7 926 452 0425

F. +7 495 755 98 01

Source: https://habr.com/ru/post/260765/



All Articles