03.12.2019

Cloud ecp. Cloud electronic signature


In the traditional sense familiar to the vast majority of users electronic signature(ES) the key of this very signature is stored by its owner. Most often, a certain secure key carrier in the format of a USB token or smart card is used for this, which the user can carry with him. This key carrier is carefully guarded by the owner from unauthorized persons, since the key falling into the wrong hands means its compromise. To use the key, specialized software (CIPF) is installed on the owner's device, designed to calculate the ES.

On the other hand, in the IT world, the concept of "cloud computing" is increasingly being used, which in many ways has a lot of advantages compared to using traditional applications installed on the user's computer. As a result, there is a completely natural desire to take advantage of these advantages of cloud technologies to create "ES in the cloud".

But before solving this problem, it is necessary to define what we mean by "electronic signature in the cloud". Currently, in different sources you can find different interpretations of this concept, often suitable only for explaining on the fingers to a person "from the street" who went to the Certification Center to "buy an electronic signature".

What is a qualified electronic signature in the cloud

For the purposes of this article, as well as other popular science and practical discourses on cloud electronic signature, it is proposed to use the following definition.

An electronic signature in the cloud (cloud electronic signature) is a computing system that provides access via the network to the possibilities of creating, verifying ES and integrating these functions into business processes of other systems.

In accordance with this definition, a local ES tool can also be used for a cloud-based electronic signature. For example, using the user through a web browser can sign an electronic document using the ES tool installed on his terminal device ( Personal Computer or tablet). In such a system, the signature key remains with the owner and security issues are resolved using a standard set of tools known in the world as "traditional ES". You can call it if you like cloud ES with local ES tool.

Another version of the cloud ES is obtained with using an ES tool hosted in the cloud. For the convenience of further presentation, let's call such a schemecompletely cloud-basedto distinguish it from the previous one. This scheme regularly causes heated discussions among specialists, since it involves the transfer of the signature key itself “to the cloud”. This article is intended to clarify a number of issues related to the security of a completely cloud-based ES.

Let's start with the main

The main headache when transferring any IT system “to the cloud” is the pain of “security officers” (and lawyers helping them) associated with the transfer of information “there” for processing or storage. If earlier this information did not leave some protected perimeter, and it was relatively easy to ensure its confidentiality, then in the cloud the very concept of the perimeter is absent. At the same time, the responsibility for ensuring the confidentiality of information is, in a sense, “blurred” between its owner and the cloud service provider.

The same thing happens with the ES key transmitted to the cloud. Moreover, the ES key is not just confidential information. The key must be available only to one person - its owner. Thus, trust in a cloud signature is determined not only by the personal responsibility of the user, but also by the security of storing and using the key on the server and the reliability of authentication mechanisms.

Currently, certification tests of our solution are being carried out. This is a cloud ES server that stores user keys and certificates and provides authenticated access to them to generate an electronic signature. Both of the above-mentioned aspects of the security of cloud-based ES in particular are the subject of research conducted during the testing of CryptoPro DSS. At the same time, it is worth noting that a significant part of these issues has already been considered in the framework of case studies. , on which CryptoPro DSS is based.

In our country, the organizational and legal aspects of using cloud ES are still poorly developed, so in this article we will consider CryptoPro DSS from the point of view of the requirements for the signature server developed by the European Committee for Standardization (CEN).

European way

October 2013 The European Committee for Standardization (CEN) approved the technical specification CEN/TS 419241 "Security Requirements for Trustworthy Systems Supporting Server Signing". This document requirements and recommendations are given for an electronic signature server designed to create, among other things, qualified signatures.

I would like to note that even now CryptoPro DSS fully complies with the requirements of this specification in the strongest version: the Level 2 requirements for the formation of a qualified electronic signature (in terms of European legislation).

One of the main requirements of Layer 2 is to support strong authentication options. In these cases, the user is authenticated directly at the signing server - as opposed to being allowed for Level 1 authentication by an application that accesses the signing server on its own behalf. All authentication methods supported by CryptoPro DSS satisfy this requirement Level 2

In accordance with this specification, user signature keys for the formation of a qualified ES must be stored in the memory of a specialized secure device (cryptographic token, HSM). In the case of CryptoPro DSS, such a device is the CryptoPro HSM cryptographic hardware and software module - certified by the FSB of Russia at the KB2 level as an ES tool.

