I am trying to use Diffie Hellman for key exchange and AES to encrypt data with keys. Can anyone provide me a suitable work sample for android ?
I've actually been working on a similar problem lately myself. I don't have a working sample, but here are some points you should be aware of:
Android uses a partial Bouncy Castle package to handle most of its cryptography, but some people prefer to user their own cryptographic package (Spongy Castle is a commonly cited alternative) since Android's is incomplete. See the discussion in here.
If you choose to use Android's existing tools, you can access them through Cipher. Here is a useful list of algorithms Android supports.
Be aware that if you choose to use some non-Android Java crypto library, Android does not support all Java packages your library may need. See my (currently unanswered) question about how to deal with that in Spongy Castle.
Hope these help!
Related
I am interested in the hardware-backed KeyStore. I was looking at some documentation and I have noticed some contradiction.
The official documentation (here) confirms that all implementations must provide, among others, AES encryption.
Multiple implementations exist for the KeyStore. I looked at the Qualcomm one that is based on QSEE. As far as I understood from The keymaster glue (here), the QSEE-based KeyStore implements only RSA encryption.
Am I missing something ? I am considering the case that this keymaster glue is not up-to-date. In this case, where can I find the latest one ?
Thanks for any help.
Has anyone used CKO_VENDOR_DEFINED to create a key or a data object?
There is hardly any documentation (including the mother load from Oasis) about how to do it, or which attributes are applicable/not-applicable.
Unfortunately, but hopefully understandably, I can not describe exactly what I am trying to do.
But the gist of it is that I need to be able to have a bit more attribute<=>mechanism flexibility with our kind of keys and the ability to modify a key on the token.
I'd really appreciate any pointers or help.
You can take a look at OpenPGP extension to PKCS #11 where CKC_OPENPGP is defined as:
#define CKC_OPENPGP (CKC_VENDOR_DEFINED|0x00504750)
I've seen also commercial implementations introducing CK*_VENDOR_DEFINED extensions this way.
(AFAIK) vendor defined object types must be implemented inside the HSM unit firmware (in theory, the host-side cryptoki library could introduce some additional "virtual" object types, but this probably would not make any sense as the overall security model would stay the same -- because the host-side cryptoki code runs in an untrusted execution environment).
If you need more control than provided by the vanilla PKCS#11 you have some choices:
Use existing vendor extensions -- some vendors add their own extensions designed to solve common use-cases. Read your documentation or contact your vendor directly.
Implement a custom firmware -- some products allow the end-user to run a custom code inside the HSM device. You can implement your model this way.
SafeNet ProtectServer:
SafeNet ProtectServer HSMs offer a unique level of flexibility for
application developers to create their own firmware and execute it
within the secure confines of the HSM. Known as functionality modules,
the toolkits provide a comprehensive facility to develop and deploy
custom firmware.
Thales nShield:
Most nShield HSMs also support the unique ability to host critical
applications within the hardened security boundary, so you can
establish tamper-resistant business processes in addition to
protecting cryptographic operations.
Utimaco CryptoServer:
The CryptoServer Software Development Kit (SDK) is the professional
development environment for all Utimaco Hardware Security Modules. It
enables integrators and end-users to create specific applications,
e.g. proprietary algorithms, custom key derivation procedures or
complex protocols that run in the tamper-proof environment of the
CryptoServer Hardware Security Module. As the SDK provides full access
to the Utimaco base firmware, custom firmware modules can be developed
in a very short time frame.
Use some other technology -- do not use HSMs at all and leverage some other secure device. Specifically smartcards might be a viable alternative as some of them can be programmed (at least Java Card or MULTOS ones). On the other hand the performance and range of supported algorithms is quite limited here (depends on your use-case).
I found a few dead projects on this title.
Some referenced here.
I need one. But why are they all dead?
Is it bad idea to use such design? do you know of any good implementation which does this?
Some Smart Card vendors were providing CSP over PKCS#11 (not open source). In my opitnion, htis is not the best way of developping a CSP. These 2 standards are very different, and even more different since the venue of CNG and Credential Providers under 'recent' Windows OS.
I'm moving away from strict Android development and wanting to create iPhone applications. My understanding is that I can code the backend of iOS applications in C/C++ and also that I can use the NDK to include C/C++ code in Android apps. My question however is how? I've googled quite a bit and I can't find any clear and concise answers.
When looking at sample code for the NDK, it seems that all the function names etc. are Android (or at least Java) specific and so I would not be able to use this C/C++ backend to develop an iPhone frontend?
I'd appreciate some clarification on this issue and if at all available some code to help me out? (even just a simple Hello World that reads a string from a C/C++ file and displays it in an iOS and Android app).
Thanks guys
Chris
Note that I almost exclusively work on "business/utility/productivity" applications; things that rely heavily on fairly standard UI elements and expect to integrate well with their platform. This answer reflects that. See Mitch Lindgren's comment to Shaggy Frog's answer for good comments for game developers, who have a completely different situation.
I believe #Shaggy Frog is incorrect here. If you have effective, tested code in C++, there is no reason not to share it between Android and iPhone, and I've worked on projects that do just that and it can be very successful. There are dangers that should be avoided, however.
Most critically, be careful of "lowest common denominator." Self-contained, algorithmic code, shares very well. Complex frameworks that manage threads, talk on the network, or otherwise interact with the OS are more challenging to do in a way that doesn't force you to break the paradigms of the platform and shoot for the LCD that works equally badly on all platforms. In particular, I recommend writing your networking code using the platform's frameworks. This often requires a "sandwich" approach where the top layer is platform-specific and the very bottom layer is platform-specific, and the middle is portable. This is a very good thing if designed carefully.
Thread management and timers should also be done using the platform's frameworks. In particular, Java uses threads heavily, while iOS typically relies on its runloop to avoid threads. When iOS does use threads, GCD is strongly preferred. Again, the solution here is to isolate the truly portable algorithms, and let platform-specific code manage how it gets called.
If you have a complex, existing framework that is heavily threaded and has a lot of network or UI code spread throughout it, then sharing it may be difficult, but my recommendation still would be to look for ways to refactor it rather than rewrite it.
As an iOS and Mac developer who works extensively with cross-platform code shared on Linux, Windows and Android, I can say that Android is by far the most annoying of the platforms to share with (Windows used to hold this distinction, but Android blew it away). Android has had the most cases where it is not wise to share code. But there are still many opportunities for code reuse and they should be pursued.
While the sentiment is sound (you are following the policy of Don't Repeat Yourself), it's only pragmatic if what you can share that code in an efficient manner. In this case, it's not really possible to have a "write once" approach to cross-platform development where the code for two platforms needs to be written in different languages (C/C++/Obj-C on iPhone, Java for Android).
You'll be better off writing two different codebases in this case (in two different languages). Word of advice: don't write your Java code like it's C++, or your C++ code like it's Java. I worked at a company a number of years ago who had a product they "ported" from Java to C++, and they didn't write the C++ code like it was C++, and it caused all sorts of problems, not to mention being hard to read.
Writing a shared code base is really practical in this situation. There is some overhead to setting up and keeping it organized, but the major benefits are these 1) reduce the amount of code by sharing common functionality 2) Sharing bug fixes to the common code base. I'm currently aware of two routes that I'm considering for a project - use the native c/c++ (gains in speed at the expense of losing garbage collection and setting targets per processor) or use monodroid/monotouch which provide c# bindings for each os's platform functionality (I'm uncertain of how mature this is.)
If I was writing a game using 3d I'd definitely use approach #1.
I posted this same answer to a similar question but I think it's relevant so...
I use BatteryTech for my platform-abstraction stuff and my project structure looks like this:
On my PC:
gamename - contains just the common code
gamename-android - holds mostly BatteryTech's android-specific code and Android config, builders point to gamename project for common code
gamename-win32 - Just for building out to Windows, uses code from gamename project
On my Mac:
gamename - contains just the common code
gamename-ios - The iPhone/iPad build, imports common code
gamename-osx - The OSX native build. imports common code.
And I use SVN to share between my PC and Mac. My only real problems are when I add classes to the common codebase in Windows and then update on the mac to pull them down from SVN. XCode doesn't have a way to automatically add them to the project without scripts, so I have to pull them in manually each time, which is a pain but isn't the end of the world.
All of this stuff comes with BatteryTech so it's easy to figure out once you get it.
Besides using C/C++ share so lib.
If to develop cross-platform apps like game, suggest use mono-based framework like Unity3D.
Else if to develop business apps which require native UI and want to share business logic code cross mobile platforms, I suggest use Lua embedded engine as client business logic center.
The client UI is still native and get best UI performance. i.e Java on Android and ObjectC on iOS etc.
The logic is shared with same Lua scripts for all platform.
So the Lua layer is similar as client services (compare to server side services).
-- Anderson Mao, 2013-03-28
Though I don't use these myself as most of the stuff I write won't port well, I would recommend using something like Appcelerator or Red Foundry to build basic applications that can then be created natively on either platform. In these cases, you're not writing objective-c or java, you use some kind of intermediary. Note that if you move outside the box they've confined you to, you'll need to write your own code closer to the metal.
I've been reading about Stanford's Secure Remote Password protocol, and it looks ideal for the sort of environment in which iPhone apps run. Unfortunately, I haven't been able to find a good Objective-C implementation of the protocol. Nor, as far as I can tell, do the crypto libraries in the SDK implement it.
Does anyone know of such an implementation?
Failing that, what's my best bet going to be, do you think? I could try to build OpenSSL into my app, but that feels like a really big thing to add for this one little piece. I could try to translate the JavaScript or Java implementations into Objective-C, but that violates the #1 rule of crypto (use a known, tested implementation).
Couple of follow-up items: first, it should probably be obvious from context, but I'm going to need something that is compatible with closed-source commercial usage (the JavaScript implementation I linked to, I later noticed, is AGPL).
Also, assuming I do end up going with OpenSSL, I'm having real trouble finding an example of using it to do SRP. Their site claims the code is in there, but I can't find any evidence of it, either in the OpenSSL documentation, or grepping the source code (v 0.9.8k). (Or am I seriously misreading things, and I still have to apply one of their patches to the OpenSSL source?)
EDIT:
What I could really use at this point is ready-to-use code, a fairly complete recipe, or some kind of example of using SRP in OpenSSL. I'm pretty sure I could cobble something together from scratch with the protocol docs, but I'm really trying to avoid reinventing the wheel, if I can help it.
The OpenSSL and GnuTLS implementations of SRP-TLS are the only C-based ones I know that are maintained (TinySRP hasn't been updated since 2001, and there have been many security notices against the underlying OpenSSL version it's based on, though I don't know if they impact TinySRP itself).
That said, every iPhone project I've built has eventually had to include a copy of OpenSSL for something or other. I recommend just biting the bullet and using it. The instructions you link to work fine.
Personally, I build OpenSSL into a Universal library using lipo that has both arm and x86 versions. That way I can link to a single .a for both Simulator and Device. The lipo is very easy. Just build the two libraries and glue them together. Here's the rule from my Makefile:
/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/lipo \
-create \
-arch armv6 iPhoneOS$(SDK_VER)/lib/$(1) \
-arch i386 iPhoneSimulator$(SDK_VER)/lib/$(1) \
-output iPhoneUniversal$(SDK_VER)/lib/$(1)
The implementation of SRP in iOS platform requires OpenSSL, so a good way is to install OpenSSL via pods.
There's a good C implementation of srp by hoccer called csrp.
I have written an iOS wrapper for this implementation, which you can find here. But I must mention that csrp is already well implemented and self-explained from its documentation.