I am trying to form a key from encrypted components by sending a command to a thales hsm; the command is: Form a Key from Encrypted Components (A4)
'HCONA42001UUF564A40B2E64C84233DFB1289B482496U30CDD5A92A3CACBA19496ECBD134C0E7'
and the response that i get is 'HCONA510' where the 10 indicates component parity error.
Any ideas please?
Most probably because your HSM is not in authorized state.
Related
Db2 allows to set a password in the connection using
SET ENCRYPTION PASSWORD 'mysecretpw'
This avoids having to set the password on each ENCRYPT() / DECRYPT() usage.
However, how can I remove the password after I finished my work so that other parts of code that work with the same connection are not able to use my password ?
I didn't find a 'REMOVE/DROP ENCRYPTION PASSWORD'.
Setting the password to an empty string SET ENCRYPTION PASSWORD ''caused problems when my code was invoked multiple times in the same process: the second invocation got 'NO PASSWORD SET' SQL20143N / SQLSTATE 51039 even though it did set the correct password again using "SET ENCRYPTION PASSWORD 'mysecretpw'" again before using ENCRYPT/DECRYPT ... Db2 also says that you have to specify a password between 6 and 127 bytes ...
Setting an arbitrary string as new password (e.g. blanks) is also not ideal, as this does not allow Db2 to detect 'no password set' conditions so that you don't realize that you are encrypting / decrypting with a wrong password ...
So how to clear the password correctly ?
The Db2 LUW documentation (at version 11.1) for SET ENCRYPTION PASSWORD does not state it explicitly but the product allows you to set the password to an empty string with the result that subsequent encrypt/decrypt actions in that connection will return -20143 sqlcode. When I test this behaviour with the CLP it behaves as expected on Db2 LUW.
So while both Db2 for Z/OS and Db2 for i-series for SET ENCRYPTION PASSWORD explicitly mention the empty string behaviour for the password (and the Db2 LUW knowledge center does not), it appears all three code bases have the same behaviour as regards the consequence of setting the password to the empty string.
If you have a testcase that proves you get an -20143 sqlcode even after using SET ENCRYPTION PASSWORD to a valid good password, then perhaps you should publish that testcase or open a PMR with IBM. If your code is multi threaded , you may get unexpected results as the password is in special register and changing it is not under transaction control, so there may be timing issues.
Removing the password seems to be possible either via disconnecting the session or setting it to an empty string in a single-connection scenario, and with the CLP the product appears to behave as expected for me when I set the password to an empty string, and subsequently set it to a valid password for the same connection.
I am attempting to develop a file encryption function using user entered passphrase. I am studying the example functions at the WiKi here , but don't understand how 'key' and 'iv' exactly work. By experimenting I found out that I only need the same key value to decrypt the file, but NOT the same iv! Indeed I used a random iv string while decrypting, and it decrypts just fine. I plan to generate the key from the sender's passphrase to share it with the file recipient, but I am not sure what to do with iv value? Does it need to be shared with the recipient and used to decrypt, or I can use a randomly generated value, or should I hardcode the value in the program for encryption and decryption? What is 'iv' is used for in this context?
I am trying to decrypt a set of files with GnuPG, for which I already have the username and password. However, I cannot seem to be able to do so, even though I have generated a new key with the given credentials. When trying to run
gpg --output result.sc --decrypt myFile.sc.xz.gpg
I get:
gpg: encrypted with RSA key, ID 3662FD5E
gpg: decryption failed: No secret key
I am wondering, which are the steps in decrypting with GnuPG? I followed the instructions here http://linoxide.com/security/gpg-comand-linux-how-to-encrypt-and-decrypt-file/, but still did not get it to work. I have no other key given except for these credentials.
You're missing the private key with 3662FD5E.
I have no other key given except for these credentials.
Without this key, you cannot decrypt the file. The password you have might protect the private key, but without the private key, there's definitely no way to decrypt the file (unless in future, a way is found to crack the encryption, but as of now, pretty much all relevant and actually used algorithms in OpenPGP are believed to be secure).
even though I have generated a new key with the given credentials
Keys are generated from random numbers, you cannot generate the same key again, also when using the same user ID and password.
I have two clear components, generated by command 000A30303030413230303255 (it's a 000A0000A2002U in HEX mode. This is "GC" - Translate a ZPK from LMK to ZMK Encryption command from 1270A513 Issue 3 manual) using Java code
Now I need to generate an Encrypted key from those components. The console command for it: "FK" command (1270A513 Issue 3, page 5-14).
I couldn't find any commands for doing it by Java code. I used Host Command Reference manual (1270A351 Issue 6) and found only A4- Form a Key from Encrypted Components command, but this command for generating key from Encrypted components.
Is there way to generate encrypted key using clear components?
There is no way to do this and for good reason. If you were to send this via your java code it is open to attack as the clear components are being sent through the network unencrypted. Any person intercepting these components can generate the key themselves. The GC and FK commands are meant to be used with the console and not remotely which is why it is possible using those commands.
If you already have the components you can only form them at the HSM console. If you can possibly generate new keys use the A0 command from your java code.
I don't recommend using this in production. I would take following steps if i really need to do that.
Generate A ZMK(clear and encrypted) on HSM console using 'GC' and 'FK' command.(Need to do only once and reuse key).
use clear ZMK to encrypt all of your keys using TripleDES-ECB-NOPADDING in your application.
Use command 'A6'. Import all ZMK encrypted keys to LMK.
Use 'A4' command to form key using LMK encrypted Components.
I'm working on creating small relay stations out of tiny embedded Linux boxes. They have some sensors connected to them and transport data back to a server via HTTP POST. Right now the server just accepts their message, along with a unique ID (the MAC address of eth0).
I want to expand this to include some type of security. I want to be able to deploy these little devices with minimal configuration. I'd like to copy a base firmware to the device, hook them up in the field, and they self-register. The first time they connect, I'd like the server and device to do some type of negotiation where I can store a fingerprint. Subsequent requests I could then authentication/verify the device using that fingerprint.
That way, once a device registers with its unique ID, I can be assured all data from that ID is from the same device. If a rouge device or set of devices does register, I'll just delete them (I store IPs to so I can delete by unknown ranges and block them).
My question is what's the best way to go about doing this? I think back to the idea of SSH fingerprints, where the first time you connect to a server you get a server fingerprint. If a future request yields a different fingerprint, you get a huge warning and have to manually delete the fingerprint out of your authorized_keys file if the server's keys have actually regenerated (e.g. you did a reinstall without saving your old SSH keys).
Is something like this possibly with HTTP, possibly avoiding having to use preshared keys?
If it matters, the clients are running Python2 and the server they connect to is written mostly in Scala on Tomcat.
Basically, all you need to do is tell the server the public key, and then sign all of your messages with it. If you don't want pre-shared keys, then the server cannot be assured that someone new who is registering is actually one of your devices. You can still validate that the message came from the same device that originally registered with that identifier, however.
The process basically goes like this:
Client generates a new key pair (e.g. an RSA public/private key pair).
Client registers with server, sending its public key. The server stores this public key.
When the client sends a message, it generates a signature of its message, which it attaches to the message. When the server receives the message, it validates the signature to ensure that the message was sent by someone holding the corresponding private key.
The code for this in PyCrypto goes something like this:
Generate key pair
from Crypto.PublicKey import RSA
key = RSA.generate(2048)
private_key = key.exportKey()
public_key = key.publickey().exportKey()
# private_key is a string suitable for storing on disk for retrieval later
# public_key is a string suitable for sending to the server
# The server should store this along with the client ID for verification
Generate signature
from Crypto.PublicKey import RSA
from Crypto.Hash import SHA
key = RSA.importKey(private_key)
# where private_key is read from wherever you stored it previously
digest = SHA.new(message).digest()
signature = key.sign(digest, None)
# attach signature to the message however you wish
The server should load the public key as it has previously stored, and use a "verify" method provided by the Scala/Java crypto API you use, and accept the message only if it succeeds.
It is important to understand the caveats of each approach, as various techniques only protect against certain types of attacks. For instance, the above approach does not protect against a "replay attack", in which an attacker records a message with a certain meaning and then re-transmits it to the server at a later time. One way of protecting against this would be to include a timestamp in the message which is hashed; another would be to use an appropriately encrypted transport (e.g. SSL/TLS).