I want to prevent modifications from my application files stored in Documents directory.
I try CryptoSwift and AES256CBC libs but they greatly slow down my application which has multiple read / write files
Enabling Data Protection capability on my application project it enough for prevent user to modifying theses files content ?
The data protection feature is secure against everyone except the iPhone owner if the iPhone is not jailbroken. It uses AES encryption and the encryption key is stored in the keychain.
The data protection feature used Common Crypto that uses the hardware encryption engine and is very fast, on my iPhone 6s 1MB encrypts in ~2.3 mSec, a rate of > 400MB/s.
Related
Working on implementing flash encryption and secure boot on ESP32. The first step is to get flash encryption working. I am targeting the following settings:
Release Mode
No reflash over UART.
Use the esp generated key (no need to reflash anything).
MAlong with my 2 OTA app partitions, I have used a data partition of sub-type nvs to store my device security certificate for access to my cloud backend.
In my partitions.csv file, I don't think I can set the nvs partition to encrypted as it would brick my device. How can this be made secure?
Do I need to add nvs encryption an nvs_keys partition?
NVS partitions can also be encrypted, but it's done differently from encrypting everything else in Flash. In short, you need two partitions. One is your NVS data partition which gets encrypted using NVS encryption algorithm. Other is the "NVS keys" partition which holds the encryption keys for previous, and this one gets encrypted using the standard Flash encryption algorithm. If it sounds confusing, welcome to the club. But once you dig through this, it works fine.
Pre-generating an encrypted NVS data partition with some data on it (e.g. your certificate) now gets an extra step where you encrypt it on your computer before writing it to Flash.
Consider a HTML5 game, rather heavy on the assets, is it possible to somehow provide the user with an option to store the assets locally, in order to avoid loading all those assets again each time he loads the game?
Yes, there are several options:
Web Storage (localStorage/sessionStorage) can be used to store strings (or stringified objects). It has limited storage capacity but is very easy to use.
Indexed DB is a light database which allow you to store any kind of objects incl. BLOBs. It has a default limit (typically 5 mb) but has an interface that allows you to request more storage space.
Web SQL is also a database, although deprecated it has still good support in for example Safari (which do not support Indexed DB) and works by executing short SQL queries.
File system API is in the works but not widely supported (only Chrome for now). As with Indexed DB you can request larger storage space, in fact very large in this case. It's a pseudo file system which allow you store any kind of data.
And finally there is the option of application cache using manifest files and off-line storage. You can download the assets and define them using manifest files which makes them available to the app without having to consult server.
There are legacy mechanisms such as UserData in IE and of course cookies which probably has very limited use here and has it downsides such as being sent forth and back between server for every page request.
In general I would recommend web storage if the amount of data is low, or Indexed DB (Web SQL in browsers which do not support Indexed DB) for larger data. File system is cool but has little support as of yet.
Note: There is no guarantee the data will be stored on client permanently (user can choose directly or indirectly to clear stored data) so this must be taken into consideration.
We have a device running Linux and we need to run untrusted applications on this. We are trying to alleviate the following security concerns -
The untrusted application should not be able to adversely affect the core OS data and binaries
The untrusted application should not be able to adversely affect another application's data and binaries
The untrusted application should not be able consume excessive CPU, memory or disk and cause a DoS/resource starvation like situation to the core OS or the other applications
From the untrusted application standpoint, it only needs to be able to read and write to its own directory and maybe the mounted USB drive
We are thinking of using one of the following approaches -
Approach 1 - Use SELinux as a sandbox
Is this possible? I have read a bit of SELinux and it looks a bit complicated in terms of setting up a policy file and enforcing it at runtime etc. Can SELinux do this and restrict the untrusted application to just read/write its own directory and also be able to set quota limits?
Approach 2 - Create a new sandbox on our own
During install time
Create a new app user for each untrusted application
Stamp the entire application directory and files with permissions so that only the application user can read and write
Set quotas for the application user using ulimit/quota
During run time, launch the untrusted application using
Close all open file descriptors/handles
Use chroot to set the root to the application directory
Launch the application under the context of the application user
Thoughts on the above? Which approach is more secure than the other? Is there another approach that might work out better? We do not have a choice to move Android due to some reasons so we cannot use the sandboxing features that Android provides natively...
Let me know
Thanks,
The SELinux is a set of rules that are applies a bit similar as user rights even more complex. You can use it for each process to set a domain of that process and allow or deny nearly any access. It means access to files, network or processes/threads. That way it can be used as a kind of sandbox. However you have to prepare a rule set for each process or you can make a script that has to be run before sandboxed application to prepare rules itself.
If you want to take control on CPUs consumption, the SELinux has not a CPU planner because any rules have just one of two logical results 'allow' or 'deny' access. I recommend you 'cgroups' to control CPUs consumption.
The legato project uses a higher level sandboxing. It uses chroot and bind mount to contain applications. A key feature of it is a formal declarative api thus application components can talk to system service components under a managed security configuration. And services and applications can be added and removed as needed, as well as updated over the air. The application memory usage, processor share, storage, etc are also closely managed. It claims to make application development easier.
So far I had little concern about overall security considerations, because I have been developing only promotional and uncritical iPhone apps.
Currently, however, I'm working on a Mac application which requires a few more thougts about the matter, because it deals with sensitive user information.
While I know that I must take care to protect the data in its physical form (on disk), for example by encrypting it, I wonder how safe it is while it resides in memory in the course of normal use of the application.
Thus I'd like to know:
How safe is my application as long as it is built only upon framework elements such as NSTextField and Core Data?
How sensitive are Cocoa input elements to malicious attacks? What would be the best way to protect saved data which is stored using Core Data?
Objective-C is a dynamic language, which means that it is possible to replace classes and specific methods of classes at runtime. For example, this is how the 1Password plugin finds its way into Safari, and Dropbox finds it way into the Finder. It is currently possible for a malicious attacker to use the low level mach_inject API, or a number of other slightly higher-level methods, such as SIMBL or OSAX injection, to load code into your app. Once code is loaded into your app, the dynamic nature of Objective-C makes it possible in theory to replace NSTextField with a subclass of the attacker's choice, or specific methods in the class, including listening and storing user input. The secure version of NSTextField, which is designed for passwords, may have some protections against this, though I haven't found specific documentation to that effect. Security.framework and the keychain APIs in general do have protection for your data in memory, and they are not based on Objective-C, so it is significantly harder (although maybe still possible) to interfere with them.
To add to mgorbach's answer above (which is very good), Core Data can store data in four forms:
SQLite3 Database (most common)
.plist File (e.g. XML)
Binary File
In-Memory (non-persistent storage)
Neither .plist, Binary File, or SQLite are secure. .plist files can be easily read. A Binary file will be trickier, but AFAIK it's not using any encryption, and any Objective-C coder should easily be able to extract its contents. SQLite isn't secure either. Tools like SQLite Manager for FireFox, or Base for Mac, make it trivial to read Core Data SQLite data.
Since no Core Data storage methods are secure, your best bet is to encrypt data before committing it to disk.
This doesn't take into consideration any in-memory attacks. Of course, for this to be successful, a system typically has to already be compromised somehow.
If an end-user has FileVault enabled (encrypts their entire home folder), secure virtual memory enabled, their Firewall on, and a strong password, they're reasonably safe against many attacks.
I was thinking of making a small tool. It is not important what the tool will do. The important thing, is that the tool will need to store some sensitive information on the user's HDD. EDIT: The information that will be stored is USER'S information - I'm not trying to protect my own content, that I distribute with the app.
I understand that I need to encrypt this information. But then, where do I safely store the encryption password? It's some sort of an infinite recursion...
So, is there a way, to encrypt information on windows, and have windows securely manage the passwords? When I say windows I mean Windows XP SP2 or later.
I should also note, that users on the same system must not have access to other users information (even when they are both running my application).
I'm looking for both - .NET 2.0 (C#) and native (C/C++) solutions to this problem.
is there a way, to encrypt information on windows, and have windows securely manage the passwords?
CryptProtectData: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380261(v=vs.85).aspx
Using from .NET: http://msdn.microsoft.com/en-us/library/aa302402.aspx
Historically, Protected Storage (available in XP, read-only in vista+): http://msdn.microsoft.com/en-us/library/bb432403%28VS.85%29.aspx
You should consider using DPAPI for this purpose. It will encrypt your data with a special (internal) symmetric key which is on per-user basis. You don't even need to ask for passwords in this case, because different users on the system will have different keys assigned to them.
The downside of it might be that you can't recover the data if the user is deleted/Windows reinstalled (I believe that this is the case, not quite sure though). In that case encrypt the data with a "self-generated" key derived from the password and store the password in registry/file encrypted using DPAPI.
You can use the native encryption facility. Set the encrypt attribute on your folder or file (from the property page, click on the "advanced" button). Then you can set the users that can access the file (by default this only includes the file creator). The big advantage of this solution is that it is totally transparent from the application and the users points of view.
To do it programmatically: using the Win32 API, call EncryptFile() on the directory where you want to store your sensitive per-user data. From now on all newly created files within this dir will be encrypted and only readable by their creator (that would be the current user of your app). Alternatively you can use the FILE_ATTRIBUTE_ENCRYPTED flag on individual files at creation time. You can check encryption info from the explorer on the file's property page, and see that app-created files are correctly encrypted and restricted to their respective users. There is no password to store or use, everything is transparent.
If you want to hide data from all users then you can create a special app-specific user and impersonate it from your app. This, along with ACLs, is the blessed technique on Windows for system services.
You might want to look at Isolated Storage, which is a way of storing settings and other data on a per-application data automatically.
See an example and MSDN.
This is an alternative to storing normal settings in the registry, a better one in a lot of cases... I'm not sure how the data is stored to file however so you'd need to check, you wouldn't want it to be accessible, even encrypted, to other users. From memory only the app. that created the storage can open it - but that needs checking.
Edit:
From memory when I last used this, a good approach is to write a "Setting" class which handles all the settings etc. in your app. This class then has the equivalent of Serialize and DeSerialize methods which allow it to write all its data to an IsolatedStorage file, or load them back again.
The extra advantage of implementing it in this way is you can use attributes to mark up bits of the source and can then use a Property Grid to quickly give you user-edit control of settings (the Property Grid manipulates class properties at runtime using reflection).
I recommend you look at the Enterprise Library Cryptography Application Block. Check this blog post. Windows has a built in Data Protection API for encrypting data, but the Crypto Application Block makes it more straightforward.
Um, what you're trying to achieve is exactly what DRM tried to achieve. Encrypt something then give the user the keys (however obfuscated) and the crypto. They did it with DVDs. They did it with Blu-Ray. They did it with iTunes.
What you are proposing to do will never be secure. Your average lay person will probably not figure it out, but any sufficiently motivated attacker will work it out and discover the keys, the algorithm and decrypt the data.
If all you're doing is encrypting user data then ask the user for their password. If you're trying to protect your internal data from the user running the application you're S.O.L.
Erm hash the password? You don't need to store the real deal anywhere on the machine just a hashed password (possibly salted too). Then when the user enters their password you perform the same operation on that and compare it to the hashed one you've stored on disk.