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.
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.
This is a Paw question. Is there a Paw encryption add-on that supports AES working in the commonly used modes and lengths?
I have a request that includes encrypted fields. These fields are AES encrypted. The key is 128 bits long. The encryption mode is CBC. The encryption is performed by the mobile app. The key is inside the mobile app.
At the moment, I capture the requests in Burp, Import them into Paw, and then I have the valid request.
I know the plaintext. I know the key. I know the algorithm. I know the Initialization Vector. There must be a better way.
I could not find anything on: https://paw.cloud/extensions/
There are two new DynamicValues that should allow you to do what you wish to do:
AES Decrypt
AES Encrypt
They are based on an npm port of the CryptoJS library and should expose most of the API for decryption/encryption in AES.
Here's a couple screenshot to show you what it looks like:
Since the DynamicValues are quite recent, there may be a few issues with them. Don't hesitate to report them.
Is there a way to setup a hierarchical encryption using public key encryption ?
Let's say a higher level user can decrypt messages encrypted by lower level users.
Is it something possible ? I guess it is only possible to do with hierarchical
key management, like the higher level users have access to the lower level user's keys.
Any other option to do something like this ?
What I'd propose is, to some extent, an extension of your hierarchical key management idea.
Here's the core idea:
We use a cryptographically-strong random secret to encrypt the file symetrically (public-key-encryption of large datasets is actually quite slow, so most software like GPG uses a symmetric block cipher to encrypt the data, then they public-key-encrypt the random secret.). The random secret itself is encrypted with the key of each user that is allowed to access the data.
This scheme is similar to when you send a PGP message to multiple receivers. It's quite simple, but the problem is you have to update any encrypted data if users are added, modified or removed. Generally you can introduce intermediary keys to counteract this effect.
In order to address these issues, cryptographers invented HIBE (Hierarchical Identity-Based Encryption). If you want to use this in a real application, please don't build the crypto stack yourself, but use proven, peer-reviewed algorithms.
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.
I need a system to exchange very secret data (source code that is a trade secret). I will use Crypto++ so practically I can use all encryption algorithms, although I really prefer to use an industry standard.
Currently I'm thinking on these methods:
Have the server generate 2048/4096-bit RSA keys, send the public key over to the client, have the client encrypt the data then send it over to the server.
Use a key exchange method like Diffie-Hellman (Diffie-Hellman-Merkle to be correct) to exchange an AES-256 key.
Initiate a TLS connection and tell the server the AES key directly.
Which approach do you believe I should use? I'm not concerned about performance as long as it's reasonable; security is what matters. If none of them, please suggest another method.
P.S.: I might use chaining on the symmetric algorithm, like AES-Twofish-Serpent.
EDIT: Any recommended software must be in a license that won't restrict proprietary usage. LGPL is as restrictive as it must get. That rules out GPL.
Don't develop your own key exchange and/or key provisioning protocol(s). This is what historically breaks most products and, unless you are a cryoptographer (not a programmer with crypto experience), you'll likely get it wrong.
Use off-the-shelf protocols like SSL/TLS. Eg. TLS initialized with RSA keypairs for mutual authentication and AES session keys sounds appropiate for what you describe
Updated
Bruce Schneier:
"A colleague once told me that the world was full of bad security
systems designed by people who read
Applied Cryptography"
erickson in his post has already give you plenty of evidence why designing your own key provisioning and management protocol is flawed. I just want to drive the point home why Mallory is alive and doing quite well, thanks to overconfident developers:
You design the scheme you propose where the client encrypts with a public key and sends the document back to you. Things work great, but 1 year down the road the certificate is approaching expiration. You send an email out to your clients with the new certificate containing the public key you want your users to sign encrypts the documents with for you. Unknown to you is that over the past 4 months your ISP admin has received a bribe to route all your IP traffic through a remote machine. Your email is intercepted before distribution and your attached certificate is replaced with another one. All your clients are now sending their ultra secret documents encryted for someone else's private key. An application decrypts each one, stores it, then encrypts it with your public key and forwards the traffic to you. You won't even know is happening, untill by accident during a visit to a client's site you notice that the certificate he uses is not the one you distributed.
You mention in your post as an option to chain algorithms. Nobody is going to brute force you. Your weakness will be key management, and the attack will take some form of social engineering to fool someone is using the wrong key, or reveling the private key (again, bribes go a long way). Industry agreed protocols have steps to prevent man-in-the-middle attacks, they may rely on PKI infrastructure that recognizes designated key use and trusted authorities, they add certificate revocation list check steps to the validation etc etc. Just 'I encrypt with public key, you decrypt with private' does not make a secret safe.
I'd recommend using an existing S/MIME (or CMS) implementation with a solid cryptographic module to encrypt your content.
S/MIME enveloped data makes a nice format for storage of encrypted data "at rest": the envelope records information about the algorithms and keys used so that the information will be available to authorized recipients later, when it is needed.
Also, even if it doesn't support the "best" algorithms (like ECDH key agreement), a good library is much less likely to have vulnerabilities than something written by a general programmer. Since it is far, far more likely that security will be breached by an implementation error than cryptanalysis, it makes sense to minimize those errors.
In legitimate protocols, public keys are signed by one of a small number of trusted issuers, whose public keys are distributed by some secure means "out-of-band". If you already have a secure means to get a public key to the message sender, why bother sending another? And if you don't, you're screwed.
TLS and S/MIME depend on having a set of well known CA certificates at every client. These are used to sign the server's public key so that a client can detect attempts to substitute keys. The protocol can't bootstrap itself; there must be a secure way to distribute "trust anchors" out-of-band.
Also note that RSA is incredibly slow compared to symmetric ciphers. Real protocols generate a "content encryption key" for a symmetric algorithm like AES, then use an RSA public key as a "key encryption key" to encrypt the content encryption key for the message recipient(s).
So, the main problem is getting your public key to the client securely. If you can do that, either option #1 or #2 is good—assuming that you just use that public key, rather than trying to send another one "in-band". In fact, in CMS, Option #1 is called "key transport", and Option #2 is called "key agreement".
In practice, the "server" could use a certificate issued by a CA that is already well known, or the client can compare a hash of the certificate with one that you tell him over the phone, or carve into the face of a cliff, or whatever. The critical thing is, all of your security depends on the integrity of the certificate. You have to protect it from tampering.
While Crypto++ is an "industry standard", its security depends on how you use it. Just like Jerry told Kramer, "the door must be… closed!" Using the cryptographic primitives in Crypto++ with in a poorly designed protocol will get you nowhere. That's why I'm stressing the use of CMS (a higher-level protocol) together with a good cryptographic module (cryptographic primitives).
What about ssh ? (rsync on ssh for example) ?