Is that possible for a javacard applet to download and install another applet?
Is that possible for an applet to send APDUs (information) to another applet?
If so, can anyone lead me to proper documentations to begin?
Is that possible for a javacard applet to download and install another applet?
No, that's not possible, there is simply no API for it. In all the examples from Global Platform - which is probably more relevant than the Java Card specifications - the applet data is loaded through APDU commands. There is an Applet.install method in the Java Card API of course, but it gets called by the system and cannot be used from another applet - not even a security domain, as far as I know.
Is that possible for an applet to send APDUs (information) to another applet?
Yes, you can have one class implement the Shareable interface and share it through the getShareableInterfaceObject method. All Java Card tutorials will include this.
The APDU buffer cannot be shared, but it doesn't need to, you can simply access it through the APDU methods. From the API:
The Java Card runtime environment designates the APDU object as a temporary Java Card runtime environment Entry Point Object (See Runtime Environment Specification, Java Card Platform, Classic Edition, section 6.2.1 for details). A temporary Java Card runtime environment Entry Point Object can be accessed from any applet context. References to these temporary objects cannot be stored in class variables or instance variables or array components.
Please do read tutorials or buy the old but still valid Java Card technology for Smart Cards. It's old, but the core principles are still completely valid, and most other basic things can be learned by studying the API.
Related
My question is in two parts:
1-From applet point of view, does it differ to write an applet to work with mobile NFC? if so, what are the differences?
2-what changes are required (I mean Global Platform environment) to be done in order to communicate with the applet using mobile NFC?
My Target is to write an applet and access it using Single Wire Protocol (SWP) of mobile connected to NFC antenna. Is there any previously done project I can learn from? Where is the point to begin this?
I am currently writing a library that can be used by a wayland client software. The library is intended to be mostly independent of the client toolkit (currently only Qt, but other wayland-enabled toolkits should be able to use it as well). It requires only a wl_display pointer passed to the initialization routine, which is retrieved from the GUI toolkit. After the initialization is done, the library should be able to work without contact to the toolkit to make it cross-toolkit compatible.
The problem arises when my library requires a couple of global object proxies (ie. wl_output). The library uses a custom wl_registry to bind custom proxies to required global objects. However, from the server's perspective all proxies to these objects are equivalent. When events that contain object proxies are sent by the server, they may contain either toolkit's or library's proxy reference. This leads to problems because there is no easy way to differentiate these. When the toolkit receives such events, it blindly assumes that the user data of the proxy belongs to the toolkit and uses it, even if the proxy it received belongs to my library.
Is there any way to reconcile such unrelated code, or is such use beyond the scope of the wayland library/protocol and I should re-design my solution?
Qt Wayland developer here.
When the toolkit receives such events, it blindly assumes that the user data of the proxy belongs to the toolkit and uses it, even if the proxy it received belongs to my library.
Are you sure about this part? When you bind to the global, you create a new proxy object, I don't see how the toolkit can know about this... Or are you talking about the arguments in events sent by globals. I.e. wl_pointer.set_cursor and the like? Would be nice if you could be more specific about what goes wrong...
I am trying to replace HSM(s) with my software-only application and integrate with PKCS11. The problem I have with that is all of PKCS api functions deal with slots and tokens which are not a part of my software application. Are there examples out there that I can look up to see how a software application can be used to imitate an HSM and integrate with PKCS ?
When you are dealing with HSM's you have to deal with slots and tokens. You have to modify your software slightly to accommodate this.
There are 2 ways you can use the PKCS#11, PKCS#11 Wrapper or PKCS#11 Provider. The Wrapper is the api that calls the native functions of the HSM library (.dll or .so) directly. The Provider uses the Wrapper under the hood, but gives you the convenience of using it with Java KeyStore api.
Considering your case, the Wrapper might not be fit for you, because it involves writing new classes to integrate with the HSM. You could use the provider.
Java has very good documentation of the PKCS11 Provider here. There is also a very good third-party library called IAIK, here is their provider documentation. Even though you use the Provider in your software application, trivial code changes are inevitable.
Where ever you have used the KeyStore api, you may have to make changes there. And initially, when your software loads, you have to load a configuration file for the PKCS11 provider that tells which slot number and the token to connect to.
IAIK has very good examples too, and their provider library is only free for development purposes.
I'm trying to build an app using IBM Bluemix that takes user input in an HTML form, processes it in a server-side Java application, and returns the processed data to the user. This kind of thing is really simple to implement using HttpServlet, but that class doesn't seem to exist in IBM's jdk. Where can I find this class?
Apologies, I'm very new to any web development concepts beyond building a static HTML website.
HttpServlet is not part of the Java Standard Edition runtime, it's provided by your application server--Tomcat or WebSphere Liberty, for instance. At development-time, you'll need one of these on-hand to provide you that class to compile against.
I presume you are using "Liberty for Java" runtime. I believe HttpServlet is part of Liberty, and the default configuration of Liberty runtime includes the "servlet-3.0" feature (see here). There's also mention of it in the Liberty documentation here. So you should be able to use it in Bluemix.
I have some doubt regarding gwt file handling.
How to do file handling in gwt(at server side). How to create simple file. I mean which class is particularly used for CREATING and HANDLING it ??
Where is the file created. Is it under server package or somewhere else ??
How to resolve serialization and serialization problem. ??
GWT is a client-side technology. It's server-agnostic (and can also be used client-only, e.g. mobile apps, Chrome apps, browser extensions). GWT-RPC and RequestFactory use Java servlets by default (nothing precludes implementing RequestFactory in other languages/technologies) but have otherwise no requirement or limitations.
So, server-side, it's all just Java in most of the cases, and depends on your deployment target (e.g. AppEngine restricts what you can do, servlet containers can also have security policies in place, and you're of course dependent on authorizations at the filesystem level)
Since GWT is a pure client-side technology you have all possible options like plain Servlets for example. You are not limited in any way in picking the upload approach.
However, there is a number of open source projects, which make possible to use nice features like progress bars and multiple file uploads. And those come integrated with some GWT widgets as well. Check this project for example http://code.google.com/p/gwtupload/