I am working on a Java Card application where our requirement is to keep some static data and balance in the card.
For security I was thinking to make 2 object of OwnerPIN. One object is for terminal authentication (i.e. the terminal needs to send 8 bytes of data to authenticate itself) and the other object is for user authentication (i.e. the user needs to enter a 4 digit PIN to authenticate theirself)
Only if both authentications are successful, we can read the data or update the balance.
Or is there any other advice on how to implement security on card to avoid theft?
Also is there any guideline for choosing proprietary class and instruction bytes during applet development?
For user authentication, the OwnerPIN is certainly one good way to go (there are alternatives ofcourse, but OwnerPIN provides security features (e.g. tearing protection) that you would otherwise have to implement manually).
For terminal authentication, nothing should prevent you from using an approach based on an instance of the OwnerPIN. However, depending on your security requirements, you might want to choose some form of mutual authentication instead of a simple PIN code. If the terminal simply sends a PIN code (especially if it does that in plain text), an attacker could simply intercept that PIN code (while sent to a card) and then use that discovered PIN code to create their own (malicious) terminal.
With regard to class and instruction byte (and especially with regard to standard operations like PIN code verification) I would suggest that you stick to standards. ISO/IEC 7816-4 defines many instructions for such standard operations.
Related
I have a (university) project where I basically write and read text out of an NFC tag with Android devices in order to store one's balance in the card (which can be used on the cafeteria, for example).
Right now, I'm using NTAG213 doing the below code:
ndef.connect();
NdefRecord mimeRecord = NdefRecord.createMime("text/plain", messageEncrypted.getBytes(Charset.forName("US-ASCII")));
ndef.writeNdefMessage(new NdefMessage(mimeRecord));
ndef.close();
As you can notice, I'm using application level encryption to encrypt the message (messageEncrypted) before writing it to the tag (AES-256 encrypt with 'com.scottyab:aescrypt:0.0.1' library - with a very big password key that uses also the tag UID as part of it).
So far so good - only I can understand the data on the tag.
On my research, I've found that when it comes to security Ultralight C > NTAG213.
Question 1) When using application level encryption, why (is it?) is MIFARE Ultralight C safer then NTAG213?
Question 2) I'm pretty sure I can guarantee security using AES encryption, but I don't want people (besides me) messing with the stored data (formatting tag or writing info there). I see that the only way of preventing that (please, correct me if I'm wrong) is to set a password for the tag. However, both NTAG213 and Ultralight C have only an 32-bit password. Is it good enough? Is there another way of preventing someone (besides me) writing data?
Question 3) Which other security measures can I use on such tags to enforce security (tag and application layer)?
Question 4) When you compare tag security (MIFARE DESFire > Ultralight > NTAG213 > MIFARE Classic), what is really being compared? The ease of one cracking the (native tag's) encryption or the ease of one store (anything) on the tag without permission?
Question 5) I see a bunch of other techs (MIFARE DESFire, ICODE SLIX, Infineon Cipurse) that are more secure, which makes me wonder if the tech I'm using (NTAG213 or Ultralight C) is good enough for storing someones balance. Would you (and that's a personal opinion) say that NTAG213 with application level encryption and 32-bit password good enough for this type of application? And how long would it take someone to actually break its security?
When using application level encryption, why is Ultralight C safer then NTAG213? Is that even true?
First of all, "safer" depends on what your actual protection goals are. Since you want to store a balance (cash money!) on the card, you would probably want to (at least) protect towards the following goals:
Users must not be able to print their own money by setting an arbitrary balance on their card.
Users must not be able to duplicate their card and, consequently, their money balance.
Users must not be able to print their own money by restoring (roll-back) their card to a previous balance after payment.
Users must not be able to print their own money by replaying a top-up procedure.
Users must not be able to evade payment by tearing their card during a payment transaction.
Users must not be able to generate an arbitrary (and potentially higher) balance on their card by tearing their card during a top-up procedure.
In addition, you might not want to trust operators (the persons accepting payments and performing top-up) as well. In a system where one group of operators performs only top-up and the other performs only payment transactions, the latter group should probably not be allowed to ever "create" money. Particularly, you have to make yourself very clear about whether you fully trust the (Android) devices that you use in the field to perform these operations and whether you trust operators (e.g. that they don't perform any attacks against these devices).
Moreover, there might be privacy aspects that you need to consider (e.g. if the balance is freely readable, if users are identifiable, etc.)
So let's look into what you "application level encryption" adds in terms of security:
Since users do not know the encryption key, they are probably not able to generate an arbitrary balance on their card. However, this heavily depends on the format of your balance (in unencrypted form). Users can make arbitrary modifications to the cipher text with result in "random" modifications of the plain text. Consequently, users may be able to modify the balance value despite encryption. Digital signature/message authentication codes are they path that you would probably want to take to overcome this.
Since the encryption key (assuming encryption would be sufficient, which it probably is not) depends on the UID of the tag, you may be safe against cloning of cards (+ balance). However, be aware that the UID is just a freely readable identifier. It is by no means authenticated itself and may be clonable as well. See Serials on NFC Tags - truly unique? cloneable?.
The encrypted value does not protect you from users restoring their balance to a previously recorded value after payment. This type of vulnerability has been found before (particularly in MIFARE Ultralight based systems), see, for instance, Benninger, C., Sobell, M. (2012): NFC for free rides and rooms (on your phone). In: Presentation at EUSecWest 2012.
Since you write the complete value during a top-up procedure (i.e. there is no specific "increment balance" command), you are probably safe against users replaying a top-up (except for the roll-back aspect of this).
Effects of tearing are probably rather limited if your system only allows for attended payment/top-up.
So let's see what additional features NTAG213 would have that you could use to secure your system:
UID is unique on genuine tags. This does not help much, see Serials on NFC Tags - truly unique? cloneable?.
Originality signature: same as above, the originality signature is also just a static, freely readable value. Consequently, it's just as well susceptible to cloning.
The one-way counter might be a tool to help you in protecting against roll-back (by including the counter value into the signature). This still would not prevent cloning onto a tag platform that allows to generate arbitrary counter values. Moreover, the counter is not easily controllable and will change its value if the user tries to read the tag. Consequently, it's questionable if an implementation based on that value would be reliable.
Unlike MIFARE Ultralight, NTAG213 does not have a usable one-time programmable area (since that's already used by the capability container). Consequently, you can't implement a one-time deductible balance based on that.
The password protection feature could help you in authenticating tags (by performing password verification) and in protecting the value stored on the tag (by making the value only readable/writable after password verification). However, the password is transmitted in clear text (may be subject to sniffing, particularly in (but not limited to) unattended scenarios) and there is no cryptographic binding between the password and the actual read/write.
MIFARE Ultralight C would add the following:
The OTP bytes can be used. If it's an option to make the tags one-time usable (i.e. they start with a specific balance that can only be deducted from and not topped-up), then using the OTP bytes to represent the balance would be an option. Note that there's still lots of things that you could do wrong with that, e.g. Beccaro, M., Collura, M. (2013): OTP circumventing in MIFARE ULTRALIGHT: Who says free rides?. In: Presentation at DEFCON 21
The authentication is much improved. The 3DES authentication scheme seems to be sufficiently secure to prevent sniffing the key. However, read/write commands are also not cryptographically bound to the authentication step. Consequently, an attacker might be able to let a genuine payment terminal + genuine tag perform authentication, but redirect read/write to somewhere else. This might (particularly) be a problem in an unattended scenario.
I'm pretty sure I can guarantee security using AES encryption.
See above. This is probably not true.
I don't want people messing with the stored data. I see that the only way of preventing that is to set a password for the tag.
A password/authentication key may help, but be aware of the limitations due to authentication being decoupled from read/write on these tag platforms.
Both NTAG213 and Ultralight C have only a 32-bit password.
This is not true. NTAG213 has a 32-bit password. MIFARE Ultralight C uses a more sophisticated mutual 2K-3DES authentication mechanism with a 112-bit key.
When you compare tag security, what is really being compared?
Authentication mechanisms (algorithms, key sizes)
Communication security (e.g. is the communication itself encrypted/authenticated using a session key derived from the authentication step?)
Access control (e.g. are there separate keys for top-up and payment?)
Are there dedicated mechanisms for balance management (e.g. value fields, dedicated increment/decrement operations)? And, consequently, are ther mechanisms to protect agains tearing attacks?
And probably more ...
I see a bunch of other techs that are more secure, which makes me wonder if the tech I'm using is good enough for storing someones balance.
You specific system is flawed in many ways. In my opinion MIFARE Ultralight/NTAG203/NTAG21x are definitely not a good choice for a an offline system storing cash money on the cards.
MIFARE Ultralight C may be suitable with some precautions. I would definitely refrain from using that in unattended scenarios, and I would probably use an online system tracking the balance and monitoring for inconsistencies.
Anything that uses symmetric cryptography and storing the cryptographic keys in a terminal would certainly require precautions against malicious operators. It's probably fairly easy for an operator (with some knowledge) to extract keys from an app and generate their own money.
I guess your question is too broad and not for all subquestions this section of SO is the most appropriate one.
By focusing on cryptographic strength you miss something: if the low level security of the token can be easily attacked, nobody needs to crack your key.
A simple dump and later restore (after some payments) corresponds to printing money
If the token contains the money directly (instead of only identifying the wallet, which is stored on a background system), you need a far more secure system to avoid financial damage. This involves dynamically encrypted communication but continues with substantial further topics.
I am responsible for our corporate application menu page (intranet only). It contains many links to resources (web pages and installed application) and is tailored to the current user.
In the past, I have used an applet to allow installed applications to be started directly from the browser.
The corporate web is going though a revamp and I have been told to find a solution which requires no plugins of any kind.
My first attempt was to register a custom protocol handler. The menu provider contains definitions for all the links and application commands and each user has different rights. I could imagine that, when the menu is created for a user, the commands could be encoded and added as something like custom://base64encodedcommand. The handler would decode the command, perform checks and execute it.
This works well in IE, FF and Chrome. At the moment, we have mainly Windows workstations and it will be used only within the company intranet.
Is this a viable approach? Are there security issues?
Unfortunately with any solution it is possible to only prove the existance of a vulnerability, and never the lack there-of. But there are some necessery, but not sufficient ways to make your system more resistant to attacks.
Currently you are base64 encoding the execution string. This adds absolutely nothing to security. Even if you chose some different method, this will only be security through obscurity, and can easily be reverse engineered by somebody with enough time.
What you can do is to have some sort of public-private key signing set up. So that you can sign each link with your own private key, and that would mean that this link is allowed to be executed, a link without a signature or with an invalid signature should not even be decoded.
So what you would have is custom://+base64link+separator+base64signature.
Things to keep in mind:
It is very important that only you (or very select group of people) have access to private key. This is the same as with any other pub-priv key system.
Not only should you not run the link if the signature is invalid, but you must not even decode it (thus you sign the base64 string, not the decoded command). Assume that it is an attack right away, and probably even inform the user of the fact.
And i repeat, while this can be considered to be a necessary for security, it is not something that is sufficient. So keep thinking of other possible attacks.
Because of security reason I should store encrypted data on Java card,
so the question is should I encrypt data with Offcard application and send it to Java card or send pure data to Java card and let Java card encrypt it by itself?
Anyway, I want to know the best way o store data on Java card and what is the best sequence diagram in order to consider security on data?
Thanks in advance
Basically it depends what you call the off-card application, and whether you consider it trusted (or to which extent you consider it trusted).
In a system involving a card application, a mobile phone application, and a back-end server, usually the server and the card application are trusted, anything inbetween isn't (which means communication has to be done ciphered). The card will want to authenticate any incoming data before processing it. In that case the mobile application is not very much trusted, for various reasons, including the shortcomings of mobile OS's security. You need to elaborate a bit more on your use case. What are the attacks you wish to prevent against, and what part of your system do you trust ?
Anyway to answer your question, the private data managed by the card application does not need to be encrypted before being stored, because the storage can be considered safe.
I don't know what these are called, so I will explain as best I can what we want to do:
We want to implement a secure log-in system so that when logging in we want to ask for a number that is generated on a small device that is carried with the person at all times.
I understand these devices work by relying on an algorithm that generates random numbers based on the current time. The same method is used on the sever side. They both independently generate the same numbers, since their clocks are in sync, and because its the same algorithm. When the user enters this number they should match.
Where can one buy these security dongles? What is this authentication method even called?
I know of RSA SecurID as a supplier of two-factor authentication solutions.
One name for one species of the gadgets you are looking for is RSA SecurID.
Our company used to use Safeword Tokens. Google the name, and you'll have a host of places to buy them from.
http://www.google.com/search?q=safeword+token&rls=com.microsoft:en-us&ie=UTF-8&oe=UTF-8&startIndex=&startPage=1
However, an even COOLER method of authentication is Phone Factor, which we switched to when we went away from SafeWord..
Is using a USB key to secure an application the best option?
If it isn't, what is the best way to secure an application in the form of requiring a valid user before the application can be used?
The reason I ask this question is that a client recently asked me to make an application require a specific USB device be inserted into the system before the app can be used or run. Basically, the application is a medical software and the client sees this method of security more trusted, as the app contains sensitive data of his paients. In that case of loss, I can tell the user how to generate another security key using the app in command line mode.
Not necessarily an answer to the question, but a point to be considered in response to the question and comments so far...
A USB key by itself is not going to be more secure than password-based authentication. It's still one-factor, it can be lost/stolen/etc. What the client probably actually wants, and either doesn't know it or hasn't properly articulated it, is multi-factor authentication. Consider these:
Something you know (a password, answer to a question, etc.)
Something you have (a USB key, time-limited key generating fob, etc.)
Something you are (finger print, retina scan, etc.)
Most systems use only the first one. For added security, you add the second one. For Mission: Impossible style high-clearance security, throw in the third one. The idea is that any one factor can be forged, but adding new factors adds new dimensions of security which exponentially make it more difficult (rather than linearly more difficult when just replacing one factor with a "better" factor).
Your application could require a certificate, signed by you, to be present on a regular USB memory stick. The certificate could be locked with a password, that the user would have to enter. Certificates on stolen or lost thumbdrives could be revoked.
For a less homebrew solution, I'm sure there are commercial smart card based services you could use.