Hi,
My name is Sean and at the moment I am looking into the use of a SIM to provide handsets with the Malwarebytes database. The ARM SC300 CPU was designed for SIMs from it's inception and it can be cadenced at 25MHz. With Trustzone and Chameleon code as standard, data updates remain secure. There are several hardware solutions for scanning the Malwarebytes database and they don't occupy a lot of silicon so several could be placed on a chip. The idea only works if the 2 unused lines on the SIM (C4 & C8) are connected and used to provide a USB connection. It is only of value to future designs.
The solution also requires the baseband processor to send raw data but Osmocom have an open-source solution for this.The JVM idea was cursed at birth since it has to support 'classic' i.e. V2.2.2 and their are a number of ways firstly to break into assembly-language and secondly to defeat the ARM7TDMI used in all of the SIMs I have seen. Because they are usually clocked at 1-4MHz, no cache is used so on examination of how the CPU deals with an exceptions means that self-modifying code can be used to break out of the sandpit.
SIMs originally just stored data, JVM was introduced in 2006 so people have had a decade to break the system. Most of the 'security' consists of obfuscation which is a bad policy. A secure system should allow complete details to be made public without it weakening the security. For that reason, a standard implementation should be used. JVM makes a feeble attempt to avoid Gödel's incompleteness theorem from striking (like the limitation of 1D strings to avoid issues in matrix mathematics) but rather than trying to put sticking plasters on these holes, an applet should be allowed to fail in a non-critical manner. The .CAP format has proved no barrier to introducing malware but pursues the obfuscation policy. If anything, it means that programmers don't think as much about security as they should.
If I am correct in thinking that the de facto standard CPU IS an ARM7TDMI then a lot more could be written in a smaller space in assembly-language and allow for applets that use the power of the CPU. I am still considering the standard format but I've already come to the conclusion that all workspace should be declared & bounded so the CPU can intercept data fetches outside of said dataspace. ARM has always used separate data & instruction caches so that the stub that decides on which cache is used can be used to tightly bind data & instruction space.
The secure platform in a mobile handset is the main CPU. Changing this to the SIM CPU being the secure platform is a paradigm shift but without doubt, the SC300, being simpler, is easier to test for it's security. A large number of handsets using a -S CPU have still got holes in them and I'm sure people are aware that the 'Master Key' of Android has been recovered which is why they are now in a quandary because defending against fake updates has become a huge issue.
For now, I am looking at using a Raspberry Pi to emulate the SIM but I'm having a hard time getting the details on the boot. I know the GPU copies a block of code into the L1 cache of the CPU but beyond that, it is a little vague. It appears to install a bootstrap that supports a MicroSD load as well as a USB 'secondary boot'. It looks like I need to replace that and setup the Trustzone ASAP. I don't want to install an OS, or rather I wish to install an SC300 emulator. I have the appropriate hardware to connect the Pi to a SIM-connector and with the Pi being dual-core, 1 core will emulate the SIM while the other acts as a debugger. I am looking for the source-code of an ARM disassembler but if I have to, I will write my own (itself in assembly language).
I have a lot of the cheapest feature-phone I could find and right now I have a friend working on a daughter-board so that both the application CPU & Baseband CPU can be downloaded to via the USB connector (CS using PIC based top 4 address lines). I know this could take me between 1 & 2 years but I'm hoping that I will have something worth showing much sooner than that. I have coded a LOT of ARM cores, always in assembly language and if all else fails, just as a project, I can try to see just how much power a bare-bones handset that has just 4 functions (send & receive calls and SMSs).
My inspiration comes from the $12 “Gongkai” Phone which uses a Mediatek MT6250 - an ARM7 based core that is both the baseband & application processor. If all of this can be achieved at 300MHz, the cost is so low that an octocore, top-end handset could simply use a single core to deal with 3G baseband processing so the chip-count & space on the board goes down. Why nobody has done this is a surprise to me.
Such a big change is something that would normally be a top-down move, but if I can show the cost benefit in security and offset the cost of the modified SIM by omitting a separate baseband CPU, it makes sense.
If this is so ridiculous as to seem plain stupid - do say so. I joined to ask this question to a group of people who have more experience than me concerning the idea.
If I go ahead, I would appreciate help in producing a specification. I have discussed some ideas with ARM but I need a concrete set of aims. I am not looking to make a profit, I just want to cover the costs of working on the concept. Who knows, if the demo is good enough, it could end up as a Kickstarter project.
Thank you for your time.