I need a way to protect a private key on a mobile device.
I know in "Writing Secure Code" chapter "Protecting Secret Data" says "Windows CE" cannot be used in secure environments. But the book is many years old now, 2003.
Is this still the case? Tell me it ain't so. There has to be a way to secure a private key today.
The DPAPI is embodied in a set of Win32 functions, CryptProtectData and CryptUnprotectData. These functions are available on Windows CE and Windows Mobile platforms (see links), although I don't know at what version they added support.
The .NET wrapper for the DPAPI is the ProtectedData class in System.Security.Cryptography namespace (assembly System.Security.dll). However, I don't think .NET Compact Framework implements this yet, so you'll have to use P/Invoke if using .NET.
If the a user has access to a device, then no you can not 100% securely store a key. You can raise the bar but you cannot remove it.
You have to externalize the access to the key, e.g. User entered username and/or password or sent to the device via another method (e.g. asymmetric encryption over a network connection). Which is what the security for Windows Mobile programmers recommends.
Any way you store the key on the device can be reverse engineered. This includes the use of CryptProtectData and CryptUnprotectData API.
What's wrong with using standard encryption algorithms?
http://www.windowsfordevices.com/news/NS5217487259.html?kc=rss
Webcast covers security for Windows Mobile programmers
This looks like it will be good.
Related
I know this type of question has been done to death.
My question relates to protecting my code that is installed on a clients PC.
I know the answers are to obfuscate, get a patent, put code on my server, accept it will be hacked, consider that my code is not THAT important or unique etc..
BUT, I am supplying the Windows PC to the client(s) with my software pre-installed.
It is a C# .Net app.
Under these circumstances where I am supplying the hardware is there any other 'tricks' I can use to prevent decompilation my code?
Thanks
Use BitLocker (at rest encryption) on the hard disk and a user for your client with limited privileges. Don't share the admin user's password with your client.
How can I develop applications that use Arm's trust zone? Specifically, I want to develop a program that can save sensitive data in the secure world.
Should this program run in the normal world or the secure world? I know there are trustlets in the secure world, do I need to develop trustlets? Are there SDK or API
that I can use to directly interact with an existing secure world os or do I need to compile and install my own secure os?
Any advice will be greatly appreciated.
Thank you!
There are two extremes. These are documented in the Software overview chapter of ARMs Security Technology: Building a Secure System using TrustZone Technology.
APIs
At the one end of the spectrum, there is only a set of APIs which can be called from the normal world. This is detailed in the SMC calls for Linux. For instance, if the device contains a public-private key, an API call could sign data. The normal world would never have access to the private key, but anyone can verify that the device is original by verifying the signature. So the normal world is free to forward this request over any communications interface. This maybe part of authenticating a device.
Co-operative OSs
In this mode, there is a full blown OS in both the secure and normal world (called TEE and REE elsewhere). The OSs must co-operate with interrupts and scheduling. They may also use SMC calls, lock free algorithms and semaphores along with shared memory.
ARM recommends using the FIQ for the secure world and to leave the IRQ for the normal world. Specifically, there are settings to stop the normal world from masking the FIQ ever. All of these issue rely on the type of IPC, scheduling, interrupt response, etc that the system needs.
The simplest Secure scheduler would always pre-empt the normal world. Only the idle task would yield the CPU to the normal world. A more flexible solution would have the schedulers co-operate so that both worlds can have higher and lower priority tasks.
The better way is install a REE OS and a TEE OS in one device. When a program wants to do some sensitive things, the device will change to TEE OS, so you can deal with sensitive date securely. When you have done with sensitvie date, device will change to REE OS.
But implementing two OS switch on a device is a tough work.
Operating Systems such as MobiCore already exist and have been deployed on mass market devices such as Samsung Galaxy S3.
MobiCore is an OS that runs alongside Android, so trustlets (= MobiCore apps) can communicate with Android apps via a set of system calls to the MobiCore driver, which is the part of the Android OS in charge of communicating with the trusted execution enviromnent.
If you are looking to develop trustlets for MobiCore as explained above, you must become a MobiCore developer, which you could theoretically do by signing up as a developer for MobiCore's Trustonic venture.
If you wish to use ARM's TrustZone technology on your own device / dev board with an open-source secure OS, perhaps you can use OpenVirtualization's SierraTEE, which seems to be compiled for Xilinx Zynq-7000 AP SOC and also compatible with Android as the rich OS.
You can use OPTEE(Open Sourec Portable Trusted Execution environment) OS. If you are looking for trusted execution environment application examples, which are also know Trusted Applications(TA), then you can check this optee trusted applications examples repository and this TA using OP-TEE and Comcast Crypto API.
Optee os provides following APIs for writing Trusted Applications:
Secure Storage APIs for secure storage
Cryptographic Operations APIs for encryptiion, decryption of secure credentials and data
Secure Element API which help in hosting applications or applets on tamper-resistant platform
Time APIs
Arithmetical APIs
For client side or normal world optee provides:
Tee client side Apis
You can refer documentation here.
I am new to javacard programming.While working with owner pin in my javacard application, I referred that "PIN interface which is in javacard framework package does not make any assumptions about where the data for the PIN value comparison is stored".
And I want to know the following,
Can I get the exact location where my owner pin is stored? If I can how to do that? How to export my updated owner pin?
I have an applet of my javacard application. Now how can I load & install into my javacard.I know there are tools available and come with the smartcard itself. But I want to install without tool and only through apdu commands. Is there any procedure to do that? If so how to do that?
Sorry, you cannot retrieve the OwnerPIN, probably because of security reasons. You will have to implement the PIN interface yourself if you want to do that, but there are about 8 pitfalls in the implementation regarding side channel attacks and such. If you can't think of about 8 attacks, don't go there. Generally, retrieving the PIN as data is not what you should want.
Of course there is a procedure to do that: create your own GlobalPlatform API - you might want to look at open source examples though, such as gjp.
As an extreme hack, you could store the PIN in as the value of a secret key object (which are generally well protected).
Regarding the installation of applets I have a good and bad news for you:
The general process of command for installing is standardized by Global Platform, however that refers only to those commands you send to the Cardmanager-Applet.
However AFAIK there is no vendor independent standard of the Cardmanager-AID. Additionally you have to authenticate yourself to the Cardmanager applet before you can use it. On developer cards this is usually a simple key like 404142434445464748494a4b4c4d4e4f (hex) as used for example by JCOP cards for the first DES key.
Additionally this authentication key can be changed by the card owner. Therefore on non-developer cards you don't have access to the Cardmanager.
Is it possible to write a mobile application with J2ME and whenever we want to implement a functionality not offered by J2ME call native mobile API ? (kind of like what is done with .NET, whenever you need something not provided, you just call the Win32 API from the .NET platform).
While JNI is not officially supported in J2ME, the Symbian implementation of J2ME obviously uses something very similar.
Since most J2ME APIs have a corresponding Symbian OS C++ API, what Symbian did (a lot) is develop adaptation layers between the 2.
Between that and the new modular architecture of the IBM J9 virtual machine (from Series60 3rd edition feature pack 2 onward), it is technically possible to add a new API to the virtual machine without actually needing to recompile most of a handset firmware.
However, third party developers simply are not allowed to do it without a lot of help from the handset manufacturer.
A loopback socket connection is the solution that people have tipically implemented to transfer data accross the language barrier. Large-scale deployment is not the easiest task, though, as you technically need to install 2 applications on the device. Once you understand the threading model of the Symbian J2ME implementation, you also realize how ugly and inefficient a hack it is.
When you reach that kind of issue, it's time to learn Symbian OS C++ and do it right.
No. That's not possible with Java ME.
Only sort of. Actually it is possible but not directly. You can write a native server that listens on a local socket and send requests to it from your Java MIDlet. Someone even released a framework to do this called MIDP-JNI (as opposed to real JNI). Obviously the form of the solution imposes some limitations on what you can do with it but it isn't actually impossible.
Be aware that using this approach can make your application much more complex to debug.
If you are specifically looking out for Nokia/Symbian, then APIBridge http://wiki.forum.nokia.com/index.php/J2ME_API_Bridge_Interface could be a solution. Typically it is the 'official' version of 'native server on local socket' kind of thing. The APIBridge is 'extensible' & you can write your own 'plugins' for your suitable 'low-level' task.
What are some platform-specific API's that web browsers use to securely save passwords with reversible encryption on local systems?
Since they must be able to reproduce the exact characters to pass up to a web site, the data can't be a one-way hash. My initial thought is there are system methods which utilize your current authentication data to perform encryption/decryption, but do not give access to applications to read it (your system login data) directly. I'm wondering what these are on different platforms (Windows, Linux, OS X) and how well they protect the information if the hard drive is accessed directly; i.e. a stolen laptop hard drive is placed into another computer or analyzed via a Live CD.
Here's how google chrome does it. Looks like they use CryptProtectData on windows.