Open eCard

Hello,

TL;DR
The statement Java is caused mostly by the Java Browser integration which is disabled nowadays by default and is not installed in the OeC deb package anyway.

The claim Java is insecure is very vague and indifferent. It's as calling all C programs more secure or stating all dogs have brown hair.

So jokes aside and look at it in more depth. First of all there is Java itself, which is basically an execution platform for programs. There may be security problems in Java itself and there may be problems in the application which uses Java. Flaws in Java itself are usually only exploitable in case the respecting feature is also used in the Program. Applets in the Browser and the Java Extension in the Browser are an exception to this rule, as they are available to every website you visit. Luckily these things are not included in the Browsers anymore.

Security in computer programs can go wrong in a lot of ways, especially very subtle ones. In general Java does a pretty good job at preventing a very large class of problems C and C++ programs struggle with, Buffer Overflows. Things have gotten way better there with stack randomization and all the other methods compilers try to weave into programs. In a wild guess I would say this is 90% or even more of the problems in most of todays software. What happens in this attack class is that someone can inject and then execute a malicious computer program into the running process via the input the process consumes.

So what does that have to do with Java. As already stated, Java generally makes it very hard for the programmer to write this kind of flawed code. However there have been cases where built-in functionality could be exploited to inject code into the Java process. The most prominent example is Java Serialization, which is now recommended to be avoided in public interfaces.

In order to assess the security of a program one must look at the use of external libraries and their vulnerabilities (have a look at the CVE database for details) and whether the troublesome features are used, the correct usage of everything, flaws introduced by the program itself and the system installation of the program.

In essence Security Bugs can hide everywhere and nobody can prevent them. There are techniques which rule out certain classes of bugs where different programming languages perform differently. While there is a pretty large number of bugs in Java, which is not really surprising as it contains a lot of code, this doesn't mean that it is insecure per se.

In the OeC we do not use the troublesome features of Java. Namely we use the bare core of Java, Reflections at some points, JAXP and JAXB. The external libraries in use are BouncyCastle, Apache HTTP Core, JNA for loading PKCS11 middlewares, and Jackson for JSON. They are all used in recent versions to include patches against security problems in theses libraries.

Coming back to the original question, my answer is the security of the OeC has little to do with the security of Java. We are very security aware and in case a major problem surfaces we will provide a new version which fixes the problem. In my opinion this is the best a software can do (which is the reason every major software company releases security patches every month and they are still trusted by the people).

In order to have a qualified measurement of the quality of the software, an external test of the software is needed. BSI TR-03124 defines a conformance test (Certification) for eID Clients, which is currently running for the so called eID Kernel which can be run on Android. From a security perspective this certification states that security relevant protocols are executed correctly and according to the specification.

Best regards
Tobias