The Java Card development kit allows you to write code that can run on a smart card. For those that have written code using Java card you will know that the only resemblance to Java is the code style. Almost the entire class library, the garbage collection etc. is different. You also need to understand the APDU format since the coding is done at quite a low level to the smart card.
When writing code for a mobile phone typically the code is written to run on the phone itself. With the Java card technology this code can now run on the SIM card. This has a huge advantage in security since a smart card by nature is very secure. Different portions of the card can only be accessed with certain PIN's and some parts of the card can only be written to when the card is created.
Typically for a mobile banking application the transactions need to be secure. There is no more secure way than signing and encrypting the transaction using a key that is resident on the SIM card. For a SIM browser based application this is typically how it is done, but for an application on running on the phone it is tricky to utilize the SIM cards inherent security.
With Java Card 3.0 it is now possible to write an application using classes and methods that a typical Java developer is used to that can run on the SIM card and to utilize all the security features of the SIM card. This is going to open up the SIM card to a huge group of Java developers to write secure applications.
The specs can be found here http://java.sun.com/products/javacard/3.0/
Wednesday, July 30, 2008
Monday, July 21, 2008
Installing Glassfish onto Solaris 10
Check the correct version of java is running
* Open a terminal window
* Use bash
type:
bash* Get the version of java
type:
java -version* Check the version is java 1.6 or above
Upgrading java version
* ftp the install package of the JDK to /opt/dropzone
* Give the install execution access
type:
chmod a+x jdk-6u10-beta-bin-b24-solaris-i586-14_may_2008.sh* Install the JDK by running the install script
type:
./jdk-6u10-beta-bin-b24-solaris-i586-14_may_2008.sh* Check that the installation work by doing a directory listing
type:
ls -l* Move the installation to /usr/jdk/instances
type:
mv ./jdk1.6.0_10 /usr/jdk/instances* Check that in moved successfully
type:
ls -l /usr/jdk/instances* Move the latest symbolic link to point to the new installation
type:
rm /usr/jdk/latest; ln -s instances/jdk1.6.0_10 /usr/jdk/latest;* Check that the latest symbolic link points to the new installation
type:
ls -l /usr/jdk/latest* Move the java symbolic link to point to the new installation
type:
rm /usr/java; ln -s jdk/latest /usr/java;* Check the new java version is being picked up
type:
java -versionCopy the relevant deployment of Glassfish to the server
* ftp the install package of Glassfish to /opt/fundamo/dropzone
* Install Glassfish by running the install jar
type:
java -Xmx256m -jar glassfish-installer-v2ur2-b04-sunos_x86.jar* Check that the installation work by doing a directory listing
type:
ls -l* Move the installation to /opt
type:
mv ./glassfish /opt* Change directory to /opt/glassfish
type:
cd /opt/glassfish* Make the ant binaries executable
type:
chmod -R +x lib/ant/bin* Setup the installation for a non-clustered install
type:
lib/ant/bin/ant -f setup.xmlo Clustered installations are not covered here, but you should run lib/ant/bin/ant -f setup-cluster.xml
* Move the symbolic link to asadmin to point to the new Glassfish installation
type:
rm /usr/sbin/asadmin; ln -s /opt/glassfish/bin/asadmin /usr/sbin/asadmin;Create the domain
* Go to the glassfish installation directory
type:
cd /opt/glassfish* Create the domain called mydomain that listens on port 80 for HTTP and port 443 for HTTPS. The admin port is port 4848
type:
asadmin create-domain --adminport 4848 --domaindir ./domains --profile developer --instanceport 80 --domainproperties http.ssl.port=443 mydomain* To start and stop the domain use
type:
asadmin start-domain mydomaintype:
asadmin stop-domain mydomain* Test the server is running
type:
http://<ip address of the server>type:
https://<ip address of the server>* Configure you application via the administrator console
type:
http://<ip address of the server>:4848Set the domain to run as a service
* Go to the domains glassfish installation directory
type:
cd /opt/glassfish/domains/mydomain* Create a password file called .passwordfile that contain the following lines
AS_ADMIN_USER=<admin username>AS_ADMIN_PASSWORD=<admin password>AS_ADMIN_MASTERPASSWORD=changeit* Create the service
type:
asadmin create-service --passwordfile ./domains/mydomain/.passwordfile ./domains/mydomain* Check the service was created
type:
svcs -a | grep mydomaino You should see output like this
disabled 16:24:09 svc:/application/SUNWappserver/mydomain:default* Remove the AS_ADMIN_MASTERPASSWORD line from the password file by editing /opt/glassfish/domains/mydomain/.passwordfile (I don't know why, but the service does not start unless you do)
* Enable the service
type:
svcadm enable svc:/application/SUNWappserver/mydomain:default* Check that it is online
type:
svcs -a | grep mydomaino You should see output like this
online* 16:24:09 svc:/application/SUNWappserver/mydomain:defaulto If not check the log at
/var/svc/log/application-SUNWappserver-mydomain:default.log
Thursday, July 17, 2008
Leveraging the mobile phone
There are huge opportunities to leverage the mobile phone to communicate with your user base. The mobile phone is one of the few devices where you can push a message to your users in real time. Unlike a website or instant messaging application where the user needs to be logged on or email where the user needs first read their email, with a SMS or WAP push message the user can be contacted immediately.
There are many opportunities to leverage the mobile phone for marketing, notifying or prompting users. For instance there are a number of banks like First National Bank's inContact and MTN Banking that send out SMS alerts whenever money is paid from or to your bank account. There are a huge number of companies using SMS messages for marketing messages. There are a number of other uses particularly for two factor authentication like sending an SMS message with a one time pin (OTP) that is entered onto a website during the login process. This proves the user has the mobile phone in addition to knowing the username and password.
With all this added ability comes the inevitable risks. Too many marketing messages will annoy the user. It is therefore essential that the user always has an opt out option. There is also the added risk that the SMS can be spoofed. For instance an SMS can be sent to a user with a WAP link asking them to go to log onto your website, but the link points to a phishing site. This might enable somebody to get hold of a user's password.
So the bottom line is that 'yes' it is a great opportunity to contact your user base, but speak to some consultants who have a strong knowledge about this space before you do so, because there are a lot of pitfalls.
There are many opportunities to leverage the mobile phone for marketing, notifying or prompting users. For instance there are a number of banks like First National Bank's inContact and MTN Banking that send out SMS alerts whenever money is paid from or to your bank account. There are a huge number of companies using SMS messages for marketing messages. There are a number of other uses particularly for two factor authentication like sending an SMS message with a one time pin (OTP) that is entered onto a website during the login process. This proves the user has the mobile phone in addition to knowing the username and password.
With all this added ability comes the inevitable risks. Too many marketing messages will annoy the user. It is therefore essential that the user always has an opt out option. There is also the added risk that the SMS can be spoofed. For instance an SMS can be sent to a user with a WAP link asking them to go to log onto your website, but the link points to a phishing site. This might enable somebody to get hold of a user's password.
So the bottom line is that 'yes' it is a great opportunity to contact your user base, but speak to some consultants who have a strong knowledge about this space before you do so, because there are a lot of pitfalls.
Wednesday, July 2, 2008
How a SIM browser works
A SIM browser is basically a lightweight browser loaded onto a mobile phones SIM card. It basically renders a form of xml on the phone and allows for communication to a SIM browser gateway. There are to leading suppliers of SIM browser platforms. Gemalto with their S@T Platform and Smarttrust with their WIG platform. Both of these platforms working in a similar way although the format of the xml differs.
The xml is either loaded onto and stored on the SIM card or it can be dynamically downloaded on request. The nice thing about the way the xml is rendered is that it is rendered at the SIM level so it communicates to the mobile phone itself through the same protocol that is used for the other phone specific features. What this means is that the menus and prompts are consistent which the other menus and prompts on the phone.
Communication to the gateway is via SMS, but the SIM browser controls the communication. In the xml an http url is configured and the SIM browser packs this request up into SMS messages and sends them to the gateway. The gateway then unpacks the SMS messages and forwards it onto the application server. The application server would then respond with some xml, which is converted to byte code and packed into SMS messages on the gateway. These SMS messages and then sent to the phone where the SIM browser unpacks the SMS messages and renders the response to the user.
Since the SIM browser runs on the SIM card it has access to the 3DES security plugins on the SIM card and can encrypt data such as passwords or perform generate MAC values to check message integrity. A Security server can also be used on the gateway to perform password translations before passing the password into another security zone.
The xml is either loaded onto and stored on the SIM card or it can be dynamically downloaded on request. The nice thing about the way the xml is rendered is that it is rendered at the SIM level so it communicates to the mobile phone itself through the same protocol that is used for the other phone specific features. What this means is that the menus and prompts are consistent which the other menus and prompts on the phone.
Communication to the gateway is via SMS, but the SIM browser controls the communication. In the xml an http url is configured and the SIM browser packs this request up into SMS messages and sends them to the gateway. The gateway then unpacks the SMS messages and forwards it onto the application server. The application server would then respond with some xml, which is converted to byte code and packed into SMS messages on the gateway. These SMS messages and then sent to the phone where the SIM browser unpacks the SMS messages and renders the response to the user.
Since the SIM browser runs on the SIM card it has access to the 3DES security plugins on the SIM card and can encrypt data such as passwords or perform generate MAC values to check message integrity. A Security server can also be used on the gateway to perform password translations before passing the password into another security zone.
Subscribe to:
Posts (Atom)