We are not waiting, but we are preparing for the transition to new standards of cryptographic protection of information
In the information world and Digital-Bank, it goes without saying - Digital Security and Digital Signature.
Cryptography allows us to protect information from spoofing and unequivocally establish its copyright holder by means of enhanced electronic signature.
Cryptography makes it possible to close confidential information to prying eyes with encryption.
')
How to use cryptography in accordance with the law and in tune with the regulators?
The discussion will deal with legal aspects and organizational and technical measures within the framework of the official transition to national standards in the field of cryptographic information protection GOST R 34.11-2012 "Hashing Function" and GOST R 34.10-2012 "Processes of formation and verification of electronic digital signature".
The transfer is carried out in electronic signature tools used for information that does not contain information constituting state secrets in cases subject to regulation by the Federal Security Service of Russia in accordance with the current regulatory legal framework.
First, a brief reference on who and on the basis of which legal documents are regulators in this field.
The Federal Law of May 4, 2011 No. 99- “ON LICENSING OF INDIVIDUAL TYPES OF ACTIVITY” establishes a list of activities subject to mandatory licensing.
Decree of the Government of the Russian Federation No. 957 dated November 21, 2011 “ON THE ORGANIZATION OF LICENSING SEPARATE TYPES OF ACTIVITY” approved “LIST OF FEDERAL EXECUTIVE AUTHORITY AUTHORITIES IMPLEMENTING LICENSING SPECIFIC ACTIVITIES”
The licensed activities that are supervised by the Federal Security Service of the Russian Federation include:
January 31, 2014 the document of the Federal Security Service of Russia No. 149/7/1 / 3-58 “On the order of transition to the use of new EDS standards and hashing functions” is issued.
Here I allow myself to quote an extract from this document, which is published on the portal of the TECHNICAL COMMITTEE ON STANDARDIZATION "CRYPTOGRAPHIC PROTECTION OF INFORMATION" (TC 26)
Who is this document aimed at?
In the Decree of the Government of Russia of April 16, 2012 No. 313 “On Approval of the Regulation on Licensing of Activities for the Development, Production, Distribution of Encryption (Cryptographic) Means, Information Systems and Telecommunication Systems Protected Using Encryption (Cryptographic) Means, Performance of Works, Rendering services in the field of information encryption, maintenance of encryption (cryptographic) tools, information systems and telecommunication systems protected by encryption (cryptographic) means (except if maintenance of encryption (cryptographic) facilities, information systems and telecommunication systems protected using encryption (cryptographic) facilities is carried out to meet the needs of a legal entity or an individual entrepreneur) ”
A list of work performed and services rendered constituting the licensed activity in relation to encryption (cryptographic) means is given.
For example, the item from the list: “2. Development of encrypted (cryptographic) information systems tools protected
In other words, an organization that uses cryptography, interacts with the outside world and receives a profit from it, must obtain a license and comply with the requirements of the regulator.
Clause 6 of Provision No. 313 provides licensing requirements for organizations of licensees.
On this with legal aspects that are sometimes difficult to read, we finish. And let's move on to organizational measures.
MC “Mincomsvyaz” has its own portal - it is a kind of single entry point into (Public Key Infrastructure PKI) Infrastructure with a public key in the scale of the Russian Federation. A large list of regulatory documents, requirements and accreditation procedures for certification centers, a register of operating accredited CAs and information on the availability of their services are published there.
You can also download an XML-representation of the registry of accredited CAs.
TSL - Trusted List of supervised / accredited Certification Service Providers. This list is signed with the electronic signature of the Ministry of Communications and Mass Media, through which trust and certification paths are built.
In general, a single space of the Electronic Government of the Russian Federation is deployed at the State Services site. Most of the services, which was made possible by the deployment of a national PKI and the use of cryptography and a qualified electronic signature.
For example, in the bus services of the Interdepartmental Electronic Interaction System SMEV, a qualified electronic signature is used, the public key certificates of which are certified by an accredited certification authority of the national PKI.
In the light of the above, it was decided to ask the following questions to the Federal Situational Center of e-government (address sd@sc.minsvyaz.ru).
My letter was accepted into the work of the GTC-Sunrise group:
And received the following answers:
I formulated the questions regarding SMEV in a separate letter to the same address and it was routed to the PTK-SMEV group, and then to the Rostelecom PJSC team.
The following response was received:
In general, SMEV and the XMLDsig / XAdES signature are a separate large topic.
Goals:
In general, it became clear that one should not wait for the regulators, but get ready.
Moreover, almost everything you need is on hand. Certified CRPDs that support the new CryptoPro CSP 4.0 algorithms, the CryptoPro JCSP Java API and the JCP 2.0 CryptoPro.
You can generate new keys.
We only needed the CA in PKCS # 10 certificate request, to which we will be able to transfer our public key generated by the new algorithm. But more on that later.
On the website of CryptoPro, there were regular news about the automatic inclusion of warnings about the impending transition to new standards in the SKPI, at the request of the Federal Security Service of the Russian Federation.
The Knowledge Base of the technical support portal contains detailed information about these warnings, and how to disable them in the versions of the CMIS for various operating systems:
Of course, such notifications can be extremely undesirable in information systems. Where they can break into the stream, take control and cause the main program logic to fail.
For example, no need to go far. Take the Linux operating system, the Java information system and the JCP 2.0 provider CryptoPro, which is used to electronically sign documents. If you do not turn off timely notifications about the transition to a new standard, then an error will occur in the information system when you try to sign a document:
This error says that the provider tried to throw a graphic warning on a server where there is no graphic terminal.
As a result, the warning leads to a crash in the program, the document is not signed.
Of course, for an information system where there is a stream of calls to the provider, launch the X Window System server, for example, the Xming program on your station and connect using PuTTY over SSH with the X11 forwarding option enabled so that the CryptoPro JCP client can display all warnings to our station, we will not.
Therefore, turn off notifications in the control panel of the CryptoPro JCP, following the instructions.
If the information system in Java uses a cryptographic provider of CryptoPro CSP via JavaCSP, then follow the instruction:
The corresponding CryptoPro CSP reminders appear when generating keys and a new certificate request in the registration center UI. If you specify Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider in the Crypto provider field.
For a new key pair, a window will appear with a warning like:
It can be disabled for a month. Or forever for a cryptographic provider, acting on the already familiar instructions.
SKZI warnings are disabled on time, they will no longer be able to crash in our information systems.
CryptoPro has its own test certification centers
At the time of this writing, the TC supporting the new standards was absent.
I started a call to the CryptoPro technical support portal.
The answer was received:
Now there is a live link to the CryptoPro test center, supporting GOST 2012.
Assistance in obtaining certificates was provided by the information security division. An own copy of a test certification center was developed, supporting GOST 34.10-2012
Two sets of keys with dimensions of 256 and 512 bits were generated and two certificates were obtained that meet the new standards GOST R 34.10-2012, GOST R 34.11-2012.
Let me remind you that in the CryptoPro JCP you can find many examples in the sample-sources.jar file. In particular, there are examples of signature and verification of electronic documents. Everything else is largely private customization.
CryptoPro JCP and JCSP providers support the following algorithms, hash functions and signatures we need:
How beautifully to print a list of installed and ready-to-work JVM cryptographic providers, the functions they support, and the algorithms they implement:
In order for the existing signature methods in accordance with GOST R 34.10-2001 to begin to sign the document in accordance with GOST R 34.10-2012, a number of small changes were required.
Consider the example of creating a CMS (PKCS # 7) container.
Add new algorithm names:
Initialize the signature object with the desired algorithm:
Add the hash function to the created CMS container:
A CMS may contain more than one signature, therefore, in the loop for each, the identifiers of the hash and signature algorithms are specified separately:
In the same cycle, perform hashing:
And here we create a fourth sign attribute that contains the hash of the public key certificate verifying this signature
These are all places where you need to specify a new algorithm when signing.
To verify the signature in another class, add algorithm names and new OIDs.
OID identifiers and their tree structure are described in ASN.1 ITU-T X.660 and ISO / IEC 9834 standards. Standards and information which identifier, which entity is bound can be found on oid-info.com
However, identifiers of new algorithms have not yet been added to the Russian segment of OIDs. The transition is only coming. But according to the algorithms of 2001, there is information:
Further, in the signature verification method, we verify that the hash function algorithm specified in the CMS container is familiar to us:
We check the digest and signature algorithms for each signature inside the container:
Create an instance of the hash object by the specified algorithm in the signature attribute. We need it to re-calculate the hash of the data and compare it with the one passed in the container.
Initialize the object of the Signature class with the appropriate algorithm:
That's all the nuances of the software transition to the standards of GOST 34.10-2012 and GOST 34.11-2012 have been exhausted.
Our software is ready to sign documents and verify signatures according to a new standard with a key dimension of 256 and 512 bits.
This is what the CMS structure looks like with new algorithm identifiers in the ASN1View program ( developer )
- in the service of checking electronic signature on the state services portal
“The authenticity of the document is not confirmed” because the certificate is issued in a test CA and the Electronic Government does not know anything about it. The EP itself is correct.
- using CryptoArm
- in own software
- in the service of checking electronic signature on the state services portal
- using CryptoArm
In CryptoARM, an ES verification certificate is considered valid, because I added the root certificate of our test CA to the root trusted certificate authorities of my operating system.
- in own software
Cryptography allows us to protect information from spoofing and unequivocally establish its copyright holder by means of enhanced electronic signature.Cryptography makes it possible to close confidential information to prying eyes with encryption.
')
How to use cryptography in accordance with the law and in tune with the regulators?
The discussion will deal with legal aspects and organizational and technical measures within the framework of the official transition to national standards in the field of cryptographic information protection GOST R 34.11-2012 "Hashing Function" and GOST R 34.10-2012 "Processes of formation and verification of electronic digital signature".
The transfer is carried out in electronic signature tools used for information that does not contain information constituting state secrets in cases subject to regulation by the Federal Security Service of Russia in accordance with the current regulatory legal framework.
Legal aspects
First, a brief reference on who and on the basis of which legal documents are regulators in this field.
The Federal Law of May 4, 2011 No. 99- “ON LICENSING OF INDIVIDUAL TYPES OF ACTIVITY” establishes a list of activities subject to mandatory licensing.
Decree of the Government of the Russian Federation No. 957 dated November 21, 2011 “ON THE ORGANIZATION OF LICENSING SEPARATE TYPES OF ACTIVITY” approved “LIST OF FEDERAL EXECUTIVE AUTHORITY AUTHORITIES IMPLEMENTING LICENSING SPECIFIC ACTIVITIES”
The licensed activities that are supervised by the Federal Security Service of the Russian Federation include:
Development, production, distribution of encryption (cryptographic) means, information systems and telecommunication systems, protected using encryption (cryptographic) means, performance of work, provision of information encryption services, maintenance of encryption (cryptographic) means, information systems and telecommunication systems, protected with the use of encryption (cryptographic) means (with the exception of the case if the maintenance of the encryption (cryp means of information, information systems and telecommunication systems protected using encryption (cryptographic) means, to ensure the own needs of a legal entity or an individual entrepreneur)
January 31, 2014 the document of the Federal Security Service of Russia No. 149/7/1 / 3-58 “On the order of transition to the use of new EDS standards and hashing functions” is issued.
Here I allow myself to quote an extract from this document, which is published on the portal of the TECHNICAL COMMITTEE ON STANDARDIZATION "CRYPTOGRAPHIC PROTECTION OF INFORMATION" (TC 26)
“For ES facilities, the technical task for development of which was approved after December 31, 2012, implementation of the facility functions in accordance with GOST R 34.10-2012 should be provided for at least one of the parameter requirements requirements for parameters defined by the standard (use of the option corresponding to the secret key length about 256 bits, is preferred because it provides a sufficient level of cryptographic security and the best performance, including when implemented jointly with the GOST R 34.10-2 scheme 001). After December 31, 2013, do not carry out confirmation of the conformity of ES facilities with the Requirements for electronic signature facilities approved by order of the FSB of Russia of December 27, 2011 No. 796, if these funds do not provide for the implementation of the instrument’s functions in accordance with GOST 34.10-2012 one of the standard-defined options for parameter requirements. An exception can be made for ES facilities that simultaneously satisfy the following conditions:
- the terms of reference for the development of the tool is approved until December 31, 2012;
- in accordance with the terms of reference, the development of the tool is completed after December 31, 2011;
- confirmation of compliance of the means with the specified Requirements has not previously been carried out
The use of the signature scheme GOST R 34.10-2001 for the formation of a signature after December 31, 2018 is not allowed. "
Who is this document aimed at?
- it is aimed primarily at licensed CIPP developers who certify their cryptographic providers with the FSB.
- to the authorized federal body in the field of electronic signature use and at the same time the Head Certification Center (GTC), which, in accordance with Federal Law No. 63 “On Electronic Signature” and the RF Government Decree No. 976 of November 28, 2011, is the Ministry of Communications and Mass Communications
- to certification centers, which, in accordance with Article 16 of the Federal Law No. 63 "On electronic signature", receive accreditation at the Center for Information and Public Relations "Minkomsvyaz"
- on organizations, for example, Alfa-Bank, which carry out commercial activities with the use of cryptographic protection of information.
In the Decree of the Government of Russia of April 16, 2012 No. 313 “On Approval of the Regulation on Licensing of Activities for the Development, Production, Distribution of Encryption (Cryptographic) Means, Information Systems and Telecommunication Systems Protected Using Encryption (Cryptographic) Means, Performance of Works, Rendering services in the field of information encryption, maintenance of encryption (cryptographic) tools, information systems and telecommunication systems protected by encryption (cryptographic) means (except if maintenance of encryption (cryptographic) facilities, information systems and telecommunication systems protected using encryption (cryptographic) facilities is carried out to meet the needs of a legal entity or an individual entrepreneur) ”
A list of work performed and services rendered constituting the licensed activity in relation to encryption (cryptographic) means is given.
For example, the item from the list: “2. Development of encrypted (cryptographic) information systems tools protected
In other words, an organization that uses cryptography, interacts with the outside world and receives a profit from it, must obtain a license and comply with the requirements of the regulator.
Clause 6 of Provision No. 313 provides licensing requirements for organizations of licensees.
On this with legal aspects that are sometimes difficult to read, we finish. And let's move on to organizational measures.
Regulator interaction
MC “Mincomsvyaz” has its own portal - it is a kind of single entry point into (Public Key Infrastructure PKI) Infrastructure with a public key in the scale of the Russian Federation. A large list of regulatory documents, requirements and accreditation procedures for certification centers, a register of operating accredited CAs and information on the availability of their services are published there.
You can also download an XML-representation of the registry of accredited CAs.
TSL - Trusted List of supervised / accredited Certification Service Providers. This list is signed with the electronic signature of the Ministry of Communications and Mass Media, through which trust and certification paths are built.
In general, a single space of the Electronic Government of the Russian Federation is deployed at the State Services site. Most of the services, which was made possible by the deployment of a national PKI and the use of cryptography and a qualified electronic signature.
For example, in the bus services of the Interdepartmental Electronic Interaction System SMEV, a qualified electronic signature is used, the public key certificates of which are certified by an accredited certification authority of the national PKI.
In the light of the above, it was decided to ask the following questions to the Federal Situational Center of e-government (address sd@sc.minsvyaz.ru).
My letter was accepted into the work of the GTC-Sunrise group:
Hello!
In accordance with the extract from the document of the Federal Security Service of Russia No. 149/7/1 / 3-58 dated January 31, 2014, “On the Procedure for Transitioning to the Use of New EDS Standards and Hash Functions”,
Where it says that the use of GOST R 34.10-2001 for the formation of a signature after December 31, 2018 is not allowed and it is necessary to make the transition to the new standards GOST R 34.10-2012, GOST R 34.11-2012
Please indicate what work plan is envisaged for the transfer of the infrastructure of the Head Certifying Center of the Ministry of Communications and Mass Media of Russia to work with GOST R 34.10-2012, GOST R 34.11-2012
Will change:
- Root certificate of MCC Russia?
- certificates of PAC "TC 1 IS GUTs" and PAK "TC 2 IS GTS"?
- certificate of the TSLExt1.0.xml signature list of accredited CAs?
- (STREET = 125375 Moscow, Tverskaya street, 7, CN = Subsystem "Registries" IS GETs, O = Mincomsvyaz of Russia, L = Moscow, ST = 77 Moscow, C = RU)
- - The structure of the TSL list itself, published on the portal e-trust.gosuslugi.ru/CA/DownloadTSL?schemaVersion=0 ?
When do you plan to make changes and work?
Will there be any preliminary announcements on the e-trust.gosuslugi.ru portal?
What will happen with the old types of signature SMEV?<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr34102001gostr3411"/> </ds:SignedInfo>
Will there be a one-time transition to SMEV 3 with a new signature algorithm?
And received the following answers:
Good day!
Due to the fact that from January 1, 2019, the formation of a signature using the old guests is not allowed, all the certificates used to form the signature will be replaced.
The transition of the Head Certification Center to new guests is planned in the first half of 2018, respectively, the certificate of the State Registration Center of the Ministry of Communications and Mass Media of Russia will be replaced at the same time.
CA 1 TC and TC 2 CA IS certificates and the TSL signature certificate are expected to be replaced at the same time.
The structure of the TSL list is not planned to change.
Information about the work on the transition to the new guests will be published on the page sc.minsvyaz.ru and minsvyaz.ru/ru/appeals/faq/66
According to the above statement, after January 1, 2019, the formation of signatures on the old GOST is not allowed, that is, on the basis of it, they can live, but they cannot sign. Mandatory revocation of certificates on the old GOST is also not planned. The transfer of its customers to new GOST accredited TC independently implements, to the best of their abilities, no general procedure for it is provided for.
According to SMEV, unfortunately, I can’t give a hint, the Head Certification Authority doesn’t deal with SMEV. For questions related to it, you need to create a separate application in support of SMEV.
I formulated the questions regarding SMEV in a separate letter to the same address and it was routed to the PTK-SMEV group, and then to the Rostelecom PJSC team.
The following response was received:
For a while, both types of standards will be supported. The specific date of work in the SMEV is not defined. Participants of information interaction will be notified in advance of the relevant news on the Technology Portal, as well as all the necessary information.
In general, SMEV and the XMLDsig / XAdES signature are a separate large topic.
Formulation of the problem
Goals:
- to ensure the smooth operation of their own software during the transition period.
- generate new keys and certificates
- check the software for the possibility of a correct transition. To do this, sign the document with a new electronic signature and verify it.
In general, it became clear that one should not wait for the regulators, but get ready.
Moreover, almost everything you need is on hand. Certified CRPDs that support the new CryptoPro CSP 4.0 algorithms, the CryptoPro JCSP Java API and the JCP 2.0 CryptoPro.
You can generate new keys.
We only needed the CA in PKCS # 10 certificate request, to which we will be able to transfer our public key generated by the new algorithm. But more on that later.
Software uptime
On the website of CryptoPro, there were regular news about the automatic inclusion of warnings about the impending transition to new standards in the SKPI, at the request of the Federal Security Service of the Russian Federation.
The Knowledge Base of the technical support portal contains detailed information about these warnings, and how to disable them in the versions of the CMIS for various operating systems:
Please note that due to the requirements of the Federal Security Service of Russia, associated with the prohibition of the use of GOST R 34.10-2001 for the formation of a signature after January 1, 2019 (see tc26.ru/info/new-national-standards ), from July 1, 2017 in CryptoPro CSP versions 3.9 and 4.0, as well as CryptoPro JCP 2.0 will appear warnings about the need for a quick transition to GOST R 34.10-2012 when generating keys of GOST R 34.10-2001, and since October 1, 2017 - and when forming a signature according to GOST R 34.10- 2001. A user with system administrator rights can launch a warning for a month when launching an application with administrator rights (UAC) by setting the corresponding flag in this window.
In case the appearance of these warnings on your system is undesirable, you can turn them off in advance.
Of course, such notifications can be extremely undesirable in information systems. Where they can break into the stream, take control and cause the main program logic to fail.
For example, no need to go far. Take the Linux operating system, the Java information system and the JCP 2.0 provider CryptoPro, which is used to electronically sign documents. If you do not turn off timely notifications about the transition to a new standard, then an error will occur in the information system when you try to sign a document:
ERROR: java.awt.HeadlessException: No X11 DISPLAY variable was set, but this program performed an operation which requires it. at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:204) at java.awt.Window.<init>(Window.java:536) at java.awt.Frame.<init>(Frame.java:420) at java.awt.Frame.<init>(Frame.java:385) at javax.swing.JFrame.<init>(JFrame.java:189) at ru.CryptoPro.JCP.tools.j.<init>(Unknown Source) at ru.CryptoPro.JCP.tools.Gost2001Warning.warn(Unknown Source) at ru.CryptoPro.JCP.Sign.a.engineInitSign(Unknown Source) at java.security.Signature.initSign(Signature.java:527) at ru.CryptoPro.JCPxml.xmldsig.SignatureGostR3410.engineInitSign(Unknown Source) at org.apache.xml.security.algorithms.SignatureAlgorithm.initSign(SignatureAlgorithm.java:238) at org.apache.xml.security.signature.XMLSignature.sign(XMLSignature.java:591) This error says that the provider tried to throw a graphic warning on a server where there is no graphic terminal.
As a result, the warning leads to a crash in the program, the document is not signed.
Of course, for an information system where there is a stream of calls to the provider, launch the X Window System server, for example, the Xming program on your station and connect using PuTTY over SSH with the X11 forwarding option enabled so that the CryptoPro JCP client can display all warnings to our station, we will not.
Therefore, turn off notifications in the control panel of the CryptoPro JCP, following the instructions.
If the information system in Java uses a cryptographic provider of CryptoPro CSP via JavaCSP, then follow the instruction:
To disable these warnings in the CryptoPro CSP before January 1, 2019 on Unix systems, you need to add two keys to the /etc/opt/cprocsp/config64.ini configuration file (or /etc/opt/cprocsp/config.ini in the case of 32-bit systems) to the existing Parameters section:
The corresponding CryptoPro CSP reminders appear when generating keys and a new certificate request in the registration center UI. If you specify Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider in the Crypto provider field.
For a new key pair, a window will appear with a warning like:
It can be disabled for a month. Or forever for a cryptographic provider, acting on the already familiar instructions.
SKZI warnings are disabled on time, they will no longer be able to crash in our information systems.
Obtaining new certificates
CryptoPro has its own test certification centers
At the time of this writing, the TC supporting the new standards was absent.
I started a call to the CryptoPro technical support portal.
Tell me, please, is it planned to transfer test CA testca2.cryptopro.ru/UI to GOST R 34.10-2012 and if so, in what time frame?
The answer was received:
It is planned, the dates are not defined. Perhaps it will be another CA.
Now there is a live link to the CryptoPro test center, supporting GOST 2012.
Assistance in obtaining certificates was provided by the information security division. An own copy of a test certification center was developed, supporting GOST 34.10-2012
Two sets of keys with dimensions of 256 and 512 bits were generated and two certificates were obtained that meet the new standards GOST R 34.10-2012, GOST R 34.11-2012.
Document signature and verification
Let me remind you that in the CryptoPro JCP you can find many examples in the sample-sources.jar file. In particular, there are examples of signature and verification of electronic documents. Everything else is largely private customization.
CryptoPro JCP and JCSP providers support the following algorithms, hash functions and signatures we need:
JCSP - CryptoPro Java CSP Provider
JCP - CryptoPro Java Provider
MessageDigest - GOST3411_2012_256
MessageDigest - GOST3411_2012_512
Signature - GOST3411_2012_256withGOST3410DH_2012_256
Signature - GOST3411_2012_512withGOST3410DH_2012_512
How beautifully to print a list of installed and ready-to-work JVM cryptographic providers, the functions they support, and the algorithms they implement:
// try { for (Provider p : Security.getProviders()) { LOGGER.info(p.getName() + " - " + p.getInfo()); @SuppressWarnings("unchecked") ArrayList<String> propNames = (ArrayList<String>) Collections.list(p.propertyNames()); Collections.sort(propNames); Set<Service> services = new TreeSet<Service>(new Comparator<Service>() { @Override public int compare(Service s1, Service s2) { int res = s1.getType().compareTo(s2.getType()); if (res == 0) { res = s1.getAlgorithm().compareTo(s2.getAlgorithm()); } return res; } @Override public Comparator<Service> reversed() { return null; } @Override public Comparator<Service> thenComparing(Comparator<? super Service> arg0) { return null; } @Override public <U extends Comparable<? super U>> Comparator<Service> thenComparing(Function<? super Service, ? extends U> arg0) { return null; } @Override public <U> Comparator<Service> thenComparing(Function<? super Service, ? extends U> arg0, Comparator<? super U> arg1) { return null; } @Override public Comparator<Service> thenComparingDouble(ToDoubleFunction<? super Service> arg0) { return null; } @Override public Comparator<Service> thenComparingInt(ToIntFunction<? super Service> arg0) { return null; } @Override public Comparator<Service> thenComparingLong(ToLongFunction<? super Service> arg0) { return null; } }); services.addAll(p.getServices()); for (Service s : services) { LOGGER.info(" " + s.getType() + " - " + s.getAlgorithm()); } } } catch (Exception e) { throw new RuntimeException(e); } In order for the existing signature methods in accordance with GOST R 34.10-2001 to begin to sign the document in accordance with GOST R 34.10-2012, a number of small changes were required.
Consider the example of creating a CMS (PKCS # 7) container.
Add new algorithm names:
private static final String GOST3411_2012_256 = "GOST3411_2012_256"; private static final String GOST3411_2012_256WITH_GOST3410DH_2012_256 = "GOST3411_2012_256withGOST3410DH_2012_256"; private static final String GOST3411_2012_512 = "GOST3411_2012_512"; private static final String GOST3411_2012_512WITH_GOST3410DH_2012_512 = "GOST3411_2012_512withGOST3410DH_2012_512"; Initialize the signature object with the desired algorithm:
Signature signature = Signature.getInstance(GOST3411_2012_512WITH_GOST3410DH_2012_512,config.getProperty(Config.CRYPTO_PROVIDER)); Add the hash function to the created CMS container:
final DigestAlgorithmIdentifier digestAlgorithmIdentifier = new DigestAlgorithmIdentifier(new OID(JCP.GOST_DIGEST_2012_512_OID).value); digestAlgorithmIdentifier.parameters = new Asn1Null(); cms.digestAlgorithms.elements[0] = digestAlgorithmIdentifier; A CMS may contain more than one signature, therefore, in the loop for each, the identifiers of the hash and signature algorithms are specified separately:
for (int i = 0; i < cms.signerInfos.elements.length; i++) { cms.signerInfos.elements[i].digestAlgorithm = new DigestAlgorithmIdentifier(new OID(JCP.GOST_DIGEST_2012_512_OID).value); cms.signerInfos.elements[i].digestAlgorithm.parameters = new Asn1Null(); cms.signerInfos.elements[i].signatureAlgorithm = new SignatureAlgorithmIdentifier( new OID(JCP.GOST_PARAMS_SIG_2012_512_KEY_OID).value); cms.signerInfos.elements[i].signatureAlgorithm.parameters = new Asn1Null(); In the same cycle, perform hashing:
messageDigestBlob = calculateDigestm(data, GOST3411_2012_512, config.getProperty(Config.CRYPTO_PROVIDER)); final Asn1Type messageDigest = new Asn1OctetString(messageDigestBlob); cms.signerInfos.elements[i].signedAttrs.elements[k].values.elements[0] = messageDigest; And here we create a fourth sign attribute that contains the hash of the public key certificate verifying this signature
cms.signerInfos.elements[i].signedAttrs.elements[k] = new Attribute( new OID(ALL_PKIX1Explicit88Values.id_aa_signingCertificateV2).value, new Attribute_values(1)); // , // // . final DigestAlgorithmIdentifier a = new DigestAlgorithmIdentifier(new OID(JCP.GOST_DIGEST_2012_512_OID).value); // . final CertHash certHash = new CertHash(calculateDigestm(certificateList.get(i).getEncoded(), GOST3411_2012_512, config.getProperty(Config.CRYPTO_PROVIDER))); // Issuer name . GeneralName generalName = new GeneralName(); generalName.set_directoryName(name); GeneralNames generalNames = new GeneralNames(); generalNames.elements = new GeneralName[1]; generalNames.elements[0] = generalName; // . IssuerSerial issuerSerial = new IssuerSerial(generalNames, num); ESSCertIDv2 essCertIDv2 = new ESSCertIDv2(a, certHash, issuerSerial); _SeqOfESSCertIDv2 essCertIDv2s = new _SeqOfESSCertIDv2(1); essCertIDv2s.elements = new ESSCertIDv2[1]; essCertIDv2s.elements[0] = essCertIDv2; // . SigningCertificateV2 signingCertificateV2 = new SigningCertificateV2(essCertIDv2s); cms.signerInfos.elements[i].signedAttrs.elements[k].values.elements[0] = signingCertificateV2; These are all places where you need to specify a new algorithm when signing.
To verify the signature in another class, add algorithm names and new OIDs.
private static final String GOST3411_2012_256WITH_GOST3410DH_2012_256 = "GOST3411_2012_256withGOST3410DH_2012_256"; private static final String GOST3411_2012_512WITH_GOST3410DH_2012_512 = "GOST3411_2012_512withGOST3410DH_2012_512"; private static final OID OID_ALG_DIGEST_GOST_2012_256 = new OID("1.2.643.7.1.1.2.2"); private static final OID OID_ALG_SIGN_GOST_2012_256 = new OID("1.2.643.7.1.1.1.1"); private static final OID OID_ALG_DIGEST_GOST_2012_512 = new OID("1.2.643.7.1.1.2.3"); private static final OID OID_ALG_SIGN_GOST_2012_512 = new OID("1.2.643.7.1.1.1.2"); OID identifiers and their tree structure are described in ASN.1 ITU-T X.660 and ISO / IEC 9834 standards. Standards and information which identifier, which entity is bound can be found on oid-info.com
However, identifiers of new algorithms have not yet been added to the Russian segment of OIDs. The transition is only coming. But according to the algorithms of 2001, there is information:
private static final OID OID_S_ALG_DIGEST_GOSTBC = new OID("1.2.643.2.2.9"); private static final OID OID_S_ALG_SIGN_GOSTBC = new OID("1.2.643.2.2.19"); Further, in the signature verification method, we verify that the hash function algorithm specified in the CMS container is familiar to us:
if ((!signedData.digestAlgorithms.elements[0].algorithm.equals(new Asn1ObjectIdentifier(new OID(OID_S_ALG_DIGEST_GOSTBC).value))) && (!signedData.digestAlgorithms.elements[0].algorithm.equals(new Asn1ObjectIdentifier(new OID(OID_ALG_DIGEST_GOST_2012_256).value))) && (!signedData.digestAlgorithms.elements[0].algorithm.equals(new Asn1ObjectIdentifier(new OID(OID_ALG_DIGEST_GOST_2012_512).value)))) { throw new SignatureVerificationException("Unexpected SignedData digest algorithm: " + signedData.digestAlgorithms.elements[0].algorithm); } We check the digest and signature algorithms for each signature inside the container:
for (ru.CryptoPro.JCP.ASN.CryptographicMessageSyntax.SignerInfo signerInfo : signedData.signerInfos.elements) { SignatureVerificationResult svr = new SignatureVerificationResult(); result.getSignatureVerificationResultList().add(svr); //TODO if ((!signerInfo.digestAlgorithm.algorithm.equals(new Asn1ObjectIdentifier(new OID(OID_S_ALG_DIGEST_GOSTBC).value))) && (!signedData.digestAlgorithms.elements[0].algorithm.equals(new Asn1ObjectIdentifier(new OID(OID_ALG_DIGEST_GOST_2012_256).value))) && (!signedData.digestAlgorithms.elements[0].algorithm.equals(new Asn1ObjectIdentifier(new OID(OID_ALG_DIGEST_GOST_2012_512).value)))) { throw new SignatureVerificationException("Unexpected digest algorithm: " + signerInfo.digestAlgorithm.algorithm); } if ((!signerInfo.signatureAlgorithm.algorithm.equals(new Asn1ObjectIdentifier(new OID(OID_S_ALG_SIGN_GOSTBC).value))) && (!signerInfo.signatureAlgorithm.algorithm.equals(new Asn1ObjectIdentifier(new OID(OID_S_ALG_CADES).value))) && (!signerInfo.signatureAlgorithm.algorithm.equals(new Asn1ObjectIdentifier(new OID(OID_S_ALG_DIGEST_GOSTBC).value))) && (!signerInfo.signatureAlgorithm.algorithm.equals(new Asn1ObjectIdentifier(new OID(OID_ALG_SIGN_GOST_2012_256).value))) && (!signerInfo.signatureAlgorithm.algorithm.equals(new Asn1ObjectIdentifier(new OID(OID_ALG_SIGN_GOST_2012_512).value)))) { throw new SignatureVerificationException("Unexpected signature algorithm: " + signerInfo.signatureAlgorithm.algorithm); } Create an instance of the hash object by the specified algorithm in the signature attribute. We need it to re-calculate the hash of the data and compare it with the one passed in the container.
MessageDigest digester = MessageDigest.getInstance(new OID(signerInfo.digestAlgorithm.algorithm.value).toString(), config.getProperty(Config.CRYPTO_PROVIDER)); Initialize the object of the Signature class with the appropriate algorithm:
Signature signature = null; if (signerInfo.signatureAlgorithm.algorithm.equals(new Asn1ObjectIdentifier(new OID(OID_ALG_SIGN_GOST_2012_256).value))) { signature = Signature.getInstance(GOST3411_2012_256WITH_GOST3410DH_2012_256, config.getProperty(Config.CRYPTO_PROVIDER)); } else if (signerInfo.signatureAlgorithm.algorithm.equals(new Asn1ObjectIdentifier(new OID(OID_ALG_SIGN_GOST_2012_512).value))) { signature = Signature.getInstance(GOST3411_2012_512WITH_GOST3410DH_2012_512, config.getProperty(Config.CRYPTO_PROVIDER)); } else { signature = Signature.getInstance(GOST3411WITH_GOST3410DHEL, config.getProperty(Config.CRYPTO_PROVIDER)); } That's all the nuances of the software transition to the standards of GOST 34.10-2012 and GOST 34.11-2012 have been exhausted.
Our software is ready to sign documents and verify signatures according to a new standard with a key dimension of 256 and 512 bits.
This is what the CMS structure looks like with new algorithm identifiers in the ASN1View program ( developer )
The result of verification of the signature PKCS-7 GOST R 34.11-2012 / 34.10-2012 256 bits
- in the service of checking electronic signature on the state services portal
“The authenticity of the document is not confirmed” because the certificate is issued in a test CA and the Electronic Government does not know anything about it. The EP itself is correct.
- using CryptoArm
- in own software
The result of verification of the signature PKCS-7 GOST R 34.11-2012 / 34.10-2012 512 bits
- in the service of checking electronic signature on the state services portal
- using CryptoArm
In CryptoARM, an ES verification certificate is considered valid, because I added the root certificate of our test CA to the root trusted certificate authorities of my operating system.
- in own software
useful links
- TECHNICAL COMMITTEE ON STANDARDIZATION "CRYPTOGRAPHIC PROTECTION OF INFORMATION" Portal
- Portal of the MC “Mincomsvyaz”
- Federal Situational Center for e-government
- Knowledge base of the CryptoPro technical support portal
- OIDs and their tree structure in ASN.1 ITU-T X.660 and ISO / IEC 9834 standards at oid-info.com
- Test certification center CryptoPro
- Verification of certificates and documents with electronic signature on the State Services portal
- Website developer CryptoArm
Source: https://habr.com/ru/post/341476/
All Articles