Authentication of the user on the digital signature server to meet the requirements of Level 2 must be at least two-factor. CryptoPro DSS supports a wide, constantly updated range of authentication methods, including two-factor ones. In addition to the usual cryptographic tokens, a specialized smartphone application, such as one-time password generators (OTP tokens), can also be used as an authentication tool. The CEN document also mentions these methods.

Another promising method of Layer 2 authentication could be the use of a cryptographic application on the SIM card in the phone. In our opinion, this option The use of SIM-cards with cryptography is most realistic, since the construction of a functionally complete cryptographic information protection tool (or ES tool) according to the new requirements of the FSB based on only a SIM-card is hardly possible.

Considered data sheet also allows the use of an electronic signature server to generate signatures for a certain set of documents at once. This opportunity can be useful when signing a large array of homogeneous documents that differ only in data in a few fields. In this case, user authentication is performed once for the entire package of documents. Support for this use case is also available in CryptoPro DSS.

The CEN document also contains a number of requirements for the formation, processing, use and deletion of user key material, as well as for the properties of the internal key system of the electronic signature server and for auditing. These requirements are fully and even "with a margin" covered by the requirements for ES tools of class KB2, according to which the CryptoPro HSM PACM, which is responsible for these issues, is certified.

Our future

The CryptoPro DSS solution supports a wide range of authentication methods, among which it is possible to choose the right one for each task. The reliability of the safest of them meets the most stringent criteria of European requirements CEN / TS 419241 and, as we expect, in the near future will be confirmed by a certificate of conformity from the FSB of Russia.

Alexey Goldbergs,

deputy technical director

LLC "CRYPTO-PRO"


Stanislav Smyshlyaev, PhD,

head of information security department

LLC "CRYPTO-PRO"

Pavel Smirnov, Ph.D.,

Deputy Head of Development Department

LLC "CRYPTO-PRO"

June 19, 2014 09:21 am

IN Lately we often talk about electronic signature (ES) in the cloud. Basically, this topic is discussed by IT-specialists. However, with the development of services electronic document management(EDO), subject specialists such as accountants, secretaries, auditors and others began to get involved in the topic of cloud ES.

Let me explain, a cloud-based electronic signature implies that your private key The ES is stored on the server of the certification center, and the signing of documents takes place there. This is accompanied by the conclusion of relevant agreements and powers of attorney, and the actual confirmation of the identity of the signatory occurs, as a rule, using SMS authorization.

The need to use cloud ES by an accountant depends on the mode in which he works. If you are often away from the office or, for example, work for a company that provides accounting services (accounting outsourcing), then cloud-based ES will help you sign documents from anywhere. There is no need to install any additional software. However, despite the ease of use, not all companies are ready to use this opportunity.

So that you can choose for yourself whether you need a cloud-based electronic signature or not, we will consider all the pros and cons of using it. And also think about who might really need such a signature. By the way, in this article we will only talk about enhanced qualified electronic signature (hereinafter referred to as ECES).

Behind

Cloud electronic signature is cheaper than usual. This is mainly due to the fact that you do not need to purchase a cryptographic information protection tool (CIPF) and a token (flash drive with a certificate). As a rule, taking into account their acquisition, the price of a certificate soars by 2-2.5 times.

Convenience and ease of use. To work with a cloud-based electronic signature, you do not need to install both the electronic signature certificate itself and special means to work with her. This means that you will not waste time figuring out how it all works.

Mobility. On this moment common and free solutions to use a non-cloud electronic signature on mobile devices Not yet. In this regard, a huge advantage of a cloud-based electronic signature is that you can work with it from any computer, tablet, smartphone with Internet access.

Against

You do not physically sign the document. You need to understand that in the case of a cloud-based electronic signature, the private part of the key, which is confidential and should belong only to you, will be located on the server of the certification center. Of course, this will be documented, and the servers themselves are securely protected. But here it all depends on the company's security requirements and on the policy associated with signing documents. If it is important for you that the owners of the private keys themselves sign the documents, then a cloud-based electronic signature will not suit you. In this situation, it is up to you to decide how much you trust the CA and the servers that store the private keys.

You can use cloud-based ES only in those services with which there is integration of the certification center software. This is also due to the fact that in the case of cloud ES, the private key is stored on the CA server. In order for the service you need to be able to use such a private ES key for signing, it needs to be able to send a request for generating an electronic signature to the CA server. It is clear that at the moment there are many services, and all of them will not be able to provide integration with the CA software. It turns out that you will have to use cloud ES only with certain services. To work with other services, you will have to buy another ES certificate, and there are no guarantees that these services will support any cloud-based electronic signature.

