Thursday, June 18, 2009

Security in Mobile Handsets

Ref Topic Description Priority
(H/M/L)
1 Secure Boot Ensure integrity of core LiMo software at boot time. Need a flexible secure boot solution, to allow legitimate patching. H
2 Data Caging Ensure that application data can be made (directly) accessible only by the application that owns them (or by applications with file system access privilege). H
3 Reference Application Security Policy SPEF offers capability to define a policy, but none has yet been defined. A reference policy should therefore be developed. H
4 Security implications of Java and Internet Frameworks Development of Java and Internet FWs has been highlighted as high priority by the EC, but they bring with them their own execution environments and associated security risks. Security analysis and implementation of security measures are necessary to ensure these environments can be deployed safely. M
5 Secure Execution Environments Develop capability to offer controlled access to secure execution environments eg ARM’s TrustZone, or Hypervisor technology L
6 Secure storage facilities for applications Provide applications with high security areas for data storage L
7 Runtime Integrity Checking Ensure integrity of mobile software remains intact after boot M
8 Memory Management ... Prevention of attacks targeting memory (buffer overflows, NX bits, DMA & LCD access control) H
9 … and other software quality measures Use of type-safe APIs, verification tools, compartmentalisation, etc H
10 Patching Defining a secure approach for applying software patches to in-field LiMo devices, including patching of device boot code M
11 SIM Lock and IMEI Security Fundamental security measures for guarding against phone theft and subsidy loss H
12 Mobile Trusted Module (MTM) Mobile equivalent of Trusted Platform Module (TPM) for desktop computers which can be used to deliver various security services. Defined by Trusted Computing Group (TCG).

Availability of MTM in future should be considered in system design. H
(should be considered early on)
13 Debug mechanisms Ensure debug mechanisms cannot be abused to undermine platform security H

Monday, June 08, 2009

Yariv’s Blog » Blog Archive » Parallel merge sort in Erlang

Yariv’s Blog » Blog Archive » Parallel merge sort in Erlang


Parallel merge sort in Erlang
Posted by Yariv on March 09, 2009

I’ve been thinking lately about the problem of scaling a service like Twitter or the Facebook news feed. When a user visits the site, you want to show her a list of all the recent updates from her friends, sorted by date. It’s easy when the user doesn’t have too many friends and all the updates are on a single database (as in Twoorl’s case :P). You use this query:


"select * from update where uid in ([fid1], [fid2], ...) order by creation_date desc limit 20"


(After making sure you created an index on uid and creation_date, of course :) )

However, what do you when the user has many thousands of friends, and each friend’s updates are stored on a different database? Clearly, you should fetch those updates in parallel. In Erlang, it’s easy. You use pmap():