Wiley.Developing.Software.for.Symbian.OS.2nd.Edition.Dec.2007 (779887), страница 46
Текст из файла (страница 46)
However, note that the intent is not toinclude the complete set of capabilities in your DLL (i.e., CAPABILITYALL) just so that every process is guaranteed to be able to use theDLL – it’s unlikely that would get approval for Symbian Signing.7.4.8Data CagingIn addition to providing protection for sensitive APIs, platform securityalso has a feature for protecting data in the file system. This feature isknown as data caging.
Data caging is not a general file protection schemelike Unix and Linux, where individual files can be given read and writeaccess on an individual basis. Data caging in Symbian OS consists ofsetting aside specific directories in the file system and preventing accessto them except to processes with a high level of trust or owners of aparticular private area. These directories become cages of files so tospeak, where the cages protect the contents of the area.Let’s look at the directories in the file system that are protected by datacaging.\sys directoryAll system executables reside in the \sys\bin directory. In fact, theycannot be run from anywhere else.
To prevent tampering with executables, platform security restricts access to this directory. Only processeswith the Tcb capability can write to this directory. Tcb is a manufacturercapability and as stated previously in section 7.4.3, this capability is veryhard to get approved. The software installer is an example of a processthat has this capability and thus can install executables to \sys\bin.\resource directoryThe \resource directory contains the application resource files (e.g.,bitmaps, fonts, and help files). All applications can read from it, but youneed the Tcb capability to write to it.232PLATFORM SECURITY AND SYMBIAN SIGNED\private directoryThe \private directory contains the private data for all applications.There is a separate subdirectory reserved for each application. Anapplication’s subdirectory is \private\<SID>, where <SID> is theapplication’s secure ID as identified in the SECUREID line of the application’s MMP file.
If there is no SECUREID line in the MMP file, then SIDis defaulted to the application’s UID3 (which is the suggested course asmentioned in section 7.5.2). If there is no UID (but there always shouldbe), the SID defaults to 0.An application can access its own reserved subdirectory under the\private directory, but not any other application’s directory, unlessit has the AllFiles capability. This ensures that an application’s datastays private.There is no requirement that your application must write its data to itsreserved private directory, but it’s a good idea to put any data there thatyou want to be kept private.A DLL does not have its own private directory so it must use the privatedirectory of the calling process.
To discover the name of the callingprocess’s private directory, the DLL can call RFs::PrivatePath().Table 7.4 summarizes the capabilities required to read and write theprotected areas of the file system:Table 7.4 Locations of the Data Cages and Capabilities Required for AccessDirectories andsubdirectories forall drives (Z, C, etc.)Capabilityrequired to readCapabilityrequired to write\sysAllFilesTcb\resourceNone neededTcb\private\<ownSID>None neededNone needed\private\<otherSID>AllFilesAllFilesDirectories other than the ones here can be read from and written towithout requiring any capabilities.7.5 Application Signing in SymbianThis section discusses application signing on Symbian OS.
But beforejumping in to Symbian OS specifics let’s review the concept of digitalsigning in general.APPLICATION SIGNING IN SYMBIAN2337.5.1 Digital Signing OverviewDigital signing is a way of marking a file such that a receiver of the filecan be assured of the file’s source and integrity. Digital signing acts likea traditional written signature with the added feature of ensuring that thefile was not modified after the file was signed.Digital signing is a part of the public key infrastructure (PKI), whichprotects data by assigning a person (or company) a key pair consistingof a public key and a private key.
The public key is widely distributed,while the private key is privately held by the owner of the key. It is veryimportant that the key is protected and never given to anyone else, ormade vulnerable to theft! Data encrypted by a person’s public key canonly be decrypted by that person’s private key. In this way, someone cansend a secret message to anyone if they have their public key, and onlythe private key associated with that public key can decrypt the message.Digital signing works in the reverse manner: data encrypted by a privatekey can only be decrypted by the corresponding public key. The signerencrypts a ‘signature’ on a file using their private key, which includesthe file’s checksum (i.e., hash).
The person receiving this file gets thecorresponding public key for the sender and can decrypt the signature.In this way, it’s possible to verify that the signature was created by theholder of the private key, since that person is the only one with access toit. The verification process confirms that the checksum of the decryptedfile is the same as the one that was signed, which guarantees that the filehas not been tampered with since it was signed and distributed.A certificate associates a person or company’s identity with their publickey and has both pieces of information physically in it. Its purpose is toprovide assurance of who the public key belongs to.
The certificate isitself signed by a certificate authority (CA), which is a body trusted to beable to verify a person’s identity. For Symbian Signed identity verification,the CA used is a company called TC TrustCenter. A CA’s certificate canin turn be signed by another CA (a more trusted party), and so on, all theway to a certificate root, creating what is known as a certificate chain.
Ifyou trust the certificate root, then you can trust the data in the certificate.17.5.2Application SigningIn Symbian, signing an application consists of digitally signing a SymbianOS installation file (SIS file), which contains it (SIS files, and the PKG filesused to create them, are discussed in more detail in Chapter 5). Onlythe SIS file itself is signed, not its contents – even if it contains multipleexecutables and DLLs. This differs from Microsoft Windows Mobile, for1For further information about PKI, please consult Understanding PKI (Adams and Lloyd,1999) and Appendix B of Symbian OS Platform Security by Craig Heath.234PLATFORM SECURITY AND SYMBIAN SIGNEDexample, which requires each executable and DLL, in addition to theinstallation (.cab) file, to be signed.A developer can sign a SIS file themselves using the signsistool – this is known as ‘self-signing’.
Or the application can be signedexternally, as is the case when an application is Symbian Signed.The three types of application signing in Symbian are:1.unsigned,2.self-signed,3.Symbian Signed.UnsignedUnsigned applications are not digitally signed at all.
This is the state ofthe SIS file after it is created with the makesis tool (as discussed inChapter 5).In Symbian OS v9, generally an application must always be signedin some way (that is, it should be self-signed if Symbian Signing is notrequired), but the capabilities granted using self-signing are decided bythe phone manufacturer.
For example, S60 3rd Edition only allows signedapplications to be installed on devices.Self-signingSelf-signing is when an application is signed without going throughSymbian Signed. To self-sign it is necessary to have a certificate and theprivate key of that certificate. Using the signsis tool it is possible tosign a SIS file built previously with makesis, or it is also possible to usethe createsis tool to build and sign a SIS file in one go.
Carbide.c++uses this tool (as can be seen from its console output).The most basic way to obtain a certificate for self-signing is to generateone using Symbian’s makekeys tool. The makekeys tool generates boththe public certificate and the private key. Here is an example:makekeys -cert -len 2048 -dname "CN=Bob Smith OR=Acme CO=USEM=bob.smith@acme.com" bobkey.key bobcert.cerThis generates a certificate that includes the identity of a developer namedBob Smith. The .cer file generated is the public certificate file and the.key file contains the private key for that certificate.It is then possible to sign the install file with this certificate usingsignsis:signsis MyApp.sis MyApp_signed.sis bobcert.cer bobcert.key passwordAPPLICATION SIGNING IN SYMBIAN235where:MyApp.sis is the file name of your unsigned application.MyApp signed.sis is the filename for the signed version of the application.bobcert.cer is the certificate filename.bobcert.key is the certificate’s private key.password is the password of the private key (can be omitted if there isno password).Now you have a signed SIS file that you can install on a phone, unless:–Your application uses extended or phone manufacturer capabilities.–The phone manufacturer has prevented applications from beinginstalled if they are not signed with a ‘trusted’ certificate (I’ll discusstrusted and untrusted certificates in the next section).–There is a setting in the phone’s device settings to allow the user todisable installations from SIS files signed by untrusted certificates, andthe user has selected it.Trusted and untrusted certificatesIf you create a certificate and key using makekeys, as described above,it is not considered trusted by the phone.
This is because it’s not signedby a CA who would have verified that your certificate actually identifiesyou. You can see why it’s not trusted since it was easy for me to create acertificate for Bob Smith although that is not who I am. Symbian OS willstill allow an application signed by an untrusted certificate to be installed;however, it will display a message saying that the application is from anuntrusted source, and asks the user if they want to continue the install.An example of this dialog is shown in Figure 7.2.Figure 7.2Warning with Untrusted Signature236PLATFORM SECURITY AND SYMBIAN SIGNEDTo prevent the display of this warning dialog, it is necessary to havea certificate issued by a Symbian Certificate Authority.
This is achievedby applying to the Certificate Authority for a Publisher Id. Following avetting process that confirms the identity of the applier the Publisher Id isissued. The Publisher Id contains the certificate and key file that is usedto identify the source of the application.When an application is signed with a trusted certificate, the user can usethe application manager on the phone to view who the certificate belongsto and therefore the application’s source.
It also provides confidence forthe user who is installing the application by providing information aboutthe application’s author.Another type of certificate you can self-sign with is a developer certificate. Developer certificates are used to develop and test software thatuses sensitive capabilities before the software is submitted for SymbianSigned testing. Developer certificates are downloaded from the SymbianSigned website and are described in more detail later, in section 7.7.Symbian SignedAs mentioned previously, an application must be Symbian Signed if ituses capabilities identified as sensitive. It is not possible to Symbian Signan application yourself – TC TrustCenter does this following a successfulsubmission through the Symbian Signed process. The certificate TCTrustCenter uses for Symbian Signing chains to a Symbian Signed rootcertificate which resides on Symbian OS v9 devices.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
