Ok so i have developed an application which communicates with Mifare Classic smart cards (contactless).
The application is going to be used for member identification.
The current way is was just writing a 16 byte value to block 4 of the card. I left all the keys as the default (FF FF FF FF FF).
But what is the proper way to develope this kind of system so that it is more secure? Should we use the UID of the card instead of writing our own user id to data blocks?
Also can someone explain how the keys are used etc.
Thanks
If you want to identify someone you may want to keep record of an ID but also of personal data, such as the name of the person. Other data also may be interesting depending on the purpose of you application.
The bad thing about recording personal data is that this card may be lost exposing that information to person that are able to read the card data. That's why you should change the keys of the card to improve security. This way, a third subject who wants to check the content of your card would have to find out the key value first and this, besides possible, is not so trivial.
To protect the key value instead of having it hardcoded you could work with tables loaded in the reader device. Some readers have a memory region (a EEPROM, for instance) dedicated to store key values and all you will have to do is to pass the index of the desired key.
I don't think that using the UID of the card is a good option, thinking in the maintenance of your system. If someone has to change the card you would have to update you database. The advantage of your solution is that you don't need to do absolutely no set up to the card...
So, if you don't want to record any data on the card and wish to use its UID for identification, don't even bother to change the key.
Hope that helps!
Related
I am currently writing a firmware for an embedded device which acts as an human-machine-interface in an (aftermarket) automobile environment.
The device has got a service menu which shall only be accessible to specific personnel, which is secured by a device specific pin-code, which is generated randomly in production, burned on the device and stored in a database for the personnel to retrieve. Within the service menu, the user is e.g. able to manually change states and also overwrite limits for regulation functions etc.
However it might be necessary for any user to get to that menu in an error case, e.g. if they get stuck in a remote place and have a faulty sensor or whatever. Therefore I would like to create a kind of single-sign-in for the devices. My idea is, that the device creates a code and displays it to the user. The user then calls the service team which can create a pin valid for this device in this current state (the code displayed).
I don't want it to be too easy to figure out, so that anybody will be able to crack the algorithm of code generation. I cannot use any online functionality, as the users - as mentioned - may be in a remote place.
I was thinking about creating a table of random numbers and implementing it in the firmware (like 1-10k of pins and the device displays an index and the service teams just looks up the pin for that index) But I feel like there is a better solution to that problem.
My question:
What is a safe algorithm to compute a 4 digit (1000 - 9999) pin-code based on a random number (~6 digits hexadecimal) and (optionally) a 6 byte large serialnumber?
My program allows the user to input a password. The password is immediately hashed with sha1 and a constant salt and stored in memory.
Lets assume an Attacker has physical access to the computer where my application runs, and wants to retrieve the password of the last user.
Would it be possible for him to find the hash in memory with reverse engineering and some memory watch magic? My Application uses a MFC graphical interface and runs on Windows. What would he see if he himself puts in a password? could he monitor the hashing process?
If the password of my user is really bad, like "1234", all the security of the SHA1 hash depends on the SALT. The salt must also be stored somewhere in memory (its a #defined char* array right now). Could he find that with adequate effort?
Input process:
User enters password in a text edit. When done, user clicks "OK" button, BN_CLICKED message gets emitted, OnOK function is called. The function grabs text from edit field, calls hash function, which is (in code) part of another library, so I assume it must be placed somewhere else in memory. Hashed String gets stored also somewhere else. If it matters, the project structure looks like this:
SOLUTION
GUI Project
Data Storage Project
Crypto Lib
If you reverse engineer Win32/MFC applications then you should notice those data are stored in .data section while const data are stored in .rdata section, not unless the developer has explicitly created another section to store those data. I use OllyDbg for reverse engineering applications though IDA is the best one out there. Now to answer your question:
Would it be possible for him to find the hash in memory with reverse engineering and some memory watch magic? My Application uses a MFC graphical interface and runs on Windows. What would he see if he himself puts in a password? could he monitor the hashing process?
A: Yes, it is possible to find the hash in memory with reverse engineering. You just have to find the memory address of that data. Any reverse engineer/hacker can put a break point in GetDlgItem/GetDlgItemText and then capture the entered password and monitor the hashing process.
If the password of my user is really bad, like "1234", all the security of the SHA1 hash depends on the SALT. The salt must also be stored somewhere in memory (its a #defined char* array right now). Could he find that with adequate effort?
A: It requires very little effort to find the SALT too. One can easily go through those sections or use the technique that I mentioned above to debug and find out the SALT while monitoring the process.
If you are really worried about securing those data then you should consider using encryption. I hope that answers your question
I was considering the various options that i have when i want to protect a generic chunk of data to apply this principles to the distribution of a generic application.
Encryption doesn't make sense, it's like giving something unusable for the user or i have to give both the encrypted file and the key do decrypt it which make even less sense.
Generating entropy does not make sense because this process will only re-arrange the data in other way without breaking the business logic of the application.
Wrapping my application in an executable that requires a password to the user, my real application and my wrapper are double-linked and if my wrapper does not gives a green light my application will not run.
Web based distribution like the popular "Steam" service with a customized compilation for every user based on some login/ID verification.
What are the other options? I know that this will not end up with a definitive solution but at least i want to avoid the user to just redistribute my application with a simple copy and paste and i want to have at least a small edge over the software distribution system.
The usual way of doing this is to encrypt the data using some piece of information that is already on the user's system as the key; the data is then keyed to that system. For instance, on Mac OS X you can get the system serial serial number with a library call. Sun systems have a gethostid() library call that makes this trivial. An alternative that works on dumb systems cough Winders cough is to use the MAC address of an ethernet interface, or something like that.
It can be tricky, you typically have to write a little program that will grovel around in the system and generate a key, and then have the customer email this key to you, or at least OK the program to email the key to you. You can then encrypt the protected data using the key information you got back, and have the customer download it. It is possible to add this entire transaction to your application installer, if the size of the data blob is reasonable.
Ok, so I need some advice on which encryption method I should use for my current project. All the questions about this subject on here are to do with networking and passing encrypted data from one machine to another.
A brief summary of how the system works is:
I have some data that is held in tables that are in text format. I then use a tool to parse this data and serialize it to a dat file. This works fine but I need to encrypt this data as it will be stored with the application in a public place. The data wont be sent anywhere it is simply read by the application. I just need it to be encrypted so that if it were to fall into the wrong hands, it would not be possible to read the data.
I am using the crypto++ library for my encryption and I have read that it can perform most types of encryption algorithms. I have noticed however that most algorithms use a public and private key to encrypt/decrypt the data. This would mean I would have to store the private key with the data which seems counter intuitive to me. Are there any ways that I can perform the encryption without storing a private key with the data?
I see no reason to use asymmetric crypto in your case. I see two decent solutions depending on the availability of internet access:
Store the key on a server. Only if the user of the program logs in to the server he gets back the key to his local storage.
Use a Key-Derivation-Function such as PBKDF2 to derive the key from a password.
Of course all of this fails if the attacker is patient and installs a keylogger and waits until you access the files the next time. There is no way to secure your data once your machine has been compromised.
Short answer: don't bother.
Long answer: If you store your .DAT file with the application, you'll have to store the key somewhere too. Most probably in the same place (maybe hidden in the code). So if a malicious user wants to break your encryption all he has to do is to look for that key, and that's it. It doesn't really matter which method or algorithm you use. Even if you don't store the decryption key with the application, it will get there eventually, and the malicious user can catch it with the debugger at run time (unless you're using a dedicated secured memory chip and running on a device that has the necessary protections)
That said, many times the mere fact that the data is encrypted is enough protection because the data is just not worth the trouble. If this is your case - then you can just embed the key in the code and use any symmetric algorithm available (AES would be the best pick).
Common way to solve your issue is:
use symetric key algorithm to cipher your data, common algorithm are AES, twofish. most probably, you want to use CBC chaining.
use a digest (sha-256) and sign it with an asymetric algorithm (RSA), using your private key : this way you embed a signature and a public key to check it, making sure that if your scrambling key is compromised, other persons won't be able to forge your personal data. Of course, if you need to update these data, then you can't use this private key mechanism.
In any case, you should check
symetric cipher vs asymetric ones
signature vs ciphering
mode of operation, meaning how you chain one block to the next one for block ciphers, like AES, 3DES (CBC vs ECB)
As previously said, if your data is read andwritten by same application, in any way, it will be very hard to prevent malicious users to steal these data. There are ways to hide keys in the code (you can search for Whitebox cryptography), but it will be definitely fairly complex (and obviously not relying on a simple external crypto library which can be easily templated to steal the key).
If your application can read the data and people have access to that application, someone with enough motivation and time will eventually figure out (by disassembling your application) how to read the data.
In other words, all the information that is needed to decipher the encrypted data is already in the hand of the attacker. You have the consumer=attacker problem in all DRM-related designs and this is why people can easily decrypt DVDs, BluRays, M4As, encrypted eBooks, etc etc etc...
That is called an asymmetric encryption when you use public/private key pairs.
You could use a symmetric encryption algorithm, that way you would only require one key.
That key will still need to be stored somewhere (it could be in the executable). But if the user has access to the .dat, he probably also has access to the exe. Meaning he could still extract that information. But if he has access to the pc (and the needed rights) he could read all the information from memory anyways.
You could ask the user for a passphrase (aka password) and use that to encrypt symmetrically. This way you don't need to store the passphrase anywhere.
I want to store confidential data in a digitally signed file, so that I know when its contents have been tampered with.
My initial thought is that the data will be stored in NVPs (name value pairs), with some kind of CRC or other checksum to verify the contents.
I am thinking of implementing the creating (i.e. writing) and verification (reading) of such a file, using ANSI C++.
Assuming this is the data I want to store:
//Unencrypted, raw data to be stored in file
struct PrivateInfo {
double age; weight;
FitnessScale fitness;
Location loc;
OtherStuff stuff;
};
//128-bit Encrypted Data (Payload to be stored in file)
struct EncryptedData {
// unknown fields/format ??
};
[After I have read a few responses to this question]
Judging by the comments I have received so far, I fear people are getting side tracked by the word "licensing" which seems to be a red flag to most people. I suspected that may be the case, but in todays atmosphere of heightened security and general nervousness, I thought I'd better detail what I needed to be "hiding" lest someone thought I was thinking of passing on the "Nuke password" to some terrorists or something. I will now remove the word "license" from my question.
View it more as a technical question. Imagine I am a student (which I am), and that I am trying to find out about recommended (or best practices) for encoding information that needs to be secure.
Mindful of the above, I will reformat my questions thus:
Given a struct of different data type fields, what is the "recommended" algorithm to give it a "reasonable secure" encryption (I still prefer to use 128 bit - but thats just me)
What is a recommended way of providing a ROBUST check on the encrypted data, so I can use that check value to know if the contents of the file (the Payload of encrypted data) differs from the original.?
First, note that "signing" data (to notice when it has been tampered with) is a completely separate and independent operation from "encrypting" data (to prevent other people from reading it).
That said, the OpenPGP standard does both. GnuPG is a popular implementation: http://www.gnupg.org/gph/en/manual.html
Basically you need to:
Generate a keypair, but don't bother publishing the public part.
Sign and encrypt your data (this is a single operation in gpg)
... storage ...
Decrypt and check the signature (this is also a single operation).
But, beware that this is only any use if you can store your private key more securely than you store the rest of the data. If you can't guarantee the security of the key, then GPG can't help you against a malicious attempt to read or tamper with your data. And neither can any other encryption/signing scheme.
Forgetting encryption, you might think that you can sign the data on some secure server using the private key, then validate it on some user's machine using the public key. This is fine as far as it goes, but if the user is malicious and clever, then they can invent new data, sign it using their own private key, and modify your code to replace your public key with theirs. Their data will then validate. So you still need the storage of the public key to be tamper-proof, according to your threat-model.
You can implement an equivalent yourself, something along the lines of:
Choose a longish string of random characters. This is your key.
Concatenate your data with the key. Hash this with a secure hash function (SHA-256). Then concatenate the resulting hash with your data, and encrypt it using the key and a secure symmetric cipher (AES).
... storage ...
Decrypt the data, chop off the hash value, put back the key, hash it, and compare the result to the hash value to verify that it has not been modified.
This will likely be faster and use less code in total than gpg: for starters, PGP is public key cryptography, and that's more than you require here. But rolling your own means you have to do some work, and write some of the code, and check that the protocol I've just described doesn't have some stupid error in it. For example, it has potential weaknesses if the data is not of fixed length, which HMAC solves.
Good security avoids doing work that some other, smarter person has done for you. This is the virtuous kind of laziness.
Err, why not use a well known encryption system like GPG?
The answers to the edited question depend on the specific scenario.
For q1 (encryption): if you encrypt and decrypt at your servers you can use a symmetric key algorithm. Otherwise you may want to use public key cryptography.
For q2, if you simply want to check if a file has changed you can use any cryptographic hash such as SHA-1 -- assuming that you can make sure that the hash itself wasn't change.
If the data generator and the verifier are both secure you can use MAC algorithm such as HMAC to to verify that the data and the MAC match. But this works only if the secret key remains secret.
Otherwise, you may be able to use digital signatures.
I'm going to change the phrasing of the question and see if it makes people happier (or I get downvoted). There are really two types of questions being asked:
You are making some computer game and you want to know if someone has been messing with your save files. (data signing)
You are writing a messaging program and want to keep people's message logs private. (data encryption)
I will deal with the second one (data encryption). It's a massively difficult topic and you should be looking for pre-built programs (such as PGP/GPG) even then it's going to take you a lot of time to understand and use properly. Think about encryption like this: it will be broken; your job is to make it not worth the effort. In other words make the effort required to break it greater than the value of the information.
As for the first one, again it can be broken. But a checksum is a good idea. see Amnon's answer for some links on that.
Hope this points you in the right direction. I'm not an expert on either topics but I hope this gives you a starting point. (you might want to re-phrase the question and see if you get some better answers)