The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

import-bot (20211) [Avatar] Offline
[Originally posted by caro]

I am trying to develop an IM for mobile phones(using J2ME) that can be used in
a corporate environment. I found your book very helpful, but I am new to both
Jabber and J2ME and have some additional questions...
I know I can use SSL for encryption between client and server, but can I also
use SSL between servers? If I want to add more security, such as digital
signatures, how do I send them? Is it possible to use the digital signature as
In order to communicate outside the corporate servers I will most likely need
more encryption. Do you have any tip? I was thinking PKI, but fear that it
might be a bit to heavy for a mobile phone?

I need my client application to be as small as possible. Can I use XPP instead
of xerces.jar. I.e. if I use XPP (or kbxml) do I have to implement xerces.jar?

import-bot (20211) [Avatar] Offline
Re: Secure IM for mobile phones
[Originally posted by iain.shigeoka]


Glad you enjoyed the book. If you have the time, please leave a review on for the book. The reviews really help new authors like myself.

Server to server SSL encryption is possible but not widely available on most
servers today. if you will be implementing the server solution on both sides
(for everyone's domain that will need secure messaging) then it is possible
(and relatively easy) to implement SSL on server connections. In fact, with
SSL you won't need to use the dialback s2s authentication scheme that's used
by most servers.

If you can control the server on your user's side, but not on the recipient's
server, then you can securely send unencrypted messages to your server
(assuming you trust your server) and then have the server encrypt the messages
before sending it to the recipient (I'll tell you how to do this below). This
offloads the computationally intensive task of packet encryption to the
server. Notice your terminal (terminal == mobile phone) will be doing SSL
encryption of the data between the client and server so the data remains
secure. Most phones that support SSL connections do it in hardware so it
usually doesn't result in too large a performance impact.

If you can't control any of the servers, then your terminal application will
have to encrypt the packets. The only standard method for doing this is to use
PGP. The details of doing this is provided in a Jabber standard (see standards for details). However, most clients don't support
packet encryption so it is unreliable to asusme that you can send an encrypted
message to someone and they can read it. There's no good way to get around
this problem other than to tell both users to use a client that understands
secure Jabber or uses your custom client.

If you know the other user has your custom client, then you can easily encrypt
the packet data using any method you like. The simplest is to have the sender
encrypt the data using the public key (in the public certificate) of the
recipient. The recipient receives the message and decrypts the data using her
private key. Java security provides the tools to run encryption algorithms
although I'm not sure what J2ME profiles/configurations contain which Java
security libraries. You'll have consult the J2ME library docs for the mobile
phones you wish to support.

Remember to wrap your encrypted data within a namespace in an x extension. An
example would be:

<message to=''>
<body>Encrypted message attached</body>
<x xmlns=''>ab432498c244d2f...</x>

Hope this helps. If any of this is unclear, let me know.

import-bot (20211) [Avatar] Offline
Re: Secure IM for mobile phones
[Originally posted by iain.shigeoka]

Sorry, I forgot to answer your last two questions.

PKI is probably the way to go. It is pretty heavy weight but there really
isn't much of an alternative that is secure. I imagine most phones should have
encryption libraries for handling HTTPS/SSL that make this less of a
performance issue but relying on that will make your client phone specific. Of
course, anything beyond the most trivial applications need to be customized to
run well on any particular phone so this may not be much of an issue...
especially if your company has standardized on a particular phone.

Your XPP question. You should probably try and replace Xerces with kbxml which
is written specifically for J2ME. It is very easy to convert XPP method calls
into SAX events (there's basically a one-to-one mapping, just pull the
parameters from your XPP calls, and pass them to the SAX handler as SAX
events). The XPP3 parser at includes a SAX adapter class that
does this for you automatically and I would imagine that the kbxml parser does
too. If it doesn't just take the adapter from the XPP3 code (it should be
standard XPP to SAX so should work with kbxml).

Let me know if you run into any problems.