And what?

Cloud electronic signature is a convenient, mobile and simple tool, but not the most flexible. And in terms of security, perhaps storing the private key on a secure server would be better than keeping a token in a drawer.

Who really needs an electronic signature? First of all, those who often work outside their office in the office. For example, lawyers and auditors who often visit clients. Or executives and directors for whom it is important to sign documents anywhere. For them, a cloud-based electronic signature will become indispensable assistant at work.

Also, a lot depends on the policy of the company. If an organization is moving towards cloud technologies, for example, in terms of storing documents, using services for internal and external document flow, then electronic signatures are also likely to be cloud-based. Otherwise, accountants, clerks and other employees who usually do not leave their office during work do not need a cloud-based electronic signature. They can purchase an ES private key and an ES certificate in the usual mode, on a carrier that can be used in most services for exchange with counterparties and government agencies.

(4.33 - rated by 9 people)

Similar posts

Well, it's not true. For example, there has been Crypto-Pro for iOS for a long time. EDMS solution providers use it. For the same DIRECTUM, there is also an EDS based on Crypto-Pro for Android.

Physically, any electronic document is not signed by you. The software does it.

More precisely, not on the CA server, but in a specialized hardware server for storing keys of the electronic signature service that interacts with the information system (electronic document management).

In this case, indeed, the user does not need to install anything on himself, but the entire security of using the key does not depend on the user, but on the reliability of the authentication of the key owner by the electronic signature service and the information system.

Well, the key can be used only in those information systems that are "connected" to the electronic signature service that stores and applies the owner's key. Those. the key will be "not fully functional" (for example, it cannot protect the connection to servers with cryptography, operating system, e-mail and files, provide authorization for the GOSSLUGITOCHKARU and many more places), but only for a specific task in a specific system. It's like comparing a bus and a tram, everywhere there is +/-.

There are solutions, but they are not common due to their relative insecurity. Free unknown. And will they show up...

I have a slightly different point of view: if the primary one is not a cloud certificate, but a cloud service. Yes, a single cloud certificate can not be used for all services. But the value, in my opinion, is not in the certificate, but in the services. And there is nothing wrong with the fact that each service uses its own cloud key. Unlike "on premise" certificates (on tokens, smart cards, or in the registry of your personal device), you don't have to carry token beads or copy certificates to registries on all devices. Just sms will come from different numbers. Moreover, a cloud certificate is usually cheaper on premise, and no software (cryptoprovider) purchase is required. Well, from a security point of view, such a scheme a priori looks more reliable, since when one key is compromised, others can remain working (uncompromised).

There is nothing shameful, but the cost is more than using one full-function key (not beads) in many systems. In the threat model of using the "cloud ES key", the risk of security breaches in the authentication channel is added. In addition, OTPviaSMS is not safe to use everywhere. And psychologically, most people feel more confident when storing their key in their safe than with a virtual key in a virtual storage with a conditionally secure channel for managing its use.

Of course, this is true as long as the signing is initiated by one device, and the SMS with the signing confirmation code arrives on another device. And as soon as the mobile client is left alone, such a scheme is no longer a priori more reliable. Only user convenience remains, but not reliability.

The user can win, get some advantage over competitors using paper with ink or physical tokens with OneTimePassword hardware support, due to faster response, greater mobility. But he also takes big risks. Service unavailability risk. The risk of compromise of the mobile device. Risks are justified when it comes to small amounts of money. I would trust a deal for a million to the good old paper, signed in silence, without prying eyes, without intermediaries and without haste.

If you need to sign a package of 30 documents. And the service does not support batch signing. Then you will have to receive 30 SMS (or one with 30 confirmation codes) and enter confirmation codes 30 times. This is the time, and the reaction is no longer faster.

But if each service has its own service for setting up an ES, then the integration of services should be very close. And batch signing will be included there. For example, one logical SMS will come: "Code 0xs3cr3t for operation #22_1806. Dear Konstantin Vasilievich. To confirm receipt of incoming documents for the period 06/01/2014-06/18/2014 (20 invoices, 7 acts of work performed and 3 waybills ), namely, the signing of 30 official documents confirming receipt, enter the specified code".

