can we utilise a general purpose HSM for EMV related work ? like ARQC/ARPC ? PCI guidelines do not specifically prohibit general purpose HSM from being used. There are certain constraints (e.g. disallow trnslation of ISO Type 0 to Type 1), etc.
But im generally curious - has anyone passed certification of a EMV switch using a general purpose HSM ?
Here's why I think it is possible:
ISO 9564 and TR-31 standards mandate that a few common things like
b) It must prevent the determination of key length for variable length
keys.
c) It must ensure that the key can only be used for a specific
algorithm (such as TDES or AES, but not both).
d) It must ensure a modified key or key block can be rejected prior to use, regardless of the utility of the key after modification. Modification includes changing any bits of the key, as well as the reordering or manipulation of individual single DES keys within a TDES key block
In forthcoming TR-31 regulations, I see that AWS KMS is compliant at the "at-rest integrity checks" using stuff like EncryptionContext and Policy Constraints
so im generally wondering what prevents us from using KMS for this purpose ?
Related
I know KDF (Key derivation function) are used to stretch user passwords, which are basically not suitable to be used as keys in cryptographic algorithms.
But what if I create a random key (random 32 bytes), do I still need to use KDF on it to ensure proper encryption?
A KDF is typically used for deriving cryptographic keys from things like passphrases, which as you correctly say are not suitable for direct use. But they are also used for deriving additional keys from a master key, which depending on your overall scheme, might be useful.
Suppose you used a key agreement protocol where both parties ended up with a random shared secret. You could use a KDF to derive a key for encryption, and one for message integrity (for example, an HMAC key).
From NIST SP800-108:
When parties share a secret symmetric key (e.g., upon a successful
execution of a key- establishment scheme as specified in 1 and
[2]), it is often the case that additional keys will be needed (e.g.
as described in [3]). Separate keys may be needed for different
cryptographic purposes – for example, one key may be required for an
encryption algorithm, while another key is intended for use by an
integrity protection algorithm, such as a message authentication
code. At other times, the distinct keys required by multiple entities
may be generated by a trusted party from a single master key. Key
derivation functions are used to derive such keys.
The short answer is, no, you don't need to use a KDF, assuming your key generation is correct.
I've an idea in my mind but I've no idea what the magic words are to use in Google - I'm hoping to describe the idea here and maybe someone will know what I'm looking for.
Imagine you have a database. Lots of data. It's encrypted. What I'm looking for is an encryption whereby to decrypt, a variable N must at a given time hold the value M (obtained from a third party, like a hardware token) or it failed to decrypt.
So imagine AES - well, AES is just a single key. If you have the key, you're in. Now imagine AES modified in such a way that the algorithm itself requires an extra fact, above and beyond the key - this extra datum from an external source, and where that datum varies over time.
Does this exist? does it have a name?
This is easy to do with the help of a trusted third party. Yeah, I know, you probably want a solution that doesn't need one, but bear with me — we'll get to that, or at least close to that.
Anyway, if you have a suitable trusted third party, this is easy: after encrypting your file with AES, you just send your AES key to the third party, ask them to encrypt it with their own key, to send the result back to you, and to publish their key at some specific time in the future. At that point (but no sooner), anyone who has the encrypted AES key can now decrypt it and use it to decrypt the file.
Of course, the third party may need a lot of key-encryption keys, each to be published at a different time. Rather than storing them all on a disk or something, an easier way is for them to generate each key-encryption key from a secret master key and the designated release time, e.g. by applying a suitable key-derivation function to them. That way, a distinct and (apparently) independent key can be generated for any desired release date or time.
In some cases, this solution might actually be practical. For example, the "trusted third party" might be a tamper-resistant hardware security module with a built-in real time clock and a secure external interface that allows keys to be encrypted for any release date, but to be decrypted only for dates that have passed.
However, if the trusted third party is a remote entity providing a global service, sending each AES key to them for encryption may be impractical, not to mention a potential security risk. In that case, public-key cryptography can provide a solution: instead of using symmetric encryption to encrypt the file encryption keys (which would require them either to know the file encryption key or to release the key-encryption key), the trusted third party can instead generate a public/private key pair for each release date and publish the public half of the key pair immediately, but refuse to disclose the private half until the specified release date. Anyone else holding the public key may encrypt their own keys with it, but nobody can decrypt them until the corresponding private key has been disclosed.
(Another partial solution would be to use secret sharing to split the AES key into the shares and to send only one share to the third party for encryption. Like the public-key solution described above, this would avoid disclosing the AES key to the third party, but unlike the public-key solution, it would still require two-way communication between the encryptor and the trusted third party.)
The obvious problem with both of the solutions above is that you (and everyone else involved) do need to trust the third party generating the keys: if the third party is dishonest or compromised by an attacker, they can easily disclose the private keys ahead of time.
There is, however, a clever method published in 2006 by Michael Rabin and Christopher Thorpe (and mentioned in this answer on crypto.SE by one of the authors) that gets at least partially around the problem. The trick is to distribute the key generation among a network of several more or less trustworthy third parties in such a way that, even if a limited number of the parties are dishonest or compromised, none of them can learn the private keys until a sufficient majority of the parties agree that it is indeed time to release them.
The Rabin & Thorpe protocol also protects against a variety of other possible attacks by compromised parties, such as attempts to prevent the disclosure of private keys at the designated time or to cause the generated private or public keys not to match. I don't claim to understand their protocol entirely, but, given that it's based on a combination of existing and well studies cryptographic techniques, I see no reason why it shouldn't meet its stated security specifications.
Of course, the major difficulty here is that, for those security specifications to actually amount to anything useful, you do need a distributed network of key generators large enough that no single attacker can plausibly compromise a sufficient majority of them. Establishing and maintaining such a network is not a trivial exercise.
Yes, the kind of encrpytion you are looking for exists. It is called timed-release encryption, or abbreviated TRE. Here is a paper about it: http://cs.brown.edu/~foteini/papers/MathTRE.pdf
The following is an excerpt from the abstract of the above paper:
There are nowdays various e-business applications, such as sealedbid auctions and electronic voting, that require time-delayed decryption of encrypted data. The literature oers at least three main categories of protocols that provide such timed-release encryption (TRE).
They rely either on forcing the recipient of a message to solve some time-consuming, non-paralellizable problem before being able to decrypt, or on the use of a trusted entity responsible for providing a piece of information which is necessary for decryption.
I personally like another name, which is "time capsule cryptography", probably coined at crypto.stackoverflow.com: Time Capsule cryptography?.
A quick answer is no: the key used to decrypt the data cannot change in time, unless you decrypt and re-encrypt all the database periodically (I suppose it is not feasible).
The solution suggested by #Ilmari Karonen is the only one feasible but it needs a trusted third party, furthermore, once obtained the master AES key it is reusable in the future: you cannot use 'one time pads' with that solution.
If you want your token to be time-based you can use TOTP algorithm
TOTP can help you generate a value for variable N (token) at a given time M. So the service requesting the access to your database would attach a token which was generated using TOTP. During validation of token at access provider end, you'll validate if the token holds the correct value based on the current time. You'll need to have a Shared Key at both the ends to generate same TOTP.
The advantage of TOTP is that the value changes with time and one token cannot be reused.
I have implemented a similar thing for two factor authentication.
"One time Password" could be your google words.
I believe what you are looking for is called Public Key Cryptography or Public Key Encryption.
Another good word to google is "asymmetric key encryption scheme".
Google that and I'm quite sure you'll find what you're looking for.
For more information Wikipedia's article
An example of this is : Diffie–Hellman key exchange
Edit (putting things into perspective)
The second key can be determined by an algorithm that uses a specific time (for example at the insert of data) to generate the second key which can be stored in another location.
As other guys pointed out One Time Password may be a good solution for the scenario you proposed.
There's an OTP implemented in C# that you might take a look https://code.google.com/p/otpnet/.
Ideally, we want a generator that depends on the time, but I don't know any algorithm that can do that today.
More generally, if Alice wants to let Bob know about something at a specific point in time, you can consider this setup:
Assume we have a public algorithm that has two parameters: a very large random seed number and the expected number of seconds the algorithm will take to find the unique solution of the problem.
Alice generates a large seed.
Alice runs it first on her computer and computes the solution to the problem. It is the key. She encrypts the message with this key and sends it to Bob along with the seed.
As soon as Bob receives the message, Bob runs the algorithm with the correct seed and finds the solution. He then decrypts the message with this key.
Three flaws exist with this approach:
Some computers can be faster than others, so the algorithm has to be made in such a way as to minimize the discrepancies between two different computers.
It requires a proof of work which may be OK in most scenarios (hello Bitcoin!).
If Bob has some delay, then it will take him more time to see this message.
However, if the algorithm is independent of the machine it runs on, and the seed is large enough, it is guaranteed that Bob will not see the content of the message before the deadline.
It is not advisable to store email addresses in databases in plain text, so I would like to find out the best algorithm to do this. Options are:
(From the documentation)
CFMX_COMPAT: the algorithm used in ColdFusion MX and prior releases. This algorithm is the least secure option (default).
AES: the Advanced Encryption Standard specified by the National Institute of Standards and Technology (NIST) FIPS-197.
BLOWFISH: the Blowfish algorithm defined by Bruce Schneier.
DES: the Data Encryption Standard algorithm defined by NIST FIPS-46-3.
DESEDE: the "Triple DES" algorithm defined by NIST FIPS-46-3.
Another questions is where should the key be stored? In the database or in the source code? Will it be encrypted or not? If it will be encrypted, then the question raises of how the key that will encrypt the key be stored.
Should it be stored in the source code, will sourceless distribution be good?
I would use AES. it's the fastest of those listed and the strongest.
As for where to store the key, that is the $64,000 question. You should not put it in the DB (At least not in the same DB as the data it is being used to encipher) or in your source code.
Key management is a beast of a topic. NIST has hundreds of pages of documentation on ways to do it.
http://csrc.nist.gov/groups/ST/toolkit/key_management.html
Key Management involves proper generaton, exchange, storage, rotation, and destruction of keys. You should not use the same key forever (a very common mistake) nor store it improperly.
You should take a look at the NIST guidelines and determine a strategy that works for you and adequately protects your data based on its sensitivity.
Use AES or DESEDE - they're strong and in my experience have a lot of wide compatibility should you need to port this information for some reason.
As for the key, this isn't REAL critical data. Typically you would create a compsite key out of a unique piece of information for that data (like the userId) and a private key (salt) such as a constant in the code base:
Somewhere in your global settings / constants :
<cfset myCodeBaseKey = "NateIsAwesome">
Then when you're ready to encrypt:
<cfset myKey = hash(myCodeBaseKey & user.userId, "SHA")>
P.s. it works better if you use that exact salt phrase I hear. :P~
We've had to extend our website to communicate user credentials to a suppliers website (in the query string) using AES with a 256-bit key, however they are using a static IV when decrypting the information.
I've advised that the IV should not be static and that it is not in our standards to do that, but if they change it their end we would incur the [big] costs so we have agreed to accept this as a security risk and use the same IV (much to my extreme frustration).
What I wanted to know is, how much of a security threat is this? I need to be able to communicate this effectively to management so that they know exactly what they are agreeing to.
*UPDATE:*We are also using the same KEY throughout as well.
Thanks
Using a static IV is always a bad idea, but the exact consequences depend on the Mode of Operation in use. In all of them, the same plaintext will produce the same ciphertext, but there may be additional vulnerabilities: For example, in CFB mode, given a static key, the attacker can extract the cipherstream from a known plaintext, and use it to decrypt all subsequent strings!
Using a static IV is always a bad idea. Using a static key is always a bad idea. I bet that your supplier had compiled the static key into their binaries.
Sadly, I've seen this before. Your supplier has a requirement that they implement encryption and they are attempting to implement the encryption in a manner that's as transparent as possible---or as "checkbox" as possible. That is, they aren't really using encryption to provide security, they are using it to satisfy a checkbox requirement.
My suggestion is that you see if the supplier would be willing to forsake this home-brewed encryption approach and instead run their system over SSL. Then you get the advantage of using a quality standard security protocol with known properties. It's clear from your question that neither your supplier nor you should be attempting to design a security protocol. You should, instead, use one that is free and available on every platform.
As far as I know (and I hope others will correct me if I'm wrong / the user will verify this), you lose a significant amount of security by keeping a static key and IV. The most significant effect you should notice is that when you encrypt a specific plaintext (say usernameA+passwordB), you get the same ciphertext every time.
This is great for pattern analysis by attackers, and seems like a password-equivalent that would give attackers the keys to the kingdom:
Pattern analysis: The attacker can see that the encrypted user+password combination "gobbbledygook" is used every night just before the CEO leaves work. The attacker can then leverage that information into the future to remotely detect when the CEO leaves.
Password equivalent: You are passing this username+password in the URL. Why can't someone else pass exactly the same value and get the same results you do? If they can, the encrypted data is a plaintext equivalent for the purposes of gaining access, defeating the purpose of encrypting the data.
What I wanted to know is, how much of a security threat is this? I need to be able to communicate this effectively to management so that they know exactly what they are agreeing to.
A good example of re-using the same nonce is Sony vs. Geohot (on a different algorithm though). You can see the results for sony :) To the point. Using the same IV might have mild or catastrophic issues depending on the encryption mode of AES you use. If you use CTR mode then everything you encrypted is as good as plaintext. In CBC mode your first block of plaintext will be the same for the same encrypted data.
I have read on wikipedia "However, symmetric ciphers also can be used for non-repudiation purposes by ISO 13888-2 standard."
Then again and I read on another wiki page, "Non-repudiation, or more specifically non-repudiation of origin, is an important aspect of digital signatures. By this property an entity that has signed some information cannot at a later time deny having signed it. Similarly, access to the public key only does not enable a fraudulent party to fake a valid signature. This is in contrast to symmetric systems, where both sender and receiver share the same secret key, and thus in a dispute a third party cannot determine which entity was the true source of the information."
This means one page says symmetric algorithms have non-repudiation and another page says they don't have it and therefore they are not used for digital signatures. So do symmetric keys have non-repudiation or not? It makes sense that they can not be used for signatures and non-repudiation since symmetric keys are the same and thus the system can't distinguish which one belongs to which person and which one is first etc. In that case I think symmetric keys are only a tool for confidentiality and not used for non-repudiation or digital signatures.
As for non-repudiation, the tricky part is that it's not technical but rather legal term and it causes a lot of misunderstanding if placed in technical context. The thing is that you can always repudiate anything you have done. And that's why there are courts.
In the court two parties are confronted and try to prove each other wrong using evidence. Here's where technology comes, as it allows to collect sufficient electronic evidence to prove wrong the party that tries to deny a transaction, message etc.
And this is exactly what ISO 13888 series does in part 1: it provides guidelines on what evidence to collect and how to protect it to maximise your chances of countering a repudiation of electronic transaction. This standard talks about a number of tokens that serve this purpose. These tokens are for example: identifiers of both parties, timestamps, message hashes etc. Then it goes into details on how you should protect these tokens so that they retain their value as evidence.
The two other parts (2 and 3) describe specific cryptographic techniques that can be applied to obtain tokens. Symmetric ones are just keyed hashes if I remember correctly (such as HMAC), while assymetric is digital signature.
I think the answer depends on whether the shared key is public or not. If the parties agree to public source (third party) for their shared key there is non-repudiation of origin.
ISO 13888-2 introduces structures and protocols which can be used to introduce non-repudiation services, in the context of symmetric techniques. However all these "tricks" rely on the existence of a Trusted Third Party.
The point of the second Wikipedia citation in the question is that asymmetric key systems intrinsically [and without the need of thrid parties] offer non-repudiation features (specifically NRO i.e. non-repudation of the the Origin).