Basically in AEM I would want to encrypt some text using AEM CryptoSupport and pass the encrypted key to other system(say ABC system), then the ABC system to decrypt the key to do some action.
AEM can share Adobe Granite Crypto Support 0.0.8 jar to ABC system to do encrypt/decrypt but I wonder how does AEM share HMAC and Master file to other system to decrypt? Is this possible ? Please advise.
You shouldn't have to share the jar with them. AEM CryptoSupport uses AES/CBC/PKCS5Padding for encryption. As long as both systems use a known key and scheme you should be able to encrypt/decrypt without having to use the same jar. AEM Cryptosupport can be used with a key other than the one generated by AEM.
CryptoSupport#encrypt(byte[] key, byte[] plainText)
The way to generate encryption key bytes is by using
CryptoSupport.hmac_256(shared_hash_key, shared_secret)
This allows you to come up with a shared key to use with the other system without having to expose AEMs keys.
To decrypt on the other system use the same hash key and secret. The part after ':' in output from CryptoSupport.encrypt is the IV.
Related
We have a project with a PWA where we want to implement client sided encryption. We wanted to use Webauthn as a second-factor in combination with passwords. In the background we use a randomly generated key to encrypt/decrypt the database, which is stored symmetrically encrypted with the password on the server. However I am struggling to find a good way to add encryption to this key with webauthn. My tries so far:
Using raw JS samples from https://webauthn.guide , however I cannot find a part which is always the same and could be used for symmetric encryption/decryption, even the public key changes when logging in with the same USB token multiple times (???)
Using fido2-lib from npm: I couldn't get the sample to work, since the sample is not well documented and pretty long
Using server-sided authentication like spring webauthn, however I do not want the server to know anything about the client.
Any suggestions how I could implement an encryption with webauthn?
The protocol as it stands does not provide generic public key crypto services as far as I am aware. The best you can do is prove that a user is in possession of the private key related to the public key you hold.
You can learn from the following github repo ,it has many Webauthn out of the box examples (see the tech it supports inside)
Here are some samples I found at github https://github.com/OwnID/samples
In addition,I read about FIDO ,Webauthn and passkeys at passkeys.com
Everything about this cool tech is there
Years after this question, the hmac-secret extension has arrived.
This extension binds a secret to a Webauthn credential. This secret can be used to decrypt or encrypt data on client side.
Another approach could be the use of the largeBlob to store a secret generated during the creation ceremony.
Note that the availability of those extensions depends on the authenticator that is used and may fail.
I use JCManager tool load applets on my java-cards. This software has three fields for authentication keys in the top named S_ENC, S_MAC and DEK.
As I know, ENC stands for Encryption, MAC stands for Message Authentication Code and DEK stands for Data Encryption Key.
I want to know when they used (which step in communication? INITIAL UPDATE , EXTERNAL AUTHENTICATION? ... )?
Does all of these three keys, used in every communications or some of them are optional to use?
and where? (Card or Terminal or both?)
And also, I want to know what is KEK? Is there any KEK in smart cards?
Read the Global Platform Card specifications (registration required) on how the keys are used. The way they are used during authentication differs in the Global Platform specification, so it's better to go straight to the source. For instance E.4.2. of GPC 2.2 specifies:
Generating or verifying an
authentication cryptogram uses the S-ENC session key and the signing method described in appendix
B.1.2.1 - Full Triple DES.
The DEK - or a key derived from the given DEK - is uses for additional encryption of confidential data, such as keys. It would for instance allow for wrapping of keys within a Hardware Security Module, before sending it over the secure message channel (which may not encrypt at all, mind you). For older schemes it was required to also derive a DEK session key, which - paired with the awkward proprietary key derivation - made it near impossible to do so without programming the HSM specifically for Global Platform.
DEK is a more generic term than KEK (Key Encryption Key). I can be used for any data that needs to be kept confidential separate from the transport channel.
Istead of using FormsAuthentication.Encrypt / FormsAuthentication.Decrypt, is it possible to use an existing RSA container in the machine key store to do the encryption/decryption of the ticket.
The reason is that the ASP.Net application I'm developing is meant to be used in multiple load balanced servers. Hence I need to copy the machine key onto all web.config files in all the machines. Since we are already using Asymmetric Encryption (RSA) for another purpose, we have automated installing a common RSA key container in all the servers via a bat file and key container xml. Since this mechanism is in place I want to use the same RSA key container to encrypt/decrypt the forms auth ticket too.
Is this possible? If so how do I override the existing behaviour to achieve this.
If its possible then do you see any disadvantages of using RSA instead of the standard encryption?
Yes, but it would require some work.
You will need to override/replace the standard authentication module that ships with .NET and replicate all the existing functionality with the exception of calls to the RSA Encrypt/Decrypt methods you want to use instead.
See http://msdn.microsoft.com/en-us/library/system.web.security.formsauthentication.encrypt.aspx
You will also need to edit all the standard builtin login pages if you are using those.
As a template, inspect the source for the FormsAuthenticationTicket and you will see how the string is constructed that contains parameters such as UserID, Expiry Date etc, and then pass that string into the Encrypt method, which in turn is then used as the cookie value.
Your new auth module will then have to reverse that encryption and validate the user as before.
It's a fair amount of work for relatively little gain, depends on how badly you want to use RSA over the standard encryption methods used (they already offer some powerful encruyption methods right out the box see http://www.sourcetree.net/sourcetree/Development/Aspnet%20Examples/GenerateMachineKeyForWebConfig.aspx)
I need to encrypt the password the user enters in a text box on the UI, save it, and then decrypt it when the getPassword() method is called.
What is the correct JDK 1.4 API I should use?
Thanks in advance.
If you want to secure you passwords, you'll may want to use a Hash algorithm like MD5 or SHA1. You don't want to decrypt the stored password to compare it with the one provided on a login but rather hash the provided password and compare the Hashs
here some documentation on the methods you can use to hash :
https://www.owasp.org/index.php/Hashing_Java
There's an example here using Java 1.4 Crypto interface for MD5 encryption:
http://download.oracle.com/javase/1.4.2/docs/guide/security/jce/JCERefGuide.html#HmacEx
Blowfish:
http://download.oracle.com/javase/1.4.2/docs/guide/security/jce/JCERefGuide.html#BlowKeyEx
Just use Cipher with the "AES/CBC/PKCS5Padding" mechanism (in getInstance()). You can use a 128 bit (16 byte) AES key created using SecretKeySpec (this is already a key!). Higher bitrates will require unlimited encryption policy files to be installed. As I noted as remark, please note that this is only obscuring the data, since the key will need to be stored with the application - so people that know what to do can retrieve both the password and key and decrypt the information outside of the application.
If you store multiple passwords with the same key, make sure you generate and store a separate random IV per password. The advise in this last paragraph is more to let you know how to encrypt stuff correctly since it is easier to obtain the key than to decrypt the data without it anyway.
I have made a small program that will allow me to send licenses in encrypted form to users.
At the moment I have
An RSA private key that encrypts my AES key
A single AES/CBC key that encrypts the data
An RSA public key
Both the AES and public key are hard coded onto the device.
How should I deal with the IV when a license is requested, should I create a static one on the device or send a new one with every new license I create?
If I understand what you are trying to do then, like most licensing schemes, it is basically a DRM scheme. I'll only address the cryptography problem, but there is also of course the problem of playing hide-and-seek from the hackers. You should know that no DRM scheme offers any measurable security (unless perhaps security hardware is involved) in the cryptographic sense, but they are still common and some developers are comfortable with the logic behind them.
What you want to do is generate your license data and include some information that prevents a user from simply copying a valid license file from a legitimate user. Examples might be mac address, phone number, etc. Then you sign this data. The license then consists of the unencrypted license and the signature bytes. On the user side, your installation software will verify the signature using the hard-coded public key, and perform any other checks (mac address matches, phone number matches, etc).
This would be the core of your scheme, and is enough for most developers. You can take this core and further obfuscate it using ad-hoc including encryption, splitting, etc., depending on how far you want to go with the hide-and-seek game.
EDIT:
If I may make a suggestion, I think the book Beginning Cryptography With Java would be a wise investment. It includes examples that using the Bouncycastle library. You can donwload the examples for free from the same website.
Isn't this proposal totally silly?
You should encrypt with RSA public keys not with a private key. If you encrypt with a private key as you propose then everyone with access to the public key will learn the AES key and will be able to decrypt or forge anything. Of course for the same reason you should also not use the same AES key for distinct receivers.
And to answer the question, you should use a new random IV for each AES/CBC encryption.