There are solutions. But, as far as I know, CryptoPro for iOS and Android is not distributed for free.

Agree. In general, this is what is meant. In this regard, using a cloud certificate is not very convenient.

In general, if you need to work with several services, then buying several cloud ES can be even more expensive than buying one qualified certificate, CIPF and token.

As for reliability, it is a question of trust in the security of the place where the keys will be stored, in the technologies with which the signing will be carried out. I think that while the technology is not very well tested, there will not be much trust. But, you see, using a cloud signature is still quite convenient in some cases. To understand which signature is suitable in a particular case, you need to look at the processes, study the needs, evaluate the pros and cons of both options, and then make a decision. Therefore, we try to show both sides of the same coin of cloud ES.

And for which platforms is CryptoPro free?

I think the technology solves little - the only question is trust in the solution provider to whom you entrust your certificate.

Therefore, when they talk about such technologies in the context of intra-corporate use, I also understand that it can "take off". As soon as we talk about trusting a certificate to a third party, I don't see any chance.

As far as I remember, Crypto-Pro for iOS and Android is not sold to end users. Therefore, everything goes at the discretion of the application software vendor. If he wants to give it to you for free, he will. If he doesn't want to, he won't. Or it can give in addition to the functionality for which you bought the solution.

Is this a guess (as in the original article) or can you back it up with real numbers?

As well as Microsoft, Facebook, Twitter and hundreds of other providers of federated authentication, and each resource chooses which provider to integrate with. Do you suggest doing the same with the storage of certificates?

And do I understand correctly that you equate federated authentication, in which no user data, with the exception of a very limited set transmitted with an authentication token, leaves the service perimeter and the EDS service through which all your signed data will have to pass?

It may not be. A cloud key does not require a token or software. The service may, for example, include the cost of issuing a cloud token in the subscription fee and provide cloud certificates "for free". In any case, this is a matter of marketing, not technology.

You can also sign a package of 30 documents. This is how the service itself is configured, whether it supports batch signing. And where does the key come from (from the cloud or from the registry / token) - this is already an orthogonal question. Thank you, you further developed this idea in a comment. This often happens on paper as well. The big boss can only sign the register of payments with his own hand, and the payments are then signed by authorized persons.

Glory to the point! :) While the cloud signature is used in cloud accounting and reporting.

Misha, already working :)

Eugene, I applaud your comment while standing :)

Misha, let's wait for Evgeny's answer, but I understood this as an example. A new, more convenient and, possibly, less safe solution, due to its convenience, is accepted by consumers over time, since the resulting comfort outweighed possible risks. Perhaps before the first disaster. It is possible that consumers will continue to use this solution after the negative event.

Cloud signature now seems more convenient, but a priori less secure. But some users will be seduced by the convenience and assess the security risks as acceptable. And will use the cloud signature.

Cloud signature is already working in the "low-cost" segment. It would be interesting to try it in the "enterprise" segment. Perhaps the words "CryptoPro HSM" or something else will calm the business. We must think, offer and try.

Well, remove the "mobility" argument from the "for" section in the article article.

Why is she there?

Do I understand correctly that cloud accounting is a service on which records are kept and from which reports are then sent? Why is it not enough just to authorize the user on the service in this case? Why else EDS - to meet the requirements of the regulator?

Where exactly? Within one service or services of one supplier? Ok, accepted.

Only now do I need to get a certificate from each supplier? So?

What exactly is it comfortable for?

I see a plus in only one thing - if you use a web service, then organizing a signature from a local client can be problematic.

In my opinion, the mention of CryptoPro (as well as everything related to our strange "Russian qualified signature") normal business is already beginning to be idioskarziya.

Yes, that's right, but it can be different services. Not everyone needs accounting and reporting. Many people prefer to keep accounting on premise, and then submit reports through the service. CEP is needed to comply with legal requirements.

Yes, it works inside the services of one provider. Theoretically, you can learn to provide a cloud certificate to other providers, if this will economic sense. But the value, in my opinion, is provided precisely by the services and environments where ES can be used, the mere possession of a cloud or regular certificate does not make economic sense.

In the case of a cloud certificate, the user does not need to install software on his device and think about copying certificates to each device or always carry a key carrier with him. Owning a cloud certificate is less of a hassle, so I wouldn't be so intimidated by getting a bunch of certificates from different providers. And the cost of the required software and key carrier (in the case of on premise certificates) will be noticeably less than subscription fees, so the use of one universal certificate is more a matter of convenience than economic benefit.

