I am using following OpenSSL library for android
My application need to support TLS 1.2 version(TLSv2).I want to know Does above library support TLS 1.2 and above library is build upon which Openssl version?
According to the code this is only OpenSSL 1.0.0a. TLS1.2 support was added with OpenSS L1.0.1, so this library does not support TLS1.2. BTW, TLS1.2 is TLSv1_2 and not TLSv2.
I am using following OpenSSL library for android
According to Steffen, its a dwonlevel version. You might consider building it yourself. You can find information on OpenSSL's wiki: OpenSSL and Android.
Or, you could fetch 1.0.1h from this Github: Noloader GitHub. The GitHub has OpenSSL 1.0.1h built for both API 14 (GCC 4.6 toolchain) and API 18 (GCC 4.8 toolchain).
Does OpenSSL library support TLS 1.2 and above library is build upon which Openssl version?
If you are working with a modern version of OpenSSL, then TLS 1.2 will be available by default (unless on a distro like Debian and Ubuntu, which disables TLS 1.1 and TLS 1.2 prior to about 2014). If the distro has not disabled the protocol, then you should perform the following to tighten up the protocols:
/* Useless return value ??? */
SSL_library_init();
const SSL_METHOD* method = SSLv23_method();
if(!(NULL != method)) handleFailure();
SSL_CTX* ctx = SSL_CTX_new(method);
if(!(ctx != NULL)) handleFailure();
/* Cannot fail ??? */
const long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_COMPRESSION;
SSL_CTX_set_options(ctx, flags);
The code above provides you with TLS 1.0 and above. You will be fine with TLS since its ubiquitous (hence, no need for SSLv3). The code will also ensure TLS 1.3 is available once its standardized (the IETF is standardizing it now). And it disables compression because of attacks like CRIME.
There's also an opportunity to tighten up the cipher suites. You should provide 16 or 20 or so approved ciphers and no more. There's no reason to be using export grade ciphers, RC4 or MD5 in 2014. Plus, if you advertise all 80+ ciphers, it causes some appliances to break like older F5's and IronPorts. The applicances used a fixed-size buffer that was too small, and they choke/hang on the ClientHello.
Related
I am interested in using the AServiceManager_get/addService() APIs that are made available via the NDK implementation of binder, libbinder_ndk.
The sources for this can be found here for 10.0.0r30 - API29, and in your AOSP tree at:
$SDK/frameworks/native/libs/binder/ndk/
However, the libbinder_ndk.so bundled with the latest r21c NDK does not have all of these APIs exported. Many are, but the get/add services endpoints are not available. The libbinder_ndk.so for API29 can be found at:
$NDK/platforms/android-29/$PLAT/usr/lib/libbinder_ndk.so
As well as the sysroot directories of each respective toolchain, but only for API29
$NDK/toolchains/llvm/prebuilt/$HOST/sysroot/usr/lib/$PLAT/29/libbinder_ndk.so
But the symbols are of course available if you build the AOSP tree for this same release:
$ readelf --wide -s libbinder_ndk.so | grep AService
180: 000000000000e148 256 FUNC GLOBAL DEFAULT 15 AServiceManager_addService##LIBBINDER_NDK
181: 000000000000e248 244 FUNC GLOBAL DEFAULT 15 AServiceManager_checkService##LIBBINDER_NDK
224: 000000000000e33c 244 FUNC GLOBAL DEFAULT 15 AServiceManager_getService##LIBBINDER_NDK
In fact, a search of the documentation returns no results for these APIs, but the source has been available since 2018-08-20 according to the blame records.
Am I missing something?
The reason they are not exported is because they are not a part of the app API surface. They exist for vendor and APEX modules. Those domains do not have the same API permanence guarantees that apps do (read: they might disappear in any given release).
I am trying to implement the SRP protocol for a Server and Client app in Android. I checked that OpenSSL supports SRP protocol but how can I access OpenSSL APIs from the Android app? Is JNI the only way to access the OpenSSL C APIs? Are there any samples that I can refer how to build the OpenSSL for Android and to call the OpenSSL SRP APIs through JNI.
I am trying to implement the SRP protocol
I like SRP, too. Be sure to use Thomas Wu's specification, or version 6 of the IETF's specification.
OpenSSL supports SRP protocol but how can I access OpenSSL APIs from the Android app? Is JNI the only way to access the OpenSSL C APIs?
Yes.
You might also look to Bouncy Castle for a Java implementation.
Are there any samples that I can refer how to build the OpenSSL for Android...
See OpenSSL and Android on the OpenSSL wiki.
Android carries around a copy of OpenSSL, but I'm not sure of it includes SRP.
Are there any samples that I can refer ... to call the OpenSSL SRP APIs through JNI.
Not that I am aware. The closest you will find is the source code to s_client, options like -srpuser <user>, and data structures like srp_arg_st, and functions like ssl_srp_verify_param_cb and ssl_give_srp_client_pwd_cb.
You can find the source code for s_client at <openssl src dir>/apps/s_client.c. Line 1365 looks interesting (from 1.0.2h):
# ifndef OPENSSL_NO_SRP
if (srp_arg.srplogin) {
if (!srp_lateuser && !SSL_CTX_set_srp_username(ctx, srp_arg.srplogin)) {
BIO_printf(bio_err, "Unable to set SRP username\n");
goto end;
}
srp_arg.msg = c_msg;
srp_arg.debug = c_debug;
SSL_CTX_set_srp_cb_arg(ctx, &srp_arg);
SSL_CTX_set_srp_client_pwd_callback(ctx, ssl_give_srp_client_pwd_cb);
SSL_CTX_set_srp_strength(ctx, srp_arg.strength);
if (c_msg || c_debug || srp_arg.amp == 0)
SSL_CTX_set_srp_verify_param_callback(ctx,
ssl_srp_verify_param_cb);
}
# endif
And the srp_arg_st from around line 475:
/* This is a context that we pass to all callbacks */
typedef struct srp_arg_st {
char *srppassin;
char *srplogin;
int msg; /* copy from c_msg */
int debug; /* copy from c_debug */
int amp; /* allow more groups */
int strength /* minimal size for N */ ;
} SRP_ARG;
Obviously, OpenSSL is native C and does not use JNI.
How to call OpenSSL SRP APIs ...?
At the highest levels, you need to do two or three things in C. Think of them as a supplement to a the standard TLS Client from the OpenSSL wiki. (I'm side stepping Android/JNI part).
First, you need to set the SSL_CTX_set_srp_*_callback. The callbacks are how the library prompts your TLS client for information like username and password.
Second, you remove all non-SRP cipher suites. That means you do not use a cipher list like "HIGH:!aNULL:!MD5:!RC4".
Third, you use only SRP cipher suites. I'm not sure how the cipher list would look when using "HIGH:!aNULL:...". But you can hand pick the list of ciphers with:
$ openssl ciphers -v | grep SRP | grep -v DSS | cut -f 1 -d ' '
SRP-RSA-AES-256-CBC-SHA
SRP-AES-256-CBC-SHA
SRP-RSA-AES-128-CBC-SHA
SRP-AES-128-CBC-SHA
SRP-RSA-3DES-EDE-CBC-SHA
SRP-3DES-EDE-CBC-SHA
If you go to the openssl ciphers man page, then you should be able to cross reference SRP-RSA-AES-256-CBC-SHA with the name needed in the cipher list. Unfortunately, the SRP cipher suites are missing.
However, you can go to ICANN's TLS paramter registry and get the names:
SRP-RSA-AES-256-CBC-SHA → TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA
SRP-AES-256-CBC-SHA → TLS_SRP_SHA_WITH_AES_256_CBC_SHA
SRP-RSA-AES-128-CBC-SHA → TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA
SRP-AES-128-CBC-SHA → TLS_SRP_SHA_WITH_AES_128_CBC_SHA
SRP-RSA-3DES-EDE-CBC-SHA → TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA
SRP-3DES-EDE-CBC-SHA → TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA
So the string you would use for SSL_CTX_set_cipher_list or SSL_set_cipher_list:
static const char const PREFERRED_CIPHERS[] =
"TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA:TLS_SRP_SHA_WITH_AES_256_CBC_SHA:
TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA:TLS_SRP_SHA_WITH_AES_128_CBC_SHA:
TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA:TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA";
I am in the process of setting up a headless server that builds Phonegap hybrid apps for Android using data - JS, CSS, HTML + a keystore - provided by the user. I want to institute some basic client side checks to ensure that the keystore being uploaded is valid. For JKS files I have found that I can do a rudimentary check by ensuring that the first four bytes of the supplied file are the MAGIC number 0xFEEDFEED as specified here. I realize that this does not eliminate the possibility that the user supplies garbage but it does help as a preliminary client-side screen. I would like to implement similar screening for the PKCS12 and BKS keystores but have been unable to find any explanations for those file formats. I'd be most grateful to anyone who might be able to provide some information on the subject.
First, two things to take into consideration:
JCEKS is missing in your list (more secure version of JKS, magic number is 0xCECECECE).
There are two incompatible versions of BKS. The newer version was introduced with Bouncy Castle 1.47, replacing the older version completely. Therefore BKS keystores that were generated with BC 1.47 or newer cannot be read with BC 1.46 or older. In BC 1.49 a new keystore type "BKS-V1" has been added, that is compatible with the older format (see BC Release Notes).
BKS format starts with a version number in the first 4 bytes and ends with a null byte and a SHA-1 hash (20 bytes).
PKCS#12 is not so easy to detect. You will have to parse it as an ASN.1 structure (see RFC 7292):
PFX ::= SEQUENCE {
version INTEGER {v3(3)}(v3,...),
authSafe ContentInfo,
macData MacData OPTIONAL
}
If the file cannot be parsed as the above ASN.1 structure, it's not PKCS#12.
For a more accessible explanation of the PKCS12 format check here.
From developer.android.com
The latest release of the NDK supports the following instruction sets:
ARMv5TE, including Thumb-1 instructions (see docs/CPU-ARCH-ABIS.html for more information) ARMv7-A, including Thumb-2 and VFPv3-D16 instructions, with optional support for NEON/VFPv3-D32 instructions (see docs/CPU-ARM-NEON.html for more information) x86 instructions (see docs/CPU-X86.html for more information) MIPS instructions (see docs/CPU-MIPS.html for more information)
.........
Does that mean if I run my app on a mobile phone having ARM-9 or ARM-11, there will be some performance penalty?
I'm trying to use BouncyCastle with android to implement ECDH and EL Gamal. I've added the bouncycastle jar file (bcprov-jdk16-144.jar) and written some code that works with my computers jvm however when I try and port it to my android application it throws:
java.security.NoSuchAlgorithmException: KeyPairGenerator ECDH implementation not found
A sample of the code is:
Security.addProvider(new org.bouncycastle.jce.provider.BouncyCastleProvider());
java.security.KeyPairGenerator keyGen = org.bouncycastle.jce.provider.asymmetric.ec.KeyPairGenerator.getInstance("ECDH", "BC");
ECGenParameterSpec ecSpec = new ECGenParameterSpec("prime192v1");
keyGen.initialize(ecSpec, SecureRandom.getInstance("SHA1PRNG"));
KeyPair pair = keyGen.generateKeyPair();
PublicKey pubk = pair.getPublic();
PrivateKey prik = pair.getPrivate();
I then wrote a simple program to see what encryption algorithms are available and ran it on my android emulator and on my computers jvm the code was:
Set<Provider.Service> rar = new org.bouncycastle.jce.provider.BouncyCastleProvider().getServices();
Iterator<Provider.Service> ir = rar.iterator();
while(ir.hasNext())
System.out.println(ir.next().getAlgorithm());
On android I do not get any of the EC algorithms while ran normally on my computer it's fine.
I'm also getting the following two errors when compiling for a lot of the bouncy castle classes:
01-07 17:17:42.548: INFO/dalvikvm(1054): DexOpt: not resolving ambiguous class 'Lorg/bouncycastle/asn1/ASN1Encodable;'
01-07 17:17:42.548: DEBUG/dalvikvm(1054): DexOpt: not verifying 'Lorg/bouncycastle/asn1/ess/OtherSigningCertificate;': multiple definitions
What am I doing wrong?
You probably want Spongy Castle - a repackage I made of Bouncy Castle specifically targeted for Android. As noted here:
http://code.google.com/p/android/issues/detail?id=3280
...the Android platform unfortunately incorporates a cut-down version of Bouncy Castle, which also makes installing an updated version of the libraries difficult due to classloader conflicts - even when you add your full BC jar, you don't get the additional classes you added.
Spongy Castle is a full replacement for the crippled versions of the Bouncy Castle cryptographic libraries which ship with Android. There are a couple of small changes to make it work on Android:
all package names have been moved from org.bouncycastle.* to org.spongycastle.* - so no classloader conflicts
the Java Security API Provider name is now SC rather than BC
I don't know if this answers your question, but some of the BouncyCastle libraries are already in the Android SDK. Perhaps the error about ambiguous class is because BouncyCastle is already included in the emulator.
It seems you can use it via the javax.crypto.Cipher class.
If you browse the Android code you will see not all BouncyCastle functionalities are included.
see libcore/security/src/main/java/org/bouncycastle/jce/provider/BouncyCastleProvider.java
In particular the output of ECDH is commented out, which means at compilation it will be completely left out from the android jar file.