We don’t wait, but we are preparing for the transition to new standards of cryptographic information protection
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 unambiguously establish its copyright holder through an enhanced electronic signature.
Cryptography makes it possible to close confidential information with prying eyes using encryption.
How to apply cryptography in accordance with the law and with the regulators?
It will be about 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 Generation and Verification of Electronic Digital Signatures”.
The transition is carried out in electronic signature means used for information that does not contain information constituting a state secret, in cases subject to regulation by the FSB of Russia in accordance with the current regulatory legal framework.
First, a brief reference on who and on the basis of what legal documents are regulators in this area.
Federal Law of May 4, 2011 No. 99-ФЗ “On the Licensing of Certain Types of Activities” established a list of activities subject to compulsory licensing.
Decree of the Government of the Russian Federation No. 957 dated November 21, 2011 “ON THE ORGANIZATION OF LICENSING CERTAIN ACTIVITIES” approved the “LIST of FEDERAL AUTHORITIES EXECUTING THE LICENSING OF SPECIFIC ACTIVITIES
that carry out the activities of the RF:
January 31, 2014 the document of the Federal Security Service of Russia No. 149/7/1 / 3-58 “On the procedure for the transition to the use of new digital signature standards and the hash function” is published.
Here I will 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 dated April 16, 2012 No. 313 “On approval of the Regulation on licensing activities for the development, production, distribution of encryption (cryptographic) means, information systems and telecommunication systems protected using encryption (cryptographic) means, performance of work, rendering services in the field of information encryption, maintenance of encryption (cryptographic) means, information systems and telecommunication systems protected using by means of encryption (cryptographic) means (unless the maintenance of encryption (cryptographic) means, information systems and telecommunication systems protected using encryption (cryptographic) means,
The List of work performed and services provided that make up the licensed activity with respect to encryption (cryptographic) means is given.
For example, an item from the list: “2. Development of information systems protected using encryption (cryptographic) means.
In other words, an organization that uses cryptography to interact with the outside world and profit from it must obtain a license and comply with the requirements of the regulator.
Clause 6 of Regulation No. 313 provides licensing requirements for organizations to licensees.
On this with the legal aspects, which are sometimes difficult to read, we will end. And move on to organizational activities.
SEC “Minkomsvyaz” has its own portal - this is a kind of a single entry point into the (Public Key Infrastructure PKI) Public Key Infrastructure on the scale of the Russian Federation. A large list of regulatory documents, requirements and the procedure for accrediting certification centers, a register of operating accredited CAs and information on the availability of their services are published there.
You can also download the XML representation of the registry of accredited
TSL CAs - Trusted List of supervised / accredited Certification Service Providers. This list is electronically signed by the Ministry of Communications, and trust and certification are built through it.
In general, on the site of the State Servicedeployed a single space of the Electronic Government of the Russian Federation. Most of the services, which was made possible thanks to the deployment of national PKI and the use of cryptography and qualified electronic signature.
So, for example, the services of the bus system of the Interagency Electronic Interaction SMEV uses a qualified electronic signature, the public key certificates of which are certified by accredited certification centers of the national PKI.
In light of the foregoing, it was decided to ask the following questions to the Federal Situation Center for Electronic Government (address sd@sc.minsvyaz.ru).
My letter was accepted into the work of the GUT-Voskhod group:
And received the following answers:
I formulated questions regarding the MEEL in a separate letter to the same address and it was routed to the PTK-CMEV group, and then to the Rostelecom PJSC team.
Received this answer:
In general, the CMEA and the XMLDsig / XAdES signature are a separate big topic.
Objectives:
In general, it became clear that it was not necessary to wait for regulators, but to prepare.
Moreover, almost everything you need is at hand. Certified cryptographic information protection tools supporting new algorithms CryptoPro CSP 4.0, Java API CryptoPro JCSP and CryptoPro JCP 2.0 are.
You can generate new keys.
Only a CA was needed in the PKCS # 10 certificate request, to which we can transfer our public key generated by the new algorithm. But more on that later.
CryptoPro regularly posted news on the automatic inclusion of warnings in the CIPI about the upcoming transition to new standards, 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 CIP versions for various operating systems:
Of course, such notifications can be extremely undesirable in information systems. Where they can wedge into the flow, take control and cause the main program logic to fail.
You don’t have to go far for an example. Take the Linux operating system, the Java information system, and the CryptoPro JCP 2.0 provider, through which electronic signature of documents is performed. If you do not turn off timely notifications of the transition to new standards, then an error occurs 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, a warning leads to a crash in the program; a document is not signed.
Of course, for an information system where there is a flow of calls to the provider, start the X Window System server, for example, the Xming program on your station and connect using PuTTY via SSH with the X11 forwarding option enabled so that the CryptoPro JCP client can display all warnings to our station, we will not.
Therefore, we turn off notifications in the control panel of CryptoPro JCP, following the instructions.
If the Java information system uses the cryptographic provider CryptoPro CSP via JavaCSP, then we execute the instruction point:
The corresponding CryptoPro CSP reminders appear when generating keys and a new certificate request in the registration center UI. If you specify the Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider in the Cryptographic Service Provider field.
A window will appear for a new key pair with a warning of the form:
It can be turned off for a month. Or forever for a cryptographic provider, acting on familiar instructions.
CPSI warnings are turned off in time, they can no longer lead to a failure in our information systems.
CryptoPro has its own test certification centers.
At the time of writing, the CA had no support for new standards.
I started a call to the CryptoPro technical support portal
An answer was received:
Now there is a live link to the test CA CryptoPro, supporting GOST 2012.
Help with obtaining certificates was provided by the information security division. An own copy of the test certification center was deployed, supporting GOST 34.10-2012
. Two sets of keys were generated with dimensions of 256 and 512 bits, and two certificates were received that meet the new standards GOST R 34.10-2012, GOST R 34.11-2012.
Let me remind you that as part of CryptoPro JCP you can find many examples in the samples-sources.jar file. In particular, there are examples of signature and verification of electronic documents. Everything else is, by and large, private customizations.
CryptoPro JCP and JCSP providers support the following hash functions and signatures that we need: How to print a list of cryptographic providers that are installed and ready to work in the JVM, their supported functions and implemented algorithms:
In order for existing signature methods in accordance with GOST R 34.10-2001 to begin signing a 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 names for new algorithms:
Initialize the signature object with the desired algorithm:
Add the desired hash function identifier to the created CMS container:
A CMS may contain more than one signature, therefore, the identifiers of hash and signature algorithms are separately indicated for each cycle:
In the same loop we perform hashing:
And here we create the fourth signed attribute containing the hash of the public key certificate for 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 the names of the algorithms and new OIDs.
OIDs and their tree structure are described in the ASN.1 ITU-T X.660 and ISO / IEC 9834 standards. Standards and information, which identifier, which entity is attached 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 2001 algorithms, the information is:
Next, 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:
We create an instance of the hash object according to the specified algorithm in the signature attribute. We need it to recalculate the data hash and compare it with the data passed in the container.
We initialize the object of the Signature class with the corresponding algorithm:
On this, all the nuances of the program transition to the standards of GOST 34.10-2012 and GOST 34.11-2012 are exhausted.
Our software is ready to sign documents and verify signatures according to the new standard with a key dimension of 256 and 512 bits.
This is how the CMS structure looks with the new algorithm identifiers in the ASN1View program ( developer )
- in the ES verification service on the State Service portal
“Document authenticity is not confirmed”, because the certificate was issued in a test CA and E-Government does not know anything about it. EP itself is true.
- using the CryptoArm program
- in our own software
- in the ES verification service on the State Services portal
- using the CryptoArm program in CryptoARM, the
ES verification certificate is considered valid, because I added the root certificate of our test CA to the store of root trusted certificate authorities of my operating system.
- in proprietary software
Cryptography allows us to protect information from spoofing and unambiguously establish its copyright holder through an enhanced electronic signature. Cryptography makes it possible to close confidential information with prying eyes using encryption.
How to apply cryptography in accordance with the law and with the regulators?
It will be about 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 Generation and Verification of Electronic Digital Signatures”.
The transition is carried out in electronic signature means used for information that does not contain information constituting a state secret, in cases subject to regulation by the FSB of Russia in accordance with the current regulatory legal framework.
Legal Aspects
First, a brief reference on who and on the basis of what legal documents are regulators in this area.
Federal Law of May 4, 2011 No. 99-ФЗ “On the Licensing of Certain Types of Activities” established a list of activities subject to compulsory licensing.
Decree of the Government of the Russian Federation No. 957 dated November 21, 2011 “ON THE ORGANIZATION OF LICENSING CERTAIN ACTIVITIES” approved the “LIST of FEDERAL AUTHORITIES EXECUTING THE LICENSING OF SPECIFIC ACTIVITIES
that carry out the activities of the RF:
Development, production, distribution of encryption (cryptographic) means, information systems and telecommunication systems protected using encryption (cryptographic) means, performance of work, provision of services in the field of information encryption, maintenance of encryption (cryptographic) means, information systems and telecommunication systems, protected using encryption (cryptographic) means (unless the maintenance of encryption (cryptographic) of graphic) means, information systems and telecommunication systems, protected with the use of encryption (cryptographic) means, is carried out 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 procedure for the transition to the use of new digital signature standards and the hash function” is published.
Here I will 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 EP means, the technical specifications for the development of which were approved after December 31, 2012, the implementation of the means functions in accordance with GOST R 34.10-2012 should be provided for at least one of the option requirements for parameters defined by the standard (using the option corresponding to the length of the secret key of the order of 256 bits, it is preferable because it provides a sufficient level of cryptographic strength and the best operational characteristics, including when jointly implemented with the GOST R 34.10-2 scheme 001). After December 31, 2013, do not carry out confirmation of the conformity of electronic signature means to the requirements for electronic signature means approved by order of the Federal Security Service of Russia dated 12/27/2011 No. 796, if these funds do not provide for the implementation of the functions of the means in accordance with GOST R 34. 10-2012 for at least one of the standard requirements for parameter requirements. An exception can be made for electronic devices that simultaneously satisfy the following conditions:
- the terms of reference for the development of the tool was approved until December 31, 2012;
- in accordance with the terms of reference, the development of the tool was completed after December 31, 2011;
- confirmation of compliance of the funds with the specified Requirements has not previously been carried out.
The use of the GOST R 34.10-2001 signature scheme for generating a signature after December 31, 2018 is not allowed. ”
Who is this document aimed at?
- it is aimed primarily at licensed cryptographic security developers who certify their cryptographic providers with the FSB.
- to the authorized federal body in the field of the use of electronic signatures and at the same time the Head Certification Authority (GSC), which, in accordance with Federal Law No. 63 “On Electronic Signatures” and Decree of the Government of the Russian Federation No. 976 of 11/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 Signatures”, receive accreditation at the State Telecommunication Center “Minkomsvyaz”
- to organizations, for example, Alfa-Bank, which carry out commercial activities using cryptographic information protection tools.
In the Decree of the Government of Russia dated April 16, 2012 No. 313 “On approval of the Regulation on licensing activities for the development, production, distribution of encryption (cryptographic) means, information systems and telecommunication systems protected using encryption (cryptographic) means, performance of work, rendering services in the field of information encryption, maintenance of encryption (cryptographic) means, information systems and telecommunication systems protected using by means of encryption (cryptographic) means (unless the maintenance of encryption (cryptographic) means, information systems and telecommunication systems protected using encryption (cryptographic) means,
The List of work performed and services provided that make up the licensed activity with respect to encryption (cryptographic) means is given.
For example, an item from the list: “2. Development of information systems protected using encryption (cryptographic) means.
In other words, an organization that uses cryptography to interact with the outside world and profit from it must obtain a license and comply with the requirements of the regulator.
Clause 6 of Regulation No. 313 provides licensing requirements for organizations to licensees.
On this with the legal aspects, which are sometimes difficult to read, we will end. And move on to organizational activities.
Regulator interaction
SEC “Minkomsvyaz” has its own portal - this is a kind of a single entry point into the (Public Key Infrastructure PKI) Public Key Infrastructure on the scale of the Russian Federation. A large list of regulatory documents, requirements and the procedure for accrediting certification centers, a register of operating accredited CAs and information on the availability of their services are published there.
You can also download the XML representation of the registry of accredited
TSL CAs - Trusted List of supervised / accredited Certification Service Providers. This list is electronically signed by the Ministry of Communications, and trust and certification are built through it.
In general, on the site of the State Servicedeployed a single space of the Electronic Government of the Russian Federation. Most of the services, which was made possible thanks to the deployment of national PKI and the use of cryptography and qualified electronic signature.
So, for example, the services of the bus system of the Interagency Electronic Interaction SMEV uses a qualified electronic signature, the public key certificates of which are certified by accredited certification centers of the national PKI.
In light of the foregoing, it was decided to ask the following questions to the Federal Situation Center for Electronic Government (address sd@sc.minsvyaz.ru).
My letter was accepted into the work of the GUT-Voskhod 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 the Hashing Function”, which
states that the use of GOST R 34.10-2001 for generating 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 tell us what kind of work plan is provided for the transfer of infrastructure of the Head Certification Center of the Ministry of Communications of Russia to work with GOST R 34.10-2012, GOST R 34.11-2012
Will they change :
- the root certificate of the State Customs Center of the Ministry of Communications of Russia?
- certificates of PAK UTs 1 IS GUTs and PAK UTs 2 IS GUTs?
- TSLExt1.0.xml signature certificate of a list of accredited CAs?
- (STREET = 125375 Moscow, Tverskaya St., 7, CN = Subsystem “Registries” of IS GUTs, O = Ministry of Communications 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 ?
What is the schedule for changes and work?
Will there be any preliminary announcements on the portal e-trust.gosuslugi.ru ?
What will happen to the old types of CMEE signature?
Will there be a one-time transition to SMEV 3 with a new signature algorithm?
And received the following answers:
Good afternoon!
Due to the fact that from January 1, 2019, the formation of a signature using old guests is not allowed, all certificates used to generate a signature will be replaced.
The transition of the Head Certification Authority to new guests is planned in the first half of 2018, respectively, the certificate of the SEC of the Ministry of Communications of Russia will be replaced at the same time.
Certificates UTs 1 IS GUTs and UTs 2 IS GUTs and the signature certificate TSL are supposed to be replaced at the same time.
The structure of the TSL list is not planned to be changed.
Information about the work on the transition to new guests will be published on sc.minsvyaz.ru and minsvyaz.ru/ru/appeals/faq/66
According to the extract described above, after January 1, 2019, the formation of a signature on old GOSTs is not allowed, i.e., based on it, they can survive, but they cannot be signed. Mandatory revocation of certificates on old GOST is also not planned yet. The accredited CA carries out the transfer of its customers to the new GOSTs independently, as far as possible, it does not provide any general procedure for it.
Regarding SMEV, unfortunately, I can’t tell you, the Head Certification Center is not involved in SMEV. For issues related to it, you need to create a separate application in support of the CMEA.
I formulated questions regarding the MEEL in a separate letter to the same address and it was routed to the PTK-CMEV group, and then to the Rostelecom PJSC team.
Received this answer:
Both types of standards will be supported for some time. The specific date of the work in the MEIS is not defined. Participants in information interaction will be notified in advance with relevant news on the Technology Portal, as well as with all necessary information.
In general, the CMEA and the XMLDsig / XAdES signature are a separate big topic.
Formulation of the problem
Objectives:
- 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 it was not necessary to wait for regulators, but to prepare.
Moreover, almost everything you need is at hand. Certified cryptographic information protection tools supporting new algorithms CryptoPro CSP 4.0, Java API CryptoPro JCSP and CryptoPro JCP 2.0 are.
You can generate new keys.
Only a CA was needed in the PKCS # 10 certificate request, to which we can transfer our public key generated by the new algorithm. But more on that later.
Software uptime
CryptoPro regularly posted news on the automatic inclusion of warnings in the CIPI about the upcoming transition to new standards, 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 CIP versions for various operating systems:
Please note that in connection with the requirements of the FSB of Russia, associated with the prohibition of the use of GOST R 34.10-2001 to generate a signature after January 1, 2019 (see tc26.ru/info/new-national-standards ), from July 1, 2017 CryptoPro CSP versions 3.9 and 4.0, as well as CryptoPro JCP 2.0, warnings will appear about the need for an early transition to GOST R 34.10-2012 when generating keys GOST R 34.10-2001, and from October 1, 2017 - when forming a signature according to GOST R 34.10- 2001. A user with system administrator rights, when starting an application with administrator rights (UAC), can postpone warnings for a month by setting the corresponding flag in this window.
In the event that the appearance of these warnings on your system is undesirable, you can disable them in advance.
Of course, such notifications can be extremely undesirable in information systems. Where they can wedge into the flow, take control and cause the main program logic to fail.
You don’t have to go far for an example. Take the Linux operating system, the Java information system, and the CryptoPro JCP 2.0 provider, through which electronic signature of documents is performed. If you do not turn off timely notifications of the transition to new standards, then an error occurs 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.(Window.java:536)
at java.awt.Frame.(Frame.java:420)
at java.awt.Frame.(Frame.java:385)
at javax.swing.JFrame.(JFrame.java:189)
at ru.CryptoPro.JCP.tools.j.(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, a warning leads to a crash in the program; a document is not signed.
Of course, for an information system where there is a flow of calls to the provider, start the X Window System server, for example, the Xming program on your station and connect using PuTTY via SSH with the X11 forwarding option enabled so that the CryptoPro JCP client can display all warnings to our station, we will not.
Therefore, we turn off notifications in the control panel of CryptoPro JCP, following the instructions.
If the Java information system uses the cryptographic provider CryptoPro CSP via JavaCSP, then we execute the instruction point:
To disable these warnings in CryptoPro CSP before January 1, 2019 on Unix systems, you need to add two keys to the configuration file /etc/opt/cprocsp/config64.ini (or /etc/opt/cprocsp/config.ini in the case of 32-bit systems) into 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 the Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider in the Cryptographic Service Provider field.
A window will appear for a new key pair with a warning of the form:
It can be turned off for a month. Or forever for a cryptographic provider, acting on familiar instructions.
CPSI warnings are turned off in time, they can no longer lead to a failure in our information systems.
Obtaining new certificates
CryptoPro has its own test certification centers.
At the time of writing, the CA had no support for new standards.
I started a call to the CryptoPro technical support portal
Please tell me whether it is planned to transfer the test CA testca2.cryptopro.ru/UI to GOST R 34.10-2012, and if so, in what time frame?
An answer was received:
Planned, no deadlines. Perhaps it will be a different CA.
Now there is a live link to the test CA CryptoPro, supporting GOST 2012.
Help with obtaining certificates was provided by the information security division. An own copy of the test certification center was deployed, supporting GOST 34.10-2012
. Two sets of keys were generated with dimensions of 256 and 512 bits, and two certificates were received that meet the new standards GOST R 34.10-2012, GOST R 34.11-2012.
Signature and Verification
Let me remind you that as part of CryptoPro JCP you can find many examples in the samples-sources.jar file. In particular, there are examples of signature and verification of electronic documents. Everything else is, by and large, private customizations.
CryptoPro JCP and JCSP providers support the following hash functions and signatures that we need: How to print a list of cryptographic providers that are installed and ready to work in the JVM, their supported functions and implemented algorithms:
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
// Распечатка всех криптопровайдеров
try {
for (Provider p : Security.getProviders()) {
LOGGER.info(p.getName() + " - " + p.getInfo());
@SuppressWarnings("unchecked")
ArrayList propNames = (ArrayList) Collections.list(p.propertyNames());
Collections.sort(propNames);
Set services = new TreeSet(new Comparator() {
@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 reversed() {
return null;
}
@Override
public Comparator thenComparing(Comparator arg0) {
return null;
}
@Override
public > Comparator thenComparing(Function arg0) {
return null;
}
@Override
public Comparator thenComparing(Function arg0, Comparator arg1) {
return null;
}
@Override
public Comparator thenComparingDouble(ToDoubleFunction arg0) {
return null;
}
@Override
public Comparator thenComparingInt(ToIntFunction arg0) {
return null;
}
@Override
public Comparator thenComparingLong(ToLongFunction 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 existing signature methods in accordance with GOST R 34.10-2001 to begin signing a 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 names for new algorithms:
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 desired hash function identifier 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, the identifiers of hash and signature algorithms are separately indicated for each cycle:
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 loop we 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 the fourth signed attribute containing the hash of the public key certificate for 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 the names of the algorithms 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");
OIDs and their tree structure are described in the ASN.1 ITU-T X.660 and ISO / IEC 9834 standards. Standards and information, which identifier, which entity is attached 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 2001 algorithms, the information is:
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");
Next, 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);
}
We create an instance of the hash object according to the specified algorithm in the signature attribute. We need it to recalculate the data hash and compare it with the data passed in the container.
MessageDigest digester = MessageDigest.getInstance(new OID(signerInfo.digestAlgorithm.algorithm.value).toString(), config.getProperty(Config.CRYPTO_PROVIDER));We initialize the object of the Signature class with the corresponding 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));
}
On this, all the nuances of the program transition to the standards of GOST 34.10-2012 and GOST 34.11-2012 are exhausted.
Our software is ready to sign documents and verify signatures according to the new standard with a key dimension of 256 and 512 bits.
This is how the CMS structure looks with the new algorithm identifiers in the ASN1View program ( developer )
Signature verification result PKCS-7 GOST R 34.11-2012 / 34.10-2012 256 bit
- in the ES verification service on the State Service portal
“Document authenticity is not confirmed”, because the certificate was issued in a test CA and E-Government does not know anything about it. EP itself is true.
- using the CryptoArm program
- in our own software
Signature verification result PKCS-7 GOST R 34.11-2012 / 34.10-2012 512 bit
- in the ES verification service on the State Services portal
- using the CryptoArm program in CryptoARM, the
ES verification certificate is considered valid, because I added the root certificate of our test CA to the store of root trusted certificate authorities of my operating system.
- in proprietary software
useful links
- Portal of the TECHNICAL COMMITTEE FOR STANDARDIZATION "Cryptographic protection of information"
- Portal SEC "Minkomsvyaz"
- Federal Situation Center for Electronic Government
- CryptoPro technical support portal knowledge base
- OIDs and their tree structure in ASN.1 ITU-T X.660 and ISO / IEC 9834 at oid-info.com
- CryptoPro Test Certification Center
- Verification of certificates and documents with electronic signature on the State Service portal
- Cryptoarm developer site