Which of MIFARE cards support a single block that can be programmed to require a password for writing, but is available to everyone for reading its data? And is such standard eligible on all platforms, specifically iOS. Can it use its NFC chip for doing both mentioned operations on such card?
There are quite a few products in the MIFARE product family1 that would allow write-protecting information with an authentication key/password (while at the same time having that information freely readable):
MIFARE Ultralight EV1: 32 bit clear-text password verification, password can be used as a write password (free read, "authenticated" write) or as read/write password (only "authenticated" read/write). The password cannot be set for a single block through, it's only possible to set one passwords for all blocks starting at a specific offset. Note that many of NXP's NTAG products also feature these capabilities.
MIFARE Ultralight C: Similar capabilities to the above, but with a stronger authentication mechanism using 2-key-TDES.
MIFARE Classic: Each sector can have separate keys. You always need keys for reading and writing.
MIFARE DESFire EV1: Not organized in blocks but in files. Each file can have multiple keys set for read protection and/or write protection. Hence, you could have a file that's freely readable but requires a key for writing.
Your second requirement, "is such standard eligible on all platforms, specifically iOS", is a bit more complex to answer: First of all, writing to NFC tags is not possible in iOS (except with some jailbreak?) Hence, I would interpret that as: What tags support write-protection and can be read with an iOS device?
iOS devices can only read from NFC Forum tags that already contain an NDEF message. Moreover, since the NFC Forum tag specifications do not (yet?) define a way to have authentication for accessing NDEF data, all data needs to be freely readable.
Hence, all of the above, except probably for MIFARE Classic, can be used. You will need to format the tags to contain an NDEF message.
For instance, you could use a Ultralight C/EV1 tag, store an NDEF message onto it and then set write-protection for the area where the NDEF data is stored (i.e. all pages >= 3). However, only adding write-protection for a specific block won't work. You may be able to craft your NDEF message in a way that the write-protected part sits at the end of the NDEF message at a block boundary of the Ultrlaight tag. Then you could add write protection for only that specific block (and all higher, but unused, blocks). Unfortunately, this opens up for potential manipulations on the size fields for the NDEF message (chopping off that write protected block from the data). Hence, partial write protection of the NDEF message might not be a good idea from a security perspective.
Similarly to the above, you could also use DESFire EV1. When used as an NFC Forum tag, the NDEF message is stored in a single file. Therefore, you could restrict writing to that file with an authentication key.
As iOS can't write to the tags, you will probably use another platform to write updates to the tags. Android, for instance, is capable of sending the low-level commands necessary for authentication to any of the above tags. Similarly, many PC based readers support this (though DESFire usually has better support there).
1) Note that there is other products (even from other manufacturers) as well that provide similar capabilities.
Related
I'm using Airdrop to transfer application internal data between two phones. Because Airdrop was intended for file sharing, it could occur that user choose "save the file" to save the data file in Files app by accident. Since my app is a financial planning app, I'm considering to encrypt the file transferred by Airdrop to keep user's data secure. The encryption only applies to the temp file transferred by Airdrop. Once the app on the receiver phone receivers it, it decrypts the file immediately.
I'm referring to this thread to determine how I should answer the export compliance question if I encrypt the temp file. And I noticed these two exemption items:
(iii) your app uses, accesses, implements or incorporates encryption with key lengths not exceeding 56 bits symmetric, 512 bits asymmetric and/or 112 bit elliptic curve
(iv) your app is a mass market product with key lengths not exceeding 64 bits symmetric, or if no symmetric algorithms, not exceeding 768 bits asymmetric and/or 128 bits elliptic curve.
I don't quite understand the difference between the conditions in the two items (what is a mass market product?). But I don't think either helps, because the ciphers provided by iOS Cryptokit contains only AES and ChaChaPoly - the former takes a minimum key size of 128 bits and the latter takes 256 bits key size.
Since there are a lot of apps using Airdrop to transfer application internal data (I can tell that from the discussions on SO), I wonder how other people deal with this? Is this considered an exemption case?
BTW, I considered other options, but none is satisfying:
Don't encrypt the data. Obscure it instead (for example, using something like Caesar cipher). But that feels very unprofessional.
Don't use Airdrop. Implement my own data transfer mechanism. For example, start a tiny web server on sender side and the receiver side get the data through HTTPS, which from my understanding is an exemption case. I don't choose this approach because a) Airdrop provides a much better user experience than this approach, b) I'll need to use Bonjour to discover service, which requires local network permission. I'd like to avoid that if possible.
The answer depends on what cipher you use to encrypt the data.
Apple summarises your requirements in a couple of documents.
First, in the CryptoKit documentation
Typically, the use of encryption that’s built into the operating system—for example, when your app makes HTTPS connections using URLSession—is exempt from export documentation upload requirements, whereas the use of proprietary encryption is not. To determine whether your use of encryption is considered exempt, see Determine your export compliance requirements.
This leads you to this document which has a table, that I have shown in part:
Assuming that you use AES from Apple's Crypto Kit framework, the second clause would apply. You don't need to provide any documentation to Apple but you should submit a self classification report to the us government.
The exemptions you listed in your question do not apply since you wouldn't use a symmetric cipher with a key length of 64 or 56 bits.
I am reverse engineering a driver that implements HID for the purposes of searching for vulnerabilities.
The main IOCTLs it implements are all from the HID minidriver libraries in the WDK.
I am in particular interested in sending malformed values to the IOCTL_HID_SET_FEATURE IOCTL. However, based on Microsoft's documentation:
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/hidclass/ni-hidclass-ioctl_hid_set_feature
It is somewhat unclear as to how I would set a feature for one particular HID device as opposed to any other from the documentation. It is a little hand wavy as to what is expected to be in a feature report.
The input buffer size, in bytes, must be large enough to hold the feature report -- excluding its report >ID, if report IDs are used - plus one additional byte that specifies a nonzero report ID or zero.
The Irp->AssociatedIrp.SystemBuffer member points to the input buffer that contains a feature report. If >the collection includes report IDs, the requester must set the first byte of the buffer to a nonzero >report ID; otherwise the requester must set the first byte to zero. The feature report -- excluding its >report ID, if report IDs are used - is located at ((PUCHAR)ReportBuffer + 1).
The documentation refers to the IOCTL as targeting a "top-level collection." but based on my reading of my own driver's disassembly it looks like you can specify features on a granular level, specific to an individual device.
Two interrelated questions here:
Is it possible to target these IOCTLs toward a specific device rather than a class of devices? If so how? If you can point me toward an example of a client that does this, that would be awesome.
What specifically is in a HID feature report/where can I find a spec that defines it?
I'm in charge of technology at my local camera club, a not-for-profit charity in Malvern UK. We have a database-centric competition management system which is home-brewed by me in Delphi 6 and now we wish to add a scoring system to it. This entails attaching 5 x cheap-and-standard USB numeric keypads to a PC (using a USB hub) and being able to programmatically read the keystrokes from each keyboard as they are entered by the 5 judges. Of course, they will hit their keys in a completely parallel and asynchronous way, so I need to identify which key has been struck by which judge, so as to assemble the scores (i.e. possible multiple keystrokes each) they have entered individually.
From what I can gather, Windows grabs the attention of keyboard devices and looks after the characer strings they produce, simply squirting the chars into the normal keyboard queue (and I have confirmed that by experiment!). This won't do for my needs, as I really must collect the 5 sets of (possibly multiple) key-presses and allocate the received characters as 5 separate variables for the scoring system to manipulate thereafter.
Can anyone (a) suggest a method for doing this in Delphi and (b) offer some guide to the code that might be needed? Whilst I am pretty Delphi-aware, I have no experience of accessing USB devices, or capturing their data.
Any help or guidance would be most gratefully received!
Windows provides a Raw Input API, which can be used for this purpose. In the reference at the link provided, one of the advantages is listed as:
An application can distinguish the source of the input even if it is
from the same type of device. For example, two mouse devices.
While this is more work than regular Windows input messages, it is a lot easier than writing USB device drivers.
One example of its use (while not written in Delphi) demonstrates what it can do, and provides some information on using it:
Using Raw Input from C# to handle multiple keyboards.
I'm new to iOS development and working on a small iOS mobile app that stores sensitive information of users. Initially I thought of using custom AES encryption to encrypt/decrypt all the data. I also want the encrypted data to be synced with iCloud. After reading more I came to know from iPhone 3GS each device has a built-in AES-256 crypto engine. From the XCode, I observed that I can turn on an option called "Data Protection" for the mobile app to secure data. Based on my analysis I've below questions:
To use data protection for iPhone 3GS (uses iOS 6.1) do I need to set passcode?
Without setting passcode for the device how can I use the built-in crypto engine to encrypt my data?
The information are very sensitive and so in this case do I need to implement custom encryption?
RNCryptor is very useful, but it's basically just a wrapper for Apple's own CommonCrypto functionality (that makes implementing it pretty easy). It's useful if you want to encrypt data on the device that even the user cannot get ahold of.
Regarding your specific questions:
Data protection encrypts your app data using Apple's device-level encryption (you do not password protect it yourself). This has its uses - it will keep a 3rd party from being able to access data on a device if they are unable to unlock it - but does not prevent (for example) a user from getting access to data on their an unlocked device. Using RNCryptor and CommonCrypto which it is built upon you can AES256 encrypt content using a password of your choosing.
Apple details this here. Basically, from the end user's perspective they just set a password for their device as normal. You do not use a password of your own choosing.
You can set this up for your app using the following instructions:
https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/AddingCapabilities/AddingCapabilities.html#//apple_ref/doc/uid/TP40012582-CH26-SW30
This depends on how sensitive the data is and what threats you foresee (Who are you trying to keep it away from? Are there any laws/regulations you intend to comply with? How much work do you want to take upon yourself to protect this data?). There are a lot of trade-offs and caveats that can apply in certain situations.
If you have a small amount of data, you might consider just storing it in the iOS keychain. Otherwise, I'd recommend giving RNCryptor a try. It's fairly easy to integrate.
I hope this helps.
UPDATE: Another thing to consider... There are potential export control ramifications that might come up if you implement your own encryption, even using RNCryptor/CommonCrypto. Depending on how much paperwork and/or delay you're willing to deal with, this may influence your decision. You can learn more about this from Apple's site, here:
https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa/wo/20.0.0.13.7.2.7.9.3.1.2.3.3.1.5.7.1
This really depends on how many scenarios you are trying to protect against. Pretty much any scenario you can possibly create will be broken given enough time and effort. However to address a few points:
1) Yes you need to set a passcode for this feature to become active.
2) You can make use of the CommonCrypto library (or a wrapper around it like RNCryptor)
3) This is a bad idea for the simple reason that developing a secure algorithm is insanely hard. The slightest flaw will leak out all of the data and people have devoted years of their lives to sniffing out these flaws (although I may have misunderstood what you meant by "custom encryption")
If you want to be as secure as possible you will have to do this: Send your file to a server for processing (via HTTPS). It is much harder to hack into a server then it is to hack into an iOS application. If you simply use RNCryptor it is pretty trivial to rip apart the app looking for the password, or how you obtain the password. Basically if the app can do it then BlackHat can do it too.
EDIT I forgot about one thing! If you generate a random password for each install and store it in the keychain then this will help, but it is not foolproof (There is a small chance that the iOS keychain contents can be retrieved from a jailbroken device, especially if the user has a week passcode). However this will make the user's data non-recoverable if they wipe the OS for any reason.
very very very simple : https://github.com/RNCryptor/RNCryptor
I was used it for a chat application it so good.
I am looking for some libraries in delphi to programming and reading from RFID cards. today I use normal Mifare 1k cards, and use a simple library to read the cards UID, but I would like to do more with these cards, like storing and reading from theire memory.
today my development uses PCSCconnector.pas library in delphi (PC/SC Interface component)
I am not sure if this is capable of doing anything more advanced other than just send code to return the UID number of my cards ?
if not, what else is there out there who can be used?
in a second note, can someone push me in the right direction on how to identify card types?. what kind of RFID card I am holding, what are the parameters, mifare 1k. 5k? java card etc etc ?
This doesn't exactly answer your question, but a few notes and hints:
The problem with Mifare 1k (all Mifare Classic cards, not DESFire, Ultralight etc.) is that they are proprietary. Reading the UID is a standard function, supported by all ISO14443-compliant readers. To read/write data, you need to have a reader with Mifare (classic) support.
This raises the question on what kind of reader you are using?
The protocol and algorithms were reverse-engineered, but NXP does not license the crypto algorithm (crypto-1) - means any open source library doing so (there might be some) is probably not legal.
Documentation for all other NXP Mifare cards is only available under NDA.
EDIT:
SpringCard does have a lot of diagnostic software tools available on their website as well as a lot of other PC/SC-related resources. I think it is mainly C++/C#-focused.
http://www.springcard.com/solutions/pcsc.html
PC/SC Diag for example is quite handy for some quick tests on a card.