Read about HSM - an interesting thing. Foreign competitors have similar solutions, and for a long time. So here CryptoPro uses the universal world experience.

I am glad that this topic is of interest. I will try to develop the above concept of a cloud service, taking into account the comments. 1. Cloud service as the development of information systems is already a fait accompli, which means that software manufacturers are being brought up to this standard. In terms of cost reduction - previously you had to buy 2-3 software product that meet your needs, now it is 1, and 30-40% lower in total cost.

2. What is a digital signature and who needs it in the first place? The CPU is your identifier in IT systems, allowing you to say "I am I" to make decisions at any level of financial responsibility with a guaranteed level of protection against hacking or misuse. In any case, the appearance of the CPU is the evolution of a "live" signature in order to accelerate the implementation of the company's business processes. Those. if earlier paper document processed slowly, now one click is enough to make decisions.

3. Nobody says that there are ideal solutions and means. Indeed, CryptoPro has set the teeth on edge when using it. Recently I reinstalled the system for accountants using 1C, VLSI and 2 bank accounts through the web interface (using CryptoPro) - I cursed everything until I added all the necessary certificates and key support.


Michael, not exactly an equals sign. Rather, the identity sign, because FA allows you to implement a single window mechanism for users of different domains, i.e. acts as an identification guarantor for the authorization participant. The EDS service itself has authorization tools and solves its specific tasks. In this case, a clear example is the website of public services and satellite services (for example, ROI). The public services website is a FA that guarantees user identification for other services.

Sergey, I absolutely agree with you. A cloud signature can and should act as a single identification service accepted by other participants in business processes. Now, it's all too fragmented and there are many intermediaries in the way of document movement.

Where does this conclusion come from?

Maybe you don't know how to use it? Installing certificates is a very trivial task and no one raises questions. Moreover, technologically it is no different from installing certificates on other crypto providers.

Use CONVENIENT applications that work with CIPF and you will be happy.

Now what is sold under the name "cloud signature" cannot in any way perform the functions of an identification service, because itself depends entirely on authentication. The cloud signature does not have an identification task, it is required to transfer the signature generation process from the workplace to the cloud, but only for the reason that workplace user is not so safe to work with CIPF.

What is fragmented? What are the intermediaries? If about UC, then it is needed for manufacturing qualified certificates. If about the operator, how do you imagine it without him? Need electricity operator, network access operator, cloud signature service operator, operator information system and so on. This is a specialized activity. We do not have subsistence farming.

No matter how I said it :) I completely admit the use cloud signatures for individual services, okay, let the services from one operator. But for the time being, I would hesitate to use it as a single identification service.

Yeah, lately one often hears how EDF operators are compared to air sellers. I’ll probably write a big article about what the operator does, in addition to ensuring legal significance, for now I’ll limit myself to theses:

1. Creation of ED. In the service interface, as a rule, you can create the most common EDs (ESF, TORG-12, acts, etc.).

2. Storage of ED. I can’t speak for all services, but Diadoc keeps your documents until you delete them yourself. Even if you are no longer paying a subscription fee.

3. Single legal space. Try to conclude agreements with all your counterparties, if you are, say, a telecom operator or an energy sales company!

4. Transport. Ok, will you be able to organize the transportation of electronic documents through communication channels and control the signing for all your 10,000 counterparties? Oh well...

5. Integration. I'll tell you a little story. One transnational corporation decided to send through the operator ESF and TORG-12. Yes, the trouble is that ERP could only upload PDF and then in a special perverted format. IT Corporation was somewhere in Latin America and accepted orders for development for the next year. This is not counting the red tape with the formulation of m TOR and coordination on several continents. Who was able to quickly establish integration? That's right, operator.

Sergey, i.e. Can you summarize the failure of the IT infrastructure to ensure the required quality of ED within the existing ERP? Based on what you have said, ED is still in its infancy and cannot fully meet the needs of end users in full.

Then it turns out that paper manufacturers sell processed pulp.. :) EDF operators provide services that are in demand by the market (although some manage to sell canned air of the Alps)

Why so? Electronic document management is not an end in itself, it is a tool. It develops, and the requirements grow the same. Somewhere the requirements are higher, somewhere the ED itself forms the needs. In general, I believe that the state of EDI in Russia is more or less adequate to the requirements of the market.

