Protecting APIs - a different approach

I have been wondering lately if the current is the most optimal way of protecting APIs in the S60 (or Symbian in general) C++ SDKs. It must not come as a surprise to any programmers that there are far more features in these SDKs than what we can use with the publicly available functions. But they are usually hidden.

How? Before answering this question, some technical details. In order to use a certain feature in C++ the following two conditions must be met:

• The header file including the function to be called must be publicly available in the SDK,
• The component, typically a DLL and its associated LIB file, must be publicly available in the SDK.

The first condition ensures that the code compiles, the second that the link process will succeed. The most common practice that Nokia applies when they want to protect an API (i.e. not let 3rd party use it) is that they remove the header file in question. I would call it as a lazy protection as it does not protect against reverse engineering. For example, as soon as the API becomes publicly available there is nothing that can prevent a developer from making use of that functionality. Okay, Nokia clearly forbids reverse engineering in their license agreement, but there might be people who think it in a different way.

The second type of protection, let's call it hard protection, is to remove both the header and the LIB (that we import in our MMP) from the SDK so that neither compilation nor linking succeeds. Naturally, the DLL must remain in the SDK as usually it already has clients that use the provided functionality. This workaround is also applied by Nokia and Symbian alike. Sometimes they make it so that the LIB file is missing only under emulator platform (i.e. WINSCW), but not from the target platform (e.g. ARMv5). This makes it more difficult for developers to test their software - but not impossible. Since if you cannot link against a DLL statically, then you can still do it dynamically. You just need to use RLibrary class for that purpose and call the exported methods based on their ordinals. Okay, it's by far not trivial and now we're knee-deep in sensitive and confidential data, but it IS possible.

Let's just stop here for a minute to think about why Nokia (probably) follows the above-described practice! If I wanted to protect some data and not let others use it, then I would do everything in order to impede people to make use of it. Not just invent some hackish solutions that can be relatively easily bypassed, but make it really hard for others to hack. But it might not be in Nokia's interest to do so. You know, they have partners to whom they open up some - non-published, but available - APIs every now and then. And if they can choose from simply giving access to a header file OR sharing e.g. a LIB file, too, then they naturally vote for the first option. In my opinion it's much easier to do due to e.g. traceability reasons.

We have now finally reached the point where I can talk about my idea on a (probably) better way to protect APIs. You know, there's a rule of thumb in Symbian C++ programming as of the introduction of Platform Security: if you have sensitive information (I mean, data) to protect, then you're suggested to write a server and let it guard that data. This solution also enables you to smoothly control who and how can access the protected resource. I believe that Nokia has already re-factored their code according to this pattern so that all sensitive data is taken care of by various servers. These servers may then check against capabilities, secure and/or vendor IDs. Ideally, there is no sensitive data by now that is not protected by a server.

And this is the point where I ask: why not make every API public so that everyone can use it? Following from all above, security must not be a concern here, since access to sensitive data is already under control. On the other hand, developers could greatly benefit from having access to DLLs that have been hidden from them so far. You know, I'm talking about a big bunch of features that have been written by some talented developers at Nokia, Symbian, etc. and hidden unnecessarily. Why not let others make use of those features if it doesn't harm?

There's an exception, though. If the piece of information to be protected is not data, but an algorithm, for example. If it's not of big importance what data we work on, but how. Garnished possibly with some IPR issues. If this is an issue and the executing code is in a DLL (i.e. not behind a server), then we can't expect too much from Platform Security. We can assign some strong capability to the DLL so that using it would not be trivial for anyone, but we'd have no option for fine-tuned secure/vendor ID check, for example. Perhaps even capability constraints would not be sufficient, either. I think that we (err, I mean Nokia, Symbian and others) could re-use the existing approach in this case, that is, not publishing header and/or LIB files in the public SDKs. You know, I don't think we should fully get rid of the current solution, but at least suggest to use it moderately.

Wishing to read your comments!

Tote

Here is my program, sign it yourself!

I've bumped into the following blog today. This is exactly what I was thinking about a few weeks ago! I asked myself if developers could distribute their apps freely? Of course, the bottleneck is that they have to sign their apps properly, which is time-consuming and costly. But if one publishes his unsigned SIS file (it can be signed as well, since a file can be re-signed), then it can be freely signed by anybody else. So that the author can get rid of the burden of having to have his application SymbianSigned before distribution takes place.

One issue, though, that this workaround raises is trust. Why would I sign a SIS if it's from somebody whom I don't know? Why would I trust the program and presume that it will make no damage, generate extra cost, etc.? Of course, it's such an issue that must be carefully considered, case by case, program by program. But still there are programs whose authors are well-known and respected: they haven't all had time/money to bother with signing. Or let's take open source projects: unless they have good funding they will never spend money on content signing, which cost will never be returned. Not as if I was aware of such an open source project, but still. :)

