The NanoSMS project started in July 2018, it was based on a Twilio SMS interface where a user could use SMS to communicate with a server running a Nano node. Private keys were held on the server and were linked to the mobile/cell phone’s number. The user would ‘text’ commands to a defined number which would allow access to their individual wallet. The aim was to create a simple, reliable interface for people who only had access to 2G mobile phones particularly targeting the ‘unbanked’.

The response to the project from the Nano community was amazing¹ and very quickly we were able to build a small team to further develop the backend as well as start doing research into marketing and methods of pushing adoption. It was noted early on that there were similar projects connected to other digital currencies following the same path. We were also able to apply to the Nano Foundation for a grant to pay for developer time to develop the system and run a small beta test.

Identified Issues

While we were able to put together a reasonably reliable system using the global Twilio SMS system there were 2 main issues. Firstly the SMS system has its own fees and these had to be accounted for, we were particularly looking at methods of providing local advertising to create revenue to support the system. The second issue was security — the initial design had identified a number of potential security issues with the concept and attempts were made to work around or through these issue. The main issue is that the 2G SMS system is not secure, it is old and uses dated encryption² which has been reverse engineered, this is built into the GSM standard so its hard to overcome³. The poor encryption means that there is a significant risk of Man-in-the-Middle attacks, also any attempts to secure the access to the users Nano wallet with a PIN will fail as the PIN is transmitted in the clear. Man-in-the-Middle attacks could both come by intercepting signals that are transmitted over the air or could also be from inside attacks of the GSM network operators or Internet Service Providers.

These security holes while not accessible to the everyday user would still be exploitable without too much effort, for example it is possible to create a GSM base station with a Raspberry Pi and an Software Defined Radio⁴. This would put the whole system at risk from either malicious individuals, groups or even governments. The problem is that the people at risk from these security holes are those who are most vulnerable — if you have the ability to have a more advanced mobile phone which can run a modern Nano wallet then you don’t need NanoSMS.

Overcoming Old Technology

It all comes down to the fact that a 2G mobile phone is unable to store private keys and sign messages/transactions. Modern Digital Currency (cryptocurrency) wallets do exactly this, they store the private key on the device itself and create and sign the transaction block before pushing it to the currency network via a connection with a node. The network can verify the block with the private/public key model. Intercepting the block with a Man-in-the-Middle attack won’t allow the block to be changed (though you could stop the transaction reaching the network). There are services that exist that allow people to transact using the 2G (GSM) network. Some of these projects/business including a number of well publicised cryptocurrency SMS wallet projects⁵ ⁶, accept the risk of the insecurities of the system. They use a combination of USSD (Unstructured Supplementary Service Data), which carries slightly better security as is session based⁷, as well as using a 2FA system to try to avoid spoofing (we implemented a similar setup in NanoSMS). The biggest services, such as M-Pesa, have their own ‘custom’ sim cards (Sim ToolKit)⁸. These sim cards have additional code which will allow secure signing of the messages for safer transmission over the insecure 2G network⁹. M-Pesa is a service developed by Safaricom one of the largest network operators in East Africa and therefore they have the additional benefits of being able to secure their own base stations and data centres.

All this means that unless you are an established Network Operator with the ability to have secure base stations as well as distribute your own sim cards with built in encryption functions, to allow safer interaction the service you develop is always going to put the end-user at risk. While the losses on a global scale might not be that significant it certainly would be for the individual.

Where does that leave NanoSMS?

The development of NanoSMS has stalled due to the identified issues but it doesn’t mean that we should stop exploring how we can help those who are unbanked. There are a number of possible avenues we could pursue:

1- Continue with the current setup — look towards using USSD instead of direct SMS to create session based security. Perhaps the risks that have been identified are acceptable. The code for NanoSMS is freely available to be developed on.

2- Work with a network operator to develop a system that used a Sim ToolKit (STK) setup. Nano would work really well with this sort of design but the development of this would be more in the region of a startup business rather than for a hobby or community group.

3- Instead, focus on developing services for low-powered mobile phones that are modern enough to store private keys and sign and send messages (for example https://www.kaiostech.com/). The 2G network is in the process of being replaced and so instead of forcing new technology into an old system we could be looking at how we can move from 2G to 3G+. Again this would work well with current development, mobile wallets already exist for iOS and Android — perhaps a localised design could be developed and rolled out to these low-powered semi-smart phones.

References