This video claims to be able to generate a key pair directly on the Smartcard so the private key never leaves the card. Is this operation common to all smartcards, or do only select smartcards support this?
Most cryptographic smart cards are able to generate keys in the card in addition to storing externally generated plaintext keys, that's the main purpose of cryptographic smart cards.
Some cards don't allow importing plaintext keys, some allow exporting keys generated on the card, some card can do import/export of wrapped (encrypted with another key) private keys, so that the actual private key would never be in clear in an untrusted environment.
Have a look at http://www.opensc-project.org for a further pointers on cards and software.
A smartcard is just a chip on a card, so you probably want to ask about cryptographic smart cards.
I have never worked with cryptographic smart cards but that sounds like a completely reasonable functionality of such smartcards since they are intended usually for authentication and encryption which usally use private keys for that.
The advantage of cryptographic smart cards usually lies in that, that the private key is stored in it. That is intended to prevent the compromise of the keys because even if the computer, that reads the smartcard, is compromised the smartcard is safe and the private key is safe too.
this is called on-board key generation, indeed the card generates itself the keys and the private key will never leave the smartcard, besides of the key marked as not exportable, the card itself is unable to export it, it has no function, no knowledge how to do this.
many smartcards ( of course with a cryptoprocessor ) support this but not all and anyway this is an expensive feature. Most smartcard vendors sell such cards.
Related
I see a lot of videos showing withdrawals from ATMs with cloned EMV cards like code 201 so
how can be possible when a card uses DDA (dynamic keys) another question is cloned card just for magstripe because it is unencrypted or even EMV chip
It is a question that does not really belong to SO and due to the nature of what you are asking about, you may not receive a detailed answer. I will still try.
First of all, ATMs are online-only devices that do not need any form of Offline Data Authentication so DDA has little to do with them normally (there are exceptions from this rule, as usual).
There are still dynamic keys that are meant to provide security, nevertheless. A standard symmetric-key algorithm is used to generate online cryptogram and it is validated by the issuer. Symmetric keys are individual to each specific card and are not easily extracted (of course, nothing can be ever treated as 100% secure, but it would require a complex hardware attack to extract keys from a single card).
I assume your question about Service code 2xx, 5xx or 6xx is mostly revolving around magstripe data with no chip data available. In some situations (i.e. when card is mute) a fallback to magstripe transaction may happen. Normally, unattended devices should have this option blocked and decline such attempts but I would not bet there are no such devices around the world. You also need to consider that there are still devices that are not EMV-capable.
When it comes to magstripe data, they can be easily modified (for instance changing the service code) although such modification should be detectable. Same goes for using EMV track equivalent data on magstripe. In both cases, issuer is capable of detecting modification of the data or using it on different interface through the use of CVC/CVV which is encoded on a track and is created to cryptographically protect integrity of the track data. However, this requires to have proper implementation on the issuer side to detect and decline such attempts where cryptographic data from CVV or cryptogram are incorrect.
First, I want to apologize. I am complete noob in this area and many of my thoughts are probably misleading.
I need to verify that a user of my app is on a specific place in order to be authirized to perform an action. I want to use NFC for this purpose. The user have to put his smartphone by a NFC tag in order to be authorized to perform the action. Easy but I need it to be reasonably hackerproof. It means that the NFC tag must be impossible to clone without physical damage to the plastics around the NFC chip. It also means that the NFC chip must not contain only static data. The NFC chip must contain an app, that can receive some data (cryptographic challenge) and signs them using secure built-in private key (which must be unreadable through NFC interface). When the user wants to perform the action, he will ask server for the challenge, then he lets the chip to sign it, and then he sends the signed challenge back to the server which will verify the signature using known public key. This should be achievable using NFC JavaCard. But do these NFC JavaCards actually exist? I wasn't able to find a company which would be able to produce such NFC tags for me. When I try to explain my requirements to a NFC tags producer he looks like he has never heard of NFC JavaCards. I have tried about 10 producers without luck.
Can a commonly available chip meet my requirements? I mean a chip from the Mifare familly. I suspect that Mifare DESfire might be able to meet my requirements, but I am not sure.
Feel free to respond with an advertisement, because relevant advertisement is exactly what I look for :)
I try to collect some useful facts:
NFC is a very broad term, just finding that on both sides does not ensure interoperability.
Any ISO 14443 (one of the NFC flavours) compliant smart card with crypto functionality should be usable. Note, that a card with native OS may be a viable alternative to a JavaCard, since the functionality to sign a random number is pretty standard.
Any smart phone sporting a NFC chip can address such a card in principle. Unfortunately this is strongly dependent on the OS of the smart phone, for Android the relevant class to use is IsoDep, which gives you the APDU interface. After triggering the "card enters field" event, then the app receives a handle, via which further communication can take place.
Real smart cards can't be cloned, since you are not able to dump them; especially keys can't be read.
Now some things to consider:
Your approach looks unusual, which might become a problem. (To have a portable card somehow fixed to a wall, just to get the location; so you know where somebody is, but not who? While I don't consider cloning to be an issue, you somehow must ensure destruction in case of a theft attempt, which may collide with the distance topic below.)
I don't see, where the server comes into play. If not involved in the authorized action, provision of a random number is not sufficient reason.
Asymmetric key operations have a comparatively high power consumption, and this power has to be supplied via the electric field. This severely limits the distance between card and phone and may even require direct touch. While a power supply of its own would solve the issue in principle, it is not what ISO-14443 was designed for.
Yes JavaCards do exist.
https://github.com/OpenJavaCard/openjavacard-ndef is a project makes these JavaCards to output standard NDEF messages (thought note issue 4 in that there example uses the wrong APDU but that is easily changed)
This project also give a number of cards it is fully working and tested for
ACS ACOSJ - fully working
NXP JCOP J3D040/J3D081/J2E145 etc - fully working
Both ACS and Cardlogic do cards (just google the model numbers)
e.g.
https://www.acs.com.hk/en/products/405/acosj-java-card-combi/
https://www.smartcardfocus.com/shop/ilp/id~707/j3a081-80k/p/index.shtml
The answer a was looking for is not a chip which runs a custom code. Although this might be possible it is definitely not the best way to achieve the target.
I was looking for a solution that enables strong authentication using NFC data. There might be multiple chips that offers this, but probably the most available chip is NTAG 424 DNA TT. It works like this:
The chip has a memory, which is not readable through NFC. Private key is stored there.
The chip has a read counter. It increments everytime the data are read through NFC.
The chip can generate an AES-128 signature of string UID (chip serial number) + counter using the private key in the inaccessible part of the memory.
The chip can dynamicaly inject the data above into a URL that is stored in the readable memory.
So the solution will be like (I am waiting for delivery of NFC tags right now, so I don't know for sure yet):
Read the tag UID (serial number) and the actual counter value (should be 0 on an unused tag)
Generate the key-pair
Load private key to the chip
Load some data (URL, eg: https://my.app/) to the chip
Store UID, public-key, last-counter on the server
Configure the chip to inject UID, counter, signature to the URL stored on the chip
When a client reads the data, they should contain required variables, eg: https://my.app/?counter=1&uid=ff:ff:ff:ff&signature=xyz. Then on the server:
Fetch stored info (public-key, last-counter) using uid as a primary key
verifies the signature
verifies the counter that must be > last-counter
stores counter as the last-counter
successfully authorized
Is anyone able to hack this without reading the hidden memory of the chip which would require physical tampering with the chip?
Background story:
I'm trying to write my own logging library. It's for hobby purposes. There's one must for me: logged data must be encrypted asymmetrically. The log messages are always directly written into the file, no caching occurs, no waiting for any queue.
This means I'll have to encrypt bunch of small chunks of messages. Even though the bottleneck is probably going to be the lack of caching & IO operations, I'd like to choose the encryption algorithm wisely.
Summary:
I have to encrypt numerous of small (<200 bytes) of data
Algorithm MUST be asymmetric, I'd like to encrypt with the public key and the only be able to decrypt it with my very own private key
What algorithm do you suggest?
It seems that you're interpreting “logged data must be encrypted asymmetrically” literally as a low-level requirement. “Logged data must be encrypted asymmetrically” is not a security requirement, it's an implementation approach. It's a bad implementation approach, because it requires you to design your own cryptographic protocol (you can use standard primitives, but only in a non-standard way), and it would have annoying limitations.
A much more reasonable requirement is “the machine that produces the logs must not be able to decrypt them”. This is a security requirement: it is a requirement on an asset (the logs) concerning its security (specifically their confidentiality).
The way to implement this security requirement is indeed to use asymmetric encryption. But you don't take an asymmetric encryption primitive and pass the logs as input to that. Rather, you use hybrid encryption: generate a symmetric key, encrypt the logs with that, encrypt the symmetric key with the asymmetric key, and erase the symmetric key.
The best way to do this is to use a library that does it well. The crypto_box, crypto_box_easy and crypto_box_seal functions of NaCl or libsodium are the gold standards here. You pass the public key for encryption, the message to sign, and you get an encrypted “box” out which can only be decrypted with the private key. crypto_box_easy and crypto_box also take your own private key as an argument, to sign the logs, which you might not want in your toy example but is usually important in the real world. crypto_box_easy and crypto_box also take a nonce as argument; this can be any value that can be public but that you must not use twice, for example a random string of crypto_box_NONCEBYTES bytes.
If you don't want to use crypto_box, for example because you want to learn how it's done under the hood, you have to assemble the parts manually, using your chosen low-level cryptographic library. The flow is different depending on which flavor of asymmetric encryption you use. With a key establishment method such as ECIES:
Generate a random one-time private key y.
Calculate the corresponding public value gy.
Using the recipient's public key gx, calculate the shared secret gxy.
Apply a key derivation function such as HKDF to deterministically generate a secret symmetric key, for example an AES key or a Chacha20_Poly1305 key.
Use the secret symmetric key to encrypt the log message, for example using AES-GCM or Chacha20_Poly1305.
Optionally, hash the log message and sign it with your public key.
Wipe the one-time private key, the shared secret, the secret symmetric key, the plaintext log, and any other intermediate value from memory.
Send the ciphertext, the public valuegy and optionally the signature.
With a key encryption method such as RSA-OAEP:
Generate a random one-time secret key, for example an AES key or a Chacha20_Poly1305 key.
Use the secret symmetric key to encrypt the log message, for example using AES-GCM or Chacha20_Poly1305.
Optionally, hash the log message and sign it with your public key.
Encrypt the symmetric key using the recipient's public key.
Wipe the one-time secret key, the plaintext log, and any other intermediate value from memory.
Send the ciphertext, the public valuegy and optionally the signature.
Doing the steps manually may have a performance benefit if you decide that it's ok to encrypt multiple log messages with the same symmetric key. This has a performance benefit, because asymmetric operations are slower than symmetric operations. There is no long-term security drawback to doing this. The only security drawback is a short-term one: all logs from the current symmetric key can still be decrypted. If you decide, for example, that it's ok if an attacker who breaches your system can read the last minute's logs, then you can renew the symmetric key every minute.
First, some info on our system, which is basically an eTendering solution for the construction industry.
So:
List item
Our system has multiple companies
Each company has multiple users
Each company can create multiple auctions
Other companies can then submit their bids for the available auctions. A bid consists of hundreds or thousands of individual items, and we would just need to encrypt the 'price' section of these records.
The problem that we're facing is that our large customers do not want us to ever have access to the bid prices, at least while the bidding is in progress, which is totally understandable. Right now, we are simply encrypting the prices via a symmetric encryption, so even though the prices are effectively encrypted in the database, their concern is that we have the key to decrypt the prices.
We're thus looking at some form of public key encryption system.
Here is our initial thoughts on the solution:
When a company signs up, we create a public/private keypair using OpenSSL for it and we save it in S3 or straight into the database. For this to be really useful, we would enforce the user to use a strong password for the private key, which would of course not be saved in the database.
When a company submits a bid for an auction, we encrypt the prices using the public key of the auction's owner company and we save them into the database.
When the auction bidding period is over and the issuing company wants to generate the report the first time, we ask him to input his password and use that along with his company's private key to decrypt the prices.
To make subsequent traffic faster, we cache the decrypted data (and maybe encrypt it using a simple symetrical encryption system)
So here are the questions (and we're unfortunately not security experts, so sorry if those are stupid questions):
Does this make any sense or is it a totally ludicrous or overkill solution?
Would we generate the keys using OpenSSL, OpenPGP or another solution?
What happens if a user wants to change his password or generate a new key? Would there be no other way but to decrypt/re-encode everything with the new key?
What would some of the pitfalls be with this solution?
Are there any better solutions that you could recommend?
So here's my suggestion, if you want to solve this using encryption...
Each user and each company should generate OpenPGP (or GnuPG) asymmetric public/private key pairs
Each of those public keys should be uploaded to a public key server
Companies could optionally "sign" the public keys of the individual users, to designate a trust relationship with those users (and revoke that signature if that relationship changes)
The auctioneer or non-partisan arbiter would also generate a key pair and push that public key to the public key server
As part of an auction registration process, each user would import the public key of the auctioneer, and the auctioneer would import the public key of each user
A trusted third party, perhaps a SaaS vendor outside of the auctioneer, would host a service through which users and the auctioneer would communicate
Bidding users would create a bid by
signing their bid with their private key
encrypting their proposed price to two keys: their own public key and the auctioneer's public key
submitting their bid to the trusted third party service, which would need to enforce an embargo on any user retrieving bids before the auction expiration
At auction end, and only after auction end, the auctioneer retrieves all of the bids, decrypts them, and verifies signatures
A couple of key points:
It's essential that no user or company private keys are ever shared or stored within the service -- that's the only real "flaw" I see in your proposed methodology in your question. If that's the case, it would be very possible for one user to accuse an administrator of "fraud" or "tampering" with bids, as an administrator of your server would ultimately have access to the private keys of all users, since you've generated them yourself.
Along those same lines, it's essential that any an all communication and "bids" are cryptographically "signed" with the truly private keys by each user. This is how you would know that a bid came from one particular user and only that user, and that the bid could not have been tampered with.
Encrypting the bids to the public keys of the bidding user and the auctioneer ensures that the third party SaaS vendor has no introspection into the bids themselves during the blackout period while the auction is open. I believe this is the most important point to solving your problem as described.
Note that it might actually be preferred to encrypt each bid to a ring of all of the bidding users, if by design you want to make all bids public after the auction is closed. That would be a slight modification to my algorithm as described above.
In the interest of full disclosure and perhaps some subtle marketing, I happen to be the architect and CTO of a company called Gazzang who has implemented a product called zTrustee which operates exactly as described above ;-)
To be clear: I have a hunch that your clients are probably not willing to sacrifice all of the conveniences that come with having your system manage some of the cryptography; you should probably present several options and their weaknesses vs convenience.
General Points
Before anything else, you start start with an explicit threat model, covering every possible attack you can think of. Even if you choose not to address some of the attacks (it's unrealistic to handle everything), you'll ferret out the more obvious attacks, and have at least a basic set of steps for handling others should they occur.
Re: Does this make any sense?
I think the general premise, while overkill on the part of your customers, makes sense from a security perspective. Your clients want a cryptographically secure system; fair enough.
However, some points on your proposed solution:
By allowing the client to pass their password over the wire, an attacker (which your client seems to think could be you) needs to only man in the middle that password to gain access to the pricing data.
SSL helps mitigate this, but an errant log line somewhere along the line could very well expose the client's password by accident.
The only truly cryptographically secure way (as I see it) for the client to ensure that you don't have access to the pricing data is for them to encrypt it, and your system just acts as a broker for the encrypted data. This, in effect, makes you a broker of encrypted packets and public keys, but your system should never see private keys.
The question is: are clients willing to manage their own keys, or is that too burdensome to them? You might be able to automate most of it, at least (client app/website would handle storing the private key locally, and would also be responsible for gathering public keys of the other interested parties in order to decrypt their encrypted bids)
Re: Would we generate the keys using OpenSSL, OpenPGP, or another solution?
Really doesn't matter all that much; each of those options just define the container format for the public/private keys and any metadata. Use whichever one fits your language/platform best.
The main decision point should be in which encryption algorithm and key strength: RSA-2048? RSA-4096? elliptic curve? something else?
Specific to Ruby: You're probably just going to want to use the OpenSSL library, since it's part of the standard library. But to reiterate my point above: It's even better if your servers never even see the private keys (if the clients are ok with the trade off of better security over convenience)
Re: What happens if a user wants to change his password or generate a new key?
Changing a password is trivial: the private key its self is just encrypted w/ some symmetric algorithm. Changing the password involves decrypting the existing key, and re-encrypting it with the new key. If the client were to lose their password, there is no recovery.
Generating a new key is probably safer, but requires more diligence on your part (encrypted payloads will need to identify which key they match, and clients could have multiple keys active at a time). This is a good thing, though; it is a common practice to rotate keys regularly, even if they are not compromised.
When a company signs up, we create a public/private keypair using OpenSSL for it and we save it in S3 or straight into the database. For this to be really useful, we would enforce the user to use a strong password for the private key, which would of course not be saved in the database.
I am a bit sceptical about this step. If you (the developer company) generate both the public and the private key used for the encryption it means you are 50% into being able to break the encryption. The only thing that protects your customer is the password, which you might be able to bruteforce (i am not suggesting that you will but you have the ability to do so)
If you will use PKI (or what you have described) you need to ensure that the key creation does not happen on your system. The client should create the pair on their systems and then provide you with their publoic key which you will use to encrypt the prices. The client then will be able to decrypt using the private key on which they have sole control
What would some of the pitfalls be with this solution?
The pitfall is that you are making a complex solution. Especially if you follow my advice above, then you place your trust on the customer to not "lose" the private key (and/or password) or else they won't be able to decrypt the prices. In addition, if the key leaks from their side, it's difficult to prove that your application is "innocent"
Would we generate the keys using OpenSSL, OpenPGP or another solution?
In order to prevent the pitfall of a customer losing a key, you might want to look into PGP (the commercial version does this for sure) and into the concept of ADK (additional decryption key) and "split keys". The idea is that besides encrypting with the public key of the customer you also encrypt with a "corporate" key which can only be used if y out of x number of people come together (as an example, 10 people can possess parts of the key and if 6 of them come together they can reconstruct the key). The parts can be shared amongst your company, the client, their lawyer, etc
I'm writing CSP library (for CryptoAPI) for smartcards my company sells.
I have question about difference between AT_SIGNATURE key type and CALG_RSA_SIGN algorithm for private key (the same also for AT_KEYEXCHANGE and CALG_RSA_KEYX).
I know what is written on MSDN site, but how specifically CSP DLL should work if either of CALG_RSA... algorithms is specified in call for CPGenKey() function? I mean should it generate session RSA private key or the key should be generated and saved on card? Or maybe it depends on flags specified on CPAcquireContext() call (CRYPT_VERIFY_CONTEXT ie.) and AT_SIGNATURE should be defined as "default algorithm for signature", which for our cards is RSA?
Thanks
It's not my answer, just found a good explanation on the Internet:
AT_SIGNATURE key acn ONLY be used to sign a message. It cannot be used to
wrap (export) session key. AT_KEYEXCHANGE key can be used for BOTH purposes.
So if you want to use only 1 (one) key pair for both, you definitely need
AT_KEYEXCHANGE key pair.
You also need to understand some security implications - and why using two
keys are better than using the same key pair for both:
Normally you should NEVER reveal your signing private key. If it is lost, you
simply generate a new signing key pair and use that from that point of time.
On the other hand, you normally need to back up your key exchange key,
because without that you cannot decrypt messages in the future (if the
private key is lost). However, backup means that the key may be available to
someone else - who now could sign messages purportedly coming from you - and
you wouldn't want that.
If you use different key pairs for the two actions you can have secure
signing (your signing private key never goes out) and still can back up your
key exchange key.
One more note on generating these keys:
Since you don't want your signing key know, when you generate it with
CryptGenKey(AT_SIGNATURE) you should never set flags KEY_EXPORTABLE or
KEY_ARCHIVABLE and you may want the extra protection and add
CRYPT_USER_PROTECTED, so every time the signing key is used the user knows it.
On the other hand, when generating the key exchange key using
CryptGenKey(AT_KEYEXCHANGE) you should immediately back it up: set the flag
CRYPT_ARCHIVABLE and IMMEDIATELY export the key for backup. (This flag allows
to export the key only once - right after it is created -, so it is more
secure than allowing to be exported any time by setting CRYPT_EXPORTABLE.)
Laszlo Elteto
SafeNet, Inc.