So let's have a closer look at how it would work in practice! The classification of capabilities is as follows:
Group #1: User-grantable capabilities that can be granted by the user upon installation.
Capabilities: LocalServices, UserEnvironment, NetworkServices, Location, ReadUserData and WriteUserData.

Group #2: Powerful capabilities that cannot be granted by the user, but do not require any manufacturers' approval.
Capabilities: PowerMgmt, ReadDeviceData, WriteDeviceData, TrustedUI, ProtServ, SwEvent, SurroundingsDD.

Group #3: The most sensitive capabilities that only device manufacturers (i.e. not SymbianSigned or any other authority) can grant.
Capabilities: AllFiles, CommDD, DiskAdmin, MultimediaDD, NetworkControl, TCB, DRM.

If one writes a program that requires capabilities from groups #1-2 then it can be easily signed by anybody even if it demands some sort of technical mindedness. The steps for being able to install such a SIS file on our phone are as follows:

• Registration on SymbianSigned.com.
• Requesting a developer certificate for a given IMEI (i.e. the person's own mobile phone).
• Once having the DevCert, sign the program with it.

Following these steps enables anyone to sign any (Symbian) programs that can eventually be installed on a (Symbian) smartphone. On any programs, I meant those that do not require capabilities from the third group. Another constraint of a single DevCert is the inability to sign a program for more than one phone. That requires an ACS Publisher ID from VeriSign - costs 350 bucks, btw.

And what about those programs that use APIs protected by capabilities from group #3? For them, one must have an ACS Publisher ID even for a single phone. And not only is it the cost that might prevent most people from requesting a publisher ID from VeriSign. If you'd like to be able to sign programs with the most sensitive capabilities, then getting a publisher ID is the easier task. The second step is to issue a request to the device manufacturer in which you detail which capability you need and why. On API level (e.g. I need RFormat::Open() to use and for that I have to have DiskAdmin capability) and for each capability one by one. And believe me it's tough! It's time and energy consuming and sometimes doesn't lack unnecessary conversation with the manufacturer ('we don't think you need that capability' ... arghh).

As a brief summary I still think that it's worth going on this path. For a well-isolated target group, namely mobile geeks, but for them it's really worth. Yes, it's you who reads this blog. :)

Migrated from Forum Nokia Blogs.

Tote

Smartphone OS market share in 2006

An article on smartphone OS market share by region (between 2004 and 2006) made me think. Since I'm an analytical mind and also interested in this topic I've automatically started to compare the two figures. And as the author of the aforementioned article has left the analysis part to us (or was he just too lazy?:), I've taken the effort to draw some conclusions from the figures.



So, let's take the regions one by one as shown on the figures!
- European, Middle-East and Africa (EMEA): Symbian still rules smartphone OS market here.
- In Japan almost the whole market was ruled by Symbian in 2004. This has significantly changed by 2006 since Linux has appeared on the horizon with its ~40%! I bet Symbian is not too happy about it, even if they have shipped lots of new phones in Japan recently.
- China: first, let's start with that Microsoft was present on the market in 2004. In contrast, their market share has dramatically shrunk almost to non-existent by 2006. Second, Linux is yet again an important factor that analysts and more importantly phone manufacturers must take into account in 2006. Its roughly 40% market share is very considerable. Third, the strange thing is that Symbian's market share has remained intact during these two years - it's still around 60%.
- North-America: one of the strangest markets - at least from our analysis' point of view! In 2004, Palm phones were dominating the smartphone market (~50%). Their market share, though, has dramatically shrunk to less than half of their previous share (now ~20%). The same pattern can be observed with regards to the popularity of Symbian OS - but with different numbers. In 2004, Symbian was the second smartphone OS vendor dominating 30% of the market - in contrast they're now the fourth with their ~10%! Who won then? Surprise-surprise: Microsoft! They were the third most popular OS vendor in 2004 (~10%) and now they're the #1 with ~30%! The last observation is that RIM has pretty much gained position - they're the second now.
- Finally, the rest of the world (ROW): well, similarly to EMEA market Symbian phones are in monopoly.

As a brief summary my findings are as follows. Symbian's hegemony is noticable all around the world. In most places more than half of the smartphone OS market is in their hand(held)s. :) With one exception, though: North-America. There are couple of interesting articles (on SymbianGuru, Darla Mack's and Tommi's blogs) as to why Symbian, most notably S60 phones are not present in North-America so it wasn't surprising for me to see the trend. It came as no surprise, either, that Microsoft is just there in North-America - what I found interesting, though, that basically this is the only market where they are taken into account at all. Finally, it's already a cliche that Linux phones are coming. LiMo, MontaVista's Mobilinux and TrollTech are just a few keywords everybody blessed with a little foresight might want to memorize. Japan and China are two countries where experiments are being made with mobile linux - and their success seems to be tangible. But let's not continue the debate on which mobile platform is the best and more importantly who will win in the long run. On the one hand, that's impossible to predict, on the other hand it's worth another article. :)

Anything to add?

Migrated from Forum Nokia Blogs.

Tote