A Note on Trusting One’s Own Mobile Device
Pradip Lamsal
Department of Computer Science
University of Helsinki, Finland
1st February 2002
https://www.doczj.com/doc/1913391810.html,msal@helsinki.fi
1 A short story by Carl Ellison1
“I had this great bicycle, once. I kept it in the walkway under my rowhouse in the Federal Hill neighborhood of Baltimore, locked behind a solid wooden gate. To protect it, I went out and bought a hefty padlock. The lock cost a fair amount, but my peace of mind was worth it. Then one morning, my neighbor knocked on my door and showed me a pack from the back of a bicycle, asking if it was mine. It sure looked familiar, but it couldn't be mine, because my bike was safely locked up.”
Figure 1: An unbreakable padlock, could it protect the bicycle?
“Eventually I found the padlock, above, discarded in the empty field across from my house. We never recovered the bicycle, of course.”
It is not very difficult to get the message this short story is trying to tell us. There is more to security than just sticking a padlock to the object we want to protect. Likewise, in date security, there is more than just encryption that we need to consider. If we consider a concrete example of mobile network then there are so many things involved in security the communication between the sender and the recipient. Issues such as someone issuing a fake certificate, someone stealing the mobile device, someone getting unauthorized access to the mobile device and misusing it, trustworthiness of the applications themselves are only a few that can compromise the communication and eventually the whole communication infrastructure. In this article, we look at security issues surrounding mobile devices, especially from the perspective of trust. We list some requirements for mobile devices to be smartly secure and attempt to propose some conceptual models to make them smartly secure.
1 Original story can be found at https://www.doczj.com/doc/1913391810.html,/~cme/html/padlock.html (referred on: 1st Feb. 2002)
2 Some issues with mobile devices
From a user’s point of view a mobile device acts as a gateway to the network. The user’s communication to the network and other users is only via the mobile device. It is therefore essential that the interface between the user and his mobile device is highly trustable and this trust can always be guaranteed. If this does not hold true then the whole security architecture falls over and the rest of the problems just become secondary issues. Our experience with this interface is not as good as what we would ideally like to have. There are scenarios where trust at this interface is loose and easily broken. Sometimes this can just be an accident but at other times this can be a deliberate act. Additionally, the openness of mobile devices in the future will bring its own set of issues, which affect this user-mobile device interface from the perspective of trust and security.
Figure 2: User-Mobile device interface
The following are some of the main areas of issues:
1. The mobile device gets lost. Someone else finds it and misuses it.
a. The new owner uses the device inappropriately.
b. Since the device contains the details of the real user, the new owner pretends that he is
the real user and acts on behalf of the real user without his authorization.
2. The future form of mobile devices might be open and easily configurable or customizable. This
facility can backfire the user if the device becomes configurable by more than just the user.
a. The mobile device is used to browse the web, without downloading anything. The web
page contains some kind of virus, which automatically attacks the mobile device and
changes the device’s configuration.
b. The mobile device is used with mobile code. The mobile code is malicious and changes
the device’s configuration.
c. The mobile device is equipped with some time bomb (by the manufacturer or a repairer),
which makes the device act like a self-operating robot after a specified time. The device
after this stage can misuse the resources, for instance, delete information from the device,
misuse the user’s security keys etc.
d. The network provider has some access to the mobile device connected to its network.
How much trust can be put on the network provider? What if someone working there
tries do some nasty thing with the device?
These issues lead to another set of vital questions in this user-mobile device interface.
1. Can the user always trust his own mobile device?
a. Currently a user trusts his mobile device simply because he owns it. Is this universal?
b. How does the user know if the device is still trustable?
c. Should the user do some trust checking every time before he uses the device?
d. Can the device be made unworkable without another supporting device, either hardware
or software?
e. Should the device tell the user if it is “ill”? How?
2. Can the mobile device always trust its user?
a. Who is the right user: anyone turns the device on or someone who shows some
credentials?
b. Should the device be able to know if the credentials are from the real user or from a fake
user? Should the device have this kind of intelligence?
c. How can the device know if the credentials are coming from the right user?
d. Can the device allow the user what the user wants to do with the device, in terms of
customizing it by changing the configuration? Should there be some kind of restriction?
e. Should the device expect more than one form of authentication credentials from the user?
Can this second form of authentication credentials go beyond the regular software
credentials such as user name and password? How can this affect the usability of the
mobile device?
3. Should the owner always be accountable if the device gets misused?
3 Requirements
In order to make a mobile device smartly secured the following requirements can be put on the user, mobile device and the environment when the user uses the mobile device.
device
3.1 Mobile
1. The mobile device should have the intelligence to detect the real user and someone else.
2. The mobile device should always record and display all the changes made in its configuration
(from the initial configuration). This is critically important if the changes are made on the user’s security credentials and this kind of changes must always be flagged up.
3. The mobile device should have be able to tell the real user when it is “ill”.
4. The mobile device should be able to inform the real user if it detects that it is being used by
someone else.
3.2 User
1. The user should be able to detect when the mobile device is “ill”.
2. The user should be able to do some trust checking before he can use it. The user has the right to
ignore this checking.
3. The user should be able to notify the network immediately when he believes that his mobile
device is being used by someone else.
4. The recipient should also be able to detect if the sender’s credentials are used by someone else, not
the real user.
3.3 Network
1. The network should be able to detect if the credentials do not match the real user.
2. The network should be able to reject the credentials from the mobile device if the network is not
satisfied that the credentials are from the real user.
References
[ES00] C. Ellison and B. Schneier, “Risks of PKI: Secure Email”, Comm. ACM 43(1), 160, 2000.
Also “Ten Risks of PKI: What You're not Being Told about Public Key Infrastructure”, at
https://www.doczj.com/doc/1913391810.html,/pki-risks.pdf