Sergey, making such a conclusion, I am based on what you wrote above. After all, you are raising the question of the effectiveness of IT tools for the implementation of ED. In addition, the cloud service, as a service sector, is developing quite dynamically and the chances of an electronic signature appearing are a matter of time.

Daily subscription. Other types of subscriptions are available upon registration.

(EP) in the cloud. Basically, this topic is discussed by IT-specialists. However, with the development of electronic document management services (EDF), subject specialists - accountants, secretaries, and others - began to get involved in the topic of cloud ES.

Let me explain, a cloud-based electronic signature implies that your private ES is stored on the server and the signing of documents takes place there. This is accompanied by the conclusion of relevant contracts and powers of attorney. And the actual confirmation of the signer's identity occurs, as a rule, using SMS authorization.

The need to use cloud ES by an accountant depends on the mode in which he works. If you are often out of the office, or, for example, work for a company that provides accounting services (accounting outsourcing), then cloud-based ES will help you sign documents from anywhere. It does not need to install any additional However, despite the ease of use, not all companies are ready to use this feature.

So that you can choose for yourself whether you need a cloud-based electronic signature or not, we will consider all the pros and cons of using it. And also think about who might really need such a signature. By the way, in this article we will only talk about enhanced (hereinafter - UKEP).

Behind

Cloud electronic signature is cheaper than usual. This is mainly due to the fact that you do not need to purchase a cryptographic information protection tool (CIPF) and a token (flash drive with a certificate). As a rule, taking into account their acquisition, the price of the product takes off by 2-2.5 times.

Convenience and ease of use. To work with a cloud-based electronic signature, you do not need to install either the electronic signature certificate itself or special tools for working with it. This means that you will not waste time figuring out how it all works.

Mobility. At the moment, there are no common and free solutions for using a non-cloud electronic signature on mobile devices. In this regard, a huge advantage of a cloud-based electronic signature is that you can work with it from any computer, tablet, smartphone with Internet access.

Against

You do not physically sign the document. You need to understand that in the case of a cloud-based electronic signature, the private part of the key, which is confidential and should belong only to you, will be located on the server of the certification center. Of course, this will be documented, and the servers themselves are securely protected. But here it all depends on the company's security requirements and on the documents associated with signing. If it is important for you that the owners of the private keys themselves sign the documents, then a cloud-based electronic signature will not suit you. In this situation, it is up to you to decide how much you trust the CA and the servers that store the private keys.

You can use cloud-based ES only in those services with which there is integration of the certification center software. This is also due to the fact that in the case of cloud ES, the private key is stored on the CA server. In order for the service you need to be able to use such a private ES key for signing, it needs to be able to send a request for generating an electronic signature to the CA server. It is clear that at the moment there are a lot of services and all of them will not be able to provide integration with software UC. It turns out that you will have to use cloud ES only with certain services. To work with other services, you will have to buy another ES certificate, and there is no way that these services will support any kind of cloud-based electronic signature.

And what?

Cloud electronic signature is a convenient, mobile and simple tool, but not the most flexible. And in terms of security, perhaps storing the private key on a secure server would be better than keeping a token in a drawer.

Who really needs an electronic signature? First of all, those who often work outside their office in the office. For example, auditors who often visit clients. Or and for whom it is important to sign documents anywhere. For them, a cloud-based electronic signature will become an indispensable assistant in their work.

Also, a lot depends on the policy of the company. If an organization moves towards cloud technologies, for example, in terms of storing documents, using services for internal and external document management, then electronic signatures will most likely also be cloud-based. Otherwise, accountants, clerks and other employees who usually do not leave their office during work do not need a cloud-based electronic signature. They can purchase an ES private key and an ES certificate in the usual mode, on a carrier that can be used in most services for exchange with counterparties and government agencies.

Only crypto keys issued with CryptoPro CIPF can be transferred to the cloud.

The transfer is carried out in 2 stages, they are described below.

