Pkcs7 To Jks
Serafin Sonnier
openssl pkcs7 [-inform PEMDER] [-outform PEMDER] [-in filename] [-out filename] [-print_certs] [-text] [-noout] [-engine id]
specifying an engine (by its unique id string) will cause pkcs7 to attempt to obtain a functional reference to the specified engine, thus initialising it if needed. The engine will then be set as the default for all available algorithms.
Well, Andrew, first I noticed there are some pkcs related include files, but only for pkcs5, 11, 12. None for 7. Eventually I grepped all the headers in the Middlewares folder in the project, and pkcs7 did not appear anywhere.
The algorithm used to perform encryption is determined by the current valueof the global ContentEncryptionAlgorithm package variable. By default, thevalue is EncryptionAlgorithmDESCBC. To use a different algorithm, change thevalue before calling Encrypt(). For example:
If truststore is not nil, it also verifies the chain of trust ofthe end-entity signer cert to one of the roots in thetruststore. When the PKCS7 object includes the signing timeauthenticated attr verifies the chain at that time and UTC nowotherwise.
NewSignedData takes data and initializes a PKCS7 SignedData struct that isready to be signed via AddSigner. The digest algorithm is set to SHA1 by defaultand can be changed by calling SetDigestAlgorithm.
AddSignerChain signs attributes about the content and adds certificatesand signers infos to the Signed Data. The certificate and private keyof the end-entity signer are used to issue the signature, and anyparent of that end-entity that need to be added to the list ofcertifications can be specified in the parents slice.
SignWithoutAttr issues a signature on the content of the pkcs7 SignedData.Unlike AddSigner/AddSignerChain, it calculates the digest on the data aloneand does not include any signed attributes like timestamp and so on.
The pkcs7 plugin can be configured in a bolt-project.yaml or bolt-defaults.yaml file. Thisconfiguration applies to using the plugin configuration and inventory, and to running 'bolt secret'commands on the command line. The following values can be configured and apply to each plugin thatuses the value:
The pkcs7::secret_decrypt task is aliased to resolve_reference, letting it be used anywhere that aresolve_reference task can be used such as a bolt.yaml, inventory.yaml, or a plan. To use theplugin, write a plugin reference anywhere you need to decrypt an encrypted value:
NOTE: You must configure the keysize, public_key, and private_key parameters in yourbolt-project.yaml or bolt-defaults.yaml as shown above. Only the --force parameter can bepassed on the command line.
The inspiration of this article comes from the fact that I needed some very efficient way to encrypt a sensitive string before passing it around. I was currently working in C for this part of the project so writing this part in C was awesome as it can be considered efficient on its own. So, I started looking for my options and then it is when I saw this marvelous tiny AES implementation made from kokke. It was undoubtedly what I was looking for, as it supports key lengths of 128/192/256 bits and the CBC mode. The only thing missing was the pkcs7 padding but we will see later how this was dealt with.
The first line #define CBC 1, is mandatory to define the mode we want to use. The rest of the lines are pretty self explanatory, we define the IV to be 16 bytes and then we define our sensitive report to be encrypted with a key. Do note here that neither the report nor the key are multiples of 16 bytes while this is something required due to the way the algorithm works.
In the code above the dlen and the klen hold the length of the report and the key respectively. Now due to we want the report and the key to be multiples of 16 bytes we need to figure out how long both of them will need to be based on their current length. The formula to do that is pretty simple, get the modulo of the length with 16 and then subtract this from 16. The result is how many more bytes we should add to the original length. So the dlenu and the klenu in the code above hold the updated length for the report and they key, which now are multiples of 16 bytes.
The goal now is to have some proper padding, and for this we chose to go for the pkcs7 padding. Before continuing to implement that, lets check if it is already out there --- and it is -- a fork of the original project found here includes the pkcs7 padding we are looking for. The two files we want are the pkcs7_padding.c and the pkcs7_padding.h.
The function we want to use first is the pkcs7_padding_pad_buffer which takes as input the report (char array) along with the original length of the report, it pads the char array and it returns the number of paddings it added.
Two are the most important things to note here, the first is the AES_init_ctx_iv which initializes AES with the key and the IV and the second one is the actual encryption process with the AES_CBC_encrypt_buffer function, which takes the report char array as parameter and it is where it stores the encrypted output as well.
As it was noted by Sarah, the function pkcs7_padding_data_length has a small bug for the cases where the report string is exactly N times the 16 bytes. This is fixed by changed the in line 41 of the file pkcs7_padding.c the returned value to be the buffer_size. Please do note that this is a valid solution given that we will provide as a report string printable characters which will always be higher in value than 16 which is our modulo. You can find the updated file here.
The result of this implementation of AES appeared to be super efficient and works like a charm. In the project I have used it, it serves its purpose perfectly that is why I thought it is something I should share.
Disclaimer: All credits about the implementation of the AES or the PKCS7 padding go to their original authors mentioned in the article. The cryptographic security provided by the above must be validated in all cases.
c80f0f1006