I have an Apex flex and installed Smart PGP, but can’t find a way to store gpg encrypted file on it.
Know how to encrypt a file with OpenKeychain, but don’t know how to store a gpg file on the impant and when I read it, the app ask for a decryption password, I give it an I see the decrypted message.
What’s the possible way to do this without touching the NDEF record?
The SmartPGP applet can only store your keys.
From a security standpoint, there is no need to store an encrypted file on the chip - it could just be stored in some cloud storage for example. However, portability and offline access are something to consider of course.
You can write multiple distinct records to the NDEF applet, maybe you can use that.
If I get it correctly, I can make an NDEF record which is separated.
How can I make that if others read it they see only the first chunk of data, but when I read it I see both?
I think you are looking for a secure storage option like DESFire can offer where you can create a “file” on the DESFire chip and lock access to it using an AES symmetric key. It doesn’t encrypt the data but simply blocks access to it unless you can authenticate with an AES or 3DES key.
Currently there is nothing for Apex like that, and even if we made something specific for secure storage, it would require a custom smartphone or external app to properly work with it to get your data in and out.
So, because you will need a custom app, you might consider just storing your AES encrypted data in an NDEF record and using an AES key to pull it down and decrypt it on your phone… or if you want, you can use SmartPGP to do the decryption of an encrypted AES key that is also stored in the NDEF container alongside the encrypted data in a separate record… then just write an app that would pull the data and encrypted AES key from your Apex and use PGP to run the encrypted key through SmartPGP to decrypt the key and then use it to decrypt the data… that way everything you need to decrypt the data is on your chip.
If you want to add some protection against someone just running through those steps to get at your data, you could easily add a manual salt to the mix so there is some form of protection. For example, you could put this salt into the mix for your encrypted data or the AES key itself… so like, you encrypt the data with an AES key + salt… then you encrypt on the AES key itself and store that on your chip… so you are missing the salt… then when you decrypt the AES key using SmartPGP, you will still need to add your salt back to properly decrypt your data… though you’ve dramatically reduced the entropy of your AES key by doing this and brute forcing becomes trivial… but I do know there are ways to add salts to cryptography that remain effective… someone better versed can chime in I’m sure.
Bottom line though … there is currently nothing for Apex that will work like you’re hoping because it would require much more on the phone / computer / external side to make this work how you want.
ok… so let me ask… what if we created something that worked like this;
- you install a “protected storage” applet on your Apex from 1kB to 32kB in size
- you’d have to use the Apex Manager smartphone app to use it
- you set a simple password to protect access to the data
- once set, you could upload 1 single file from your phone… any binary data, which would overwrite whatever is already on the chip
- to get the file back, you’d have to enter your password and it would download it to your phone and store it in the /Downloads folder
- no encryption is happening anywhere… but the data on the chip will not be accessible until a proper password authentication happens.
- to help secure the password from brute-force, we will explore ways to create a tar-pit to slow down password checks past 3 fails in a row.
If that seems interesting to you, let me know… we’ll consider… if more people are interested in this please post so we can gauge interest.
Future features might include multiple file support etc. but for now just a single file will be supported. It could be a JPG file or TXT file or whatever.
Pre-tarpit check notes;
A traditional tar pit checks the password and if it’s bad, increments the bad counter and then implements some sort of delay before checking another password attempt. This does not work for scenarios or hardware like RFID chips where an attacker has control over the power supply and can perform an almost instantaneous reset on power cycle. The following is the way I suggest we implement a pre-check tarpit for RFID chips like Apex;
-
+1 to fail counter value
- we add one to the fail counter even before checking to ensure good/bad password checks take the same amount of time and power.
-
check fail counter value
- for the same reason, we check the value of the fail counter before checking the password.
-
if > 3 execute tarpit
- for the same reason, we tarpit if the fail counter is too high.
-
check password
- now that we have delayed checking of the password, we can check the password.
-
if password good, set counter value to 0
- if password is good, reset counter to 0 and proceed.
-
if password bad, halt
- if password is bad, halt. power must be removed and reapplied to try again.
1 Like
If we won’t use any encryption algo while storing the file the best would be store a pgp message because it’s already encrypted and I can operate with it via OpenKeychain. Also for security reasons there should be an option how do we want to read the file, like:
- store like you said under the Downloads folder
- open only in cache and show it’s content on screen
The first option what you said is good for binary files like image files, but the another is also needed for me. Let’s say I open the file with the password then I see a pgp encrypted message, i just copy it to OpenKeychain and decrypt it. This would be much harder with only the first option.
TL;DR
I totally support your idea but want to just copy the file’s content to clipboard and right after delete from cache.
I mean, we could … but then you have to manage the key for that… and that’s not something you can realistically remember and type in… so you’d have to store it somewhere… and if you store it on the chip then your security just becomes replicating a series of steps… which is worse than a password. let’s clarify your goals first… this is what i’m assuming;
-
not require storage of data or keys externally to the chip (not cached on phone / computer)
-
able to write and human read the data only if proper authentication is provided to the chip
are these goals correct?
if you don’t want to require external storage of a crypto key or the encrypted data itself on a computer or cloud or whatever, we can’t realistically leverage cryptography in a meaningful way. a password protection scheme is all you can realistically use because you have to remember and enter the authentication mechanism (the password) yourself to write or read the data to/from the chip.
you could store whatever you wanted there… pgp message or anything really… you just wouldn’t be able to read it without a password auth.
Yes this seems possible… it’s just binary data storage… so you could upload a file or enter ASCII text… or maybe Unicode. You could then download the binary content as a file or show it on screen as ASCII/Unicode text. It might get annoying if we don’t have any metadata… so if you upload bob.jpg but then forget and download it as bob.png that might not work right… so it would be good to have some basic metadata about what was uploaded show up once password auth has succeeded.
Sounds perfect. I really want to contribute but I don’t have this kind of java knowledge
We’re considering making this… i just need to understand the draw… who all would be interested in something like this to have some password protected storage on Apex?
1 Like
* raises hand I’d be interested in something like this
Can’t we already store images and files in an encrypted password database like keepass? We can even secure it with the hmac-sha1 applet on apex
Internal file storage would be very appealing as a feature but it would be more appealing if it were a larger storage option. IMHO. But either way, would buy.
I don’t want to store an encrypted file on the cloud or on a drive because that implies having access to the internet or said drive. The implant is always there no matter what. That’s the draw imo
(Full disclosure I haven’t read the whole thread so maybe I’m off topic)
Yes absolutely could do plenty with cloud storage, but some people absolutely want to keep certain “secret” data inside themselves and nowhere else. What kind of data? I DON’T KNOW, IT’S A SECRET! 
… but I’ve been asked about it many times.
Yep that’s exactly it.
Shitcoin wallet address and missile launch codes
1 Like
Yeah well maybe i want to store my favorite high def nudie picture in case there is an apocalypse, or a video clip of spongebob going ‘Aight im out’ or the entire julia child recipe collection! xD. Maybe a copy of all my personal information like birth certificate, medical records, etc.
1 Like
The last one is possible. I mean the personal data can be that small that you can store it in the NDEF, you have 32kb, that can store many things.
1 Like
The only “problem” is the time it would take to send/receive the 32kb.
A spongebob clip for your own use would be fine if you have the time to wait.
But if you are sharing a business card with a “high res” nudie profile pic, it is less practical…but maybe more worthy of the wait
That’s true 32k and take a long time… But we are considering implementing a block storage mechanism so you could address any byte length for read and write. With a very simple object management scheme at the start of the storage space, efficient read write could be possible for multiple stored objects.
3 Likes