Checking the EDS for compliance with the requirements

    Open the CryptoPro CSP cryptographic information protection tool (CIPF) control panel ("Start" - "Control Panel" - "CryptoPro CSP") as administrator ("General" tab - "Run as administrator") and go to the "Hardware" tab (Picture 1).

    Figure 1 - Readers setup

    Click the button Set up readers... ". The USB flash drive and floppy disk reader is installed by default when installing the CryptoPro CSP. Check that on the “Readers” tab there is an item “ All removable drives". If the item "All removable drives" is missing, it must be added through the button " Add…” (Figure 2).

    Figure 2 - Managing readers

    Make sure a blank USB flash drive is connected and accessible.

    Go to the "Service" tab and click the " Copy».

    Figure 3 - Tab "Service" button "Copy"

    The Copy Private Key Container window opens.

  1. In the "" window (Figure 3), fill in the "Key container name" field. It can be found in the container lists (button " Review”) or certificates (button “ According to the certificate»).
  2. After the key container is found, click the " Further". If a password is set for access to the private key, it will be requested.

    Enter your password and click the " OK". A window for entering the parameters of the new private key container will open (Figure 4).

    Figure 4 - Window for entering parameters of a new private key container

    The window " Copying the private key container» (Figure 5).

    Figure 5 - Window "Copy private key container"

    Enter the name of the new key container and check the radio button " The entered name specifies the key container» to position « User».

    Click the Done button. A window will open in which you need to select a USB flash drive to place the copied container (Figure 6).


    Figure 6 - Media selection window

    Click the button OK". A window for creating a password for access to the private key container will open (Figure 7).


    Figure 7 - Password entry window

    At this step, you should create a password for the new private key container and confirm it. This password will protect the digital signature, you will need to enter it each time you access it. After entering the required data, click the "OK" button. The cryptographic information protection tool (CIPF) "CryptoPro CSP" will copy the container of the private key to the USB flash drive.

    To copy the EDS public key, launch the Internet Explorer settings panel (“ Start» – « Control Panel» – « Browser Properties» (Figure 8)) and go to the tab « Content» (Figure 9).

    Figure 8 - " Control Panel» – « Browser Properties»


    Figure 9 - " Browser Properties» - « Content» - « Certificates»;

    On the Contents tab, click on the Certificates button. In the "Certificates" window, select the EDS certificate associated with the private key and click the "Export ..." button (Figure 10).

    Figure 10 - Equipment "Certificates"

    The window " Certificate Export Wizard» (Figure 11).

    Figure 11 - Certificate Export Wizard

    In the Certificate Export Wizard window that opens, click the " Further". In the next step, opt out of exporting the private key by checking the " No, do not export the private key” (Figure 12) and click the “Next” button.

    Figure 12 - Selecting the type of keys for export

    In the next step, select the EDS certificate file format by selecting the radio button in the "DER-encoded X.509 (.CER) files" field, and click the " Further» (Figure 13).


    Figure 13 - Selecting the EDS certificate file format

    At the final stage, specify the name and location of the file and click the " Further". At the last step of the wizard, check the selected options and click the " Ready» (Figures 14 and 15).

    Figure 14 - Specifying the save path and the name of the certificate

    Figure 15 - Saving the EDS certificate

    The files obtained as a result of the above manipulations should be placed in a folder and copied to the cloud along the path " W:\EDS". This the folder is accessible only to the main user.

    The result should be something like the following "W: \ EDS \ LLC Test" (Figure 16).

    Figure 16 - EDS copied to the cloud.

    Installation is carried out by experts information security, they work on weekdays from 9 to 18 Moscow time. The application should indicate the name of the folder in which you saved the EDS.

    If your keys are issued using the VipNet CIPF, then they will not work on the terminal farm (via Remote Desktop or RemoteApp). In this case, work can be done on a local PC using a thin client, more about installing and working in .

    If the option of working in a thin client does not suit you, then the EDS should be reissued through CryptoPro, to approve the application for reissuing the certificate, you should contact your service organization.

Back in the last century, many enterprises began to massively switch to electronic document management. Everyone has computers with office programs. Documents were often typed into Microsoft Word or other text editors, exported to PDF, sent by e-mail.

It seemed that if the workflow electronic, then we will soon forget about cabinets with paper archives, not a single sheet of paper will remain on the desktops. If suddenly a paper document is sent to the organization by regular mail, the artifact will be immediately scanned and digitized. In reality, it turned out quite the opposite. It turned out that the more an organization uses computers for digital workflow, the more documents it prints. After all, every document needs to be endorsed. A document without a signature is just a draft or information note. To get a signature, documents are printed out and then often scanned back, keeping the originals in the archive.

It is now clear what really electronic(paperless) workflow cannot be implemented without digital signatures.

Today B2B, B2C companies and state organizations move to the introduction of digital signatures for their undeniable advantages:

  • Paperless workflow. Saving time, money and resources.
  • Effective business processes. Signing in in electronic format makes every transaction a smoother process.
  • Mobile capabilities. Communication within the organization and with customers becomes easier.
Public Key Infrastructure (PKI) provides integrity and confirms authorship each document. Timestamps certify the time a document was signed, which is necessary for time-bound transactions, non-repudiation, and data retention for auditing. Of course, the entire document management system with digital signatures must comply with necessary requirements operating in the country of jurisdiction, as well as in countries where partners and clients work.

Uniform standards for electronic document management and digital signature infrastructure are gradually being developed. For example, in the EU countries, since July 1, 2016, the eIDAS (electronic IDentification, Authentication and trust Services) standard has been in force for electronic services identification, authentication and trust. In the US, the 21 CFR 11 standard has been adopted.

The world's largest trusted services for electronic documents- Adobe Trusted List (AATL) and Microsoft Root Trust program. The CAs included in this list issue certificate-based digital identifiers and timestamp services that comply with global regulations, such as the eIDAS standard. Electronic formats are already supported for the most popular office document formats. digital signatures. Including the signature of the document by several persons, with timestamps is supported.

What is Digital Signing Service (Cloud service of digital signatures)?

Digital Signing Service (DSS) is a scalable API-enabled platform for rapidly deploying digital signatures that provides:

For your own DSS service, you need to set up more than just a signing workflow and user management. Signing certificates are also required to verify the identity of the author of each document. This includes cryptographic elements such as key management, a FIPS level 2 or higher key storage system (such as hardware tokens or HSM), an OCSP or CRL service, and a timestamp service. Combining these components, especially integrating with a hardware security module (HSM) directly, whether in the cloud or on premises, requires significant effort on the part of the IT and information security departments, along with good knowledge of cryptography and the availability of the necessary resources.

It is important to consider these hidden costs and investments, as well as limitations and overheads, when evaluating digital signature solutions.

Separately, it is worth mentioning that if the DSS service is critical to the organization, then it should work with a high level of uptime and provide high throughput. That is, you need to design your solution with a certain amount of redundancy - with a margin for the future. And it should be assumed that business is characterized by growth. The infrastructure must be scalable.

Digital Signing Service Traditional Implementation
Integration with document signing applications Through a simple REST API Requires internal cryptographic expertise for configuration and support
Cryptographic signature components (certificates, OCSP, CRL, timestamps Included in the API, do not require advanced cryptography knowledge or development resources They go separately, require separate calls from applications and internal development resources to configure
Scalability High scalability - not required additional setting or integration Additional equipment purchase and configuration may be required
High availability and disaster recovery Delivered via WebTrust-verified GlobalSign infrastructure with global data centers, redundancy, and the best network security hardware Requires additional investment in equipment
Secret key management and storage Through the REST API, internal resources or equipment not being used The client is responsible for key management and storage (for example, in the cloud or on-premises HSM)
Signing identities Support for signatures of two levels: departments and employees (for example, John Doe, accounting) Not all solutions support both types of identities

The cloud service greatly simplifies the deployment of a document management system with support for digital signatures. All operations simply go through the API.

Cloud services differ in price and functionality. But they all guarantee flexibility, scalability and high level accessibility. Although the services are paid, they relieve companies of the need to invest in the development of their own solutions, including the purchase of expensive cryptographic equipment.

Who might need a cloud-based digital signature service? In theory, these are any organizations of any size that develop or put into operation specially developed applications and intend to either integrate digital signatures there, or use an already integrated application.

  • Providers of document management solutions or applications that wish to integrate digital signatures or seals. Another option: to offer them to customers as a premium option as a guaranteed document protection against forgery. A flexible model is supported here: digital signatures can be added as an additional layer or option.
  • Businesses that want to integrate digital signatures or seals into their workflow.
  • System integrators who implement digital signatures in existing and new document management systems.
Ultimately, it is up to each organization to determine which DSS option is best suited to their project requirements. This takes into account the requirements of regulatory bodies, and the size of the organization, and other factors, often unique in each case.

2023
newmagazineroom.ru - Accounting statements. UNVD. Salary and personnel. Currency operations. Payment of taxes. VAT. Insurance premiums