How Secure Pay-As-You-Go Keycode Systems Operate

This is a continuing series on using keycode systems to deliver pay-as-you-go solar in off-grid energy markets.

• Why Distributors Use Pay-As-You-Go
• How Mobile Network Operators Utilize Prepaid Scratch Cards
• How Secure Pay-As-You-Go Keycode Systems Operate << You’re Here
• How Pay-As-You-Go Product Activation Works
• The Design Approach for Developing Keycode Systems

In the past two articles of this continuing series we provided some of the context for why keycodes and scratch cards are a good solution to the impedance mismatch between a high-tech product offering and a low-tech operational environment.

But what’s in a pay-as-you-go keycode, really? And are keycodes and scratch cards the same thing?

Fundamentally, a keycode provides a user authorization to system resources, whether it be cell network airtime or, in our case at Angaza, life-changing products.

Thinking of a keycode as a security token is useful because it allows us to perform the standard “usability versus security” tradeoff analysis when designing a pay-as-you-go keycode system. Here is where it’s important to understand the operational differences between a mobile network operator and a pay-as-you-go (PAYG) product distributor.

 

Designing Secure Systems for Mobile Network Operators

In a mobile network, the resource to protect is access to the network itself. The network operator wants to grant access to the network to anyone who has paid while denying access to everyone who has not.

Although a special device (e.g., a phone) is required to access the network, the real value is not in the device, but rather in participating in the network.

So, the mobile network operators usually don’t care about securing the phones which are at the edges of their operations. Instead, they care about protecting the central resource — the network — and the practical result is that their keycode systems are designed around the availability of a centralized authorization mechanism.

In fact, while scratch cards are an integral part of the network operators’ keycode systems, it’s important to understand that they’re just a small part of a larger picture.

In the above diagram, the network operator distributes the scratch cards to the points of sale, just like any other sort of physical inventory. The customer buys a scratch card, types the pay-as-you-go keycode into their phone, the network operator validates it, and finally allows the phone to access the network.

The key aspects here are:

• The keycode is validated centrally, by the network operator, not by the phone;
• The scratch card is merely a method of distributing the keycode to the customer;
• Ownership of the scratch card is proof of purchase.

Additionally, what may not be obvious from this diagram is that:

• The input method — the phone — has a radio and is connected to the network;
• The customer may only purchase scratch cards on an ad hoc basis;
• The codes from any scratch card may be entered on any phone;
• Each code is unique, and may be used only a single time.

 

Designing Secure Pay-As-You-Go Keycode Systems for Product Financing

In contrast, when designing a metered system for product financing, the goal is to ensure the device’s usage is authorized, else it should be prevented from turning on. The devices may not be able to directly communicate with any central authority. Adding a GSM radio to a device, for example, is cost prohibitive when that device retails for less than $150¹. This constraint is one of several that make this problem more difficult.

This constraint implies that the devices themselves must be able to validate the codes, which pushes the authorization mechanisms all the way out to the edges of the system. That problem is considerably more difficult to solve, for reasons that will become apparent later.

In this diagram, we are assuming that the user has a mobile phone and access to mobile money. This assumption is often the case in many of our operating territories, but not always².

In any case:

• Notice how the network operator is still involved. When a user wants to make an installment payment for their device using mobile money, the payment goes through the Network Operator, and all of the money being transferred stays inside their mobile money system.
• The Angaza Hub³ receives a notification that a payment was made successfully. This notification is, in other words, a receipt. Again, no money has been transferred out of the mobile money system at this time.
• The receipt is proof of a purchase. The Angaza Hub sends the keycode to the user, usually via an SMS, when that proof is received.
• The user physically types the keycode into the solar device. If the keycode is authorized, then the device is enabled.

Again, some non-obvious points about this type of system design:

• The only time that a user needs cell phone coverage is the short period of making a mobile money payment and receiving the keycode SMS. After receiving the SMS, the user is free to travel the “last mile” back to their house, where there is no electrical grid and potentially no cell coverage.
• The solar device is not consistently connected to any sort of network⁴ at all, and must be able to decide on its own whether a keycode is valid or not.

If you take anything away from this post, it’s the difference between the security mechanism of a mobile network versus pay-as-you-go product financing.

• Mobile Network = Centralized Gatekeeper
• Pay-as-you-go Product = Distributed, Per Device

As we’ll find out, the distributed nature of validating keycodes for a pay-as-you-go product is the dominant factor in the design of the overall keycode system. In our next installment, we’ll finally start exploring the design space.

—

¹ All prices are quoted in USD PPP.

² Angaza supports many types of operational work flows, including pure cash, but for clarity, this article focuses on mobile money scenarios.

³ Angaza’s B2B SaaS product for solar distributors.

⁴ In this specific context, the solar device isn’t connected to a network because it is inexpensive and doesn’t have a GSM radio, so the technical challenge of keycode authorization must be done purely in the device itself, and can’t just ask a server somewhere. However, even more expensive devices with a GSM radio that could communicate directly with a server, could benefit from independent authorization in situations where the GSM connection isn’t currently working. must have some way of independently validating keycodes in order to prevent replay attacks.