<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-9058F379-C495-4B22-B270-FF6A80E450B8" xml:lang="en"><title>Device

security mechanisms</title><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>The list below contains some common device security mechanisms.</p>

<section id="GUID-24AD1095-E039-46B5-A39A-1D814D697DA1"><title>Device protection</title>

<p>The Symbian platform is not well equipped to protect against a physical

attack (that is, when an attacker has physical access to the mobile device)

because access to a device is controlled by the device lock feature, which

is often not used. Other external methods of protection, like a PIN code or

Subscriber Identity Module (SIM) locking, tend to provide protection only

when accessing a cellular network, leaving the information content vulnerable.

Without <xref href="GUID-A1ED2377-E196-423F-A5A2-1889C1CC3E05.dita">cryptographic

protection</xref>, it is possible to gain access to the device's information

storage with hardware-based methods (for example, wiretapping connectors and

direct reading of memory chips).</p>

</section>

<section id="GUID-BE16A5D1-B580-4ED6-82D7-16B33B8EEADF"><title>Device authentication</title>

<p>Sometimes, for security reasons, an application needs to identify the

mobile device it is running on, for example, to use specific ciphering keys

or to apply copy protection. Identification can be done by checking the device's

International Mobile Equipment Identity (IMEI) code, which is unique in each

device used in cellular networks. To retrieve the IMEI code, you can use,

the IMEI code in different versions of SDKs. Refer to the SDK API or Symbian

documentation for the proper method.</p>

<p>Another way to get information about the running platform and the mobile

device is to use the <codeph>HAL:Get()</codeph> method defined in <codeph>hal.h</codeph> header

<p><b>User authentication</b></p>

<p>When powering on the device, the user is authenticated in the <i>operating

system level</i> with standard device authentication methods, such as a PIN

code and security code requests. However, these features can be turned off

by the user and are easily reset with special hardware. If an application

needs to authenticate the user, it should be done in the <i>application level</i> by

implementing a separate user name/password authentication mechanism.</p>

</section>

<section id="GUID-962E0183-0CBD-457D-B24C-C0BDB30A58A4"><title>Mobile hardware</title>

<p>The Symbian platform attempts to ensure the integrity of data even in

the presence of unreliable communication and a shortage of resources, such

as memory, power, and storage.</p>

<p>The user may detach removable storage media at any time, either intentionally

or unintentionally. The platform has a built-in detach handling mechanism,

but applications should still be prepared for a sudden loss of storage media

to prevent data loss or corruption. To check the type of storage media (removable/fixed),

use the <xref href="jar:GUID-35228542-8C95-4849-A73F-2B4F082F0C44.jar!/sdk/doc_source/reference/reference-cpp/F32_EKA2/RFsClass.html#%3a%3aRFs%3a%3aDrive%28%29" format="application/java-archive"><codeph>RFs::Drive()</codeph></xref> method. </p>

<p>The device may shut down at any time, either by accident or because

the battery runs out. Important data stored in nonpermanent memory should

be written to permanent memory as early as possible. To query the battery

level, use the <codeph>HAL::Get(EPowerBatteryStatus)</codeph> method. For

<p>Even though internal storage is not physically protected, you can secure

memory cards with password protection. If the locking option is used (method <xref href="jar:GUID-35228542-8C95-4849-A73F-2B4F082F0C44.jar!/sdk/doc_source/reference/reference-cpp/F32_EKA2/RFsClass.html#%3a%3aRFs%3a%3aLockDrive%28%29" format="application/java-archive"><codeph>RFs::LockDrive</codeph></xref>), memory card contents are protected

with a password and cannot be read in any other device without it. Password

locking is an extended functionality of the Multimedia card (MMC), and may

not be compatible with all hardware and software configurations.</p>

</section>

<section id="GUID-9058F379-C495-4B22-B270-FF6A80E450B9"><title>Third-party solutions</title>

<p>A mobile device can be protected with third-party security applications. <i>Antivirus

software</i> can detect and quarantine any viruses that try to access the

device, as well as restore infected files. Antivirus software is usually used

together with <i>firewalls</i> to observe and protect both incoming and outgoing

data connections. This enables monitoring of important data and prevents it

from being sent out of the device. Firewall and antivirus software can also

be part of an <i>intrusion detection system</i> that notifies the user whenever

a malicious attempt is detected.</p>

<p>Furthermore, there are applications you can use to encrypt existing

files, manage passwords, and store information and data securely (in vaults).

You can even cipher information in applications and connection methods which

do not initially support ciphering (for example, short message service [SMS]).</p>

</section>