Building Electrum's IoT Ecosystem: A Journey to Scalable and Secure Battery Swapping for Urban Mobility

Building Electrum's IoT Ecosystem: A Journey to Scalable and Secure Battery Swapping for Urban Mobility

In our last post, we dove into how Electrum harnessed the power of ClickHouse to build a data-driven, scalable platform that’s now central to our daily operations. With real-time insights guiding each decision, we’ve streamlined maintenance, optimized logistics, and boosted performance across our fleet of electric motorcycles. This approach has been crucial in keeping our bikes on the road and minimizing downtime for our riders.

But data alone is just the beginning. As Electrum has grown, we’ve seen that to fully realize our vision, we need more than just insights—we need a secure, interconnected ecosystem where every part, from the bikes to the swapping stations, works together seamlessly. So, we set out to build a scalable IoT infrastructure that not only meets our needs today but also sets us up for the future of urban mobility.

Hi, I’m Andi Pangeran, Principal Software Engineer at Electrum.id. In this post, I’ll take you through the IoT ecosystem we’ve built, the security layers that keep it safe, and the key lessons we’ve learned along the way.


Why IoT is Key to Electrum’s Battery Swapping Model

For us at Electrum, battery swapping is more than just a feature—it’s central to our mission of creating sustainable, user-friendly urban transport. Our goal is to make swapping a battery as easy as filling up a tank. But doing this on a large scale, with thousands of batteries across numerous locations, comes with unique challenges. To make it work, we need to monitor battery health, ensure station availability, and manage secure user access—all in real time.

This is where IoT changes everything. By connecting every bike, battery, and station to our backend, we can:

  • Monitor Battery Health: Real-time data on charge levels, temperature, and usage patterns supports predictive maintenance, preventing disruptions.
  • Optimize Station Logistics: With full visibility into station activity, we ensure charged batteries are available when and where our riders need them.
  • Secure User and Device Access: Each device communicates through secure channels, keeping user data safe and our operations protected.

However, building this interconnected system presented significant security and scalability challenges—We approached this challenge by designing an IoT security model that prioritizes:

  • Device Authentication: Each device is rigorously verified before gaining access to our network, ensuring that only trusted, authorized devices are part of the ecosystem.
  • Real-Time Communication: With thousands of devices transmitting data simultaneously, Our infrastructure quickly processes data from thousands of devices, all while upholding rigorous security standards.
  • Scalability: The infrastructure must expand as our network grows, accommodating new devices without compromising security.

This security protocol, known as Electrum’s IoT Platform Security Protocol, forms the backbone of our IoT ecosystem. Built for resilience and scalability, it meets the unique demands of our IoT environment while safeguarding user data and operational integrity.


Overview of Electrum’s IoT Platform Security Protocol

We developed Electrum’s IoT Platform Security Protocol to secure every device in our ecosystem—from bikes to battery-swapping stations—from setup through operation. This protocol keeps information flowing smoothly while safeguarding each device’s identity and connection within our network.

Here’s a breakdown of the process, with each stage contributing to the foundation of a secure and scalable IoT ecosystem.

1. Key Generation

Each device batch manufactured for Electrum’s IoT network is initialized with a unique private key generated by the manufacturer. From this private key, a public key is derived and shared with Electrum’s administrative team. This public key, paired with essential device details (such as device type, manufacturer name, and batch number), acts as a secure and unique identifier for each device batch, linking each device to Electrum’s ecosystem from the start.

2. Device-Specific Secrets

For every individual device within a batch, the manufacturer generates a unique device-specific secret using the batch’s private key. This secret, stored on the device, establishes a secure identity before it even connects to the network. As a result, each device has a unique, verifiable identity that enables secure communication within Electrum's network.

3. Authentication Process

When a device activates for the first time, it sends a request to our platform, including its key ID and device-specific secret. Our platform verifies these credentials by cross-referencing the key ID and public key in the registry. If the credentials are authenticated, the platform responds by issuing an access token, authorizing the device to communicate securely with our backend system.

Each of these steps ensures that the devices connected to Electrum’s IoT network are securely authenticated, protecting both user data and network integrity.


Step-by-Step Device Provisioning: Securing Identity Registration

The following diagram illustrates the detailed process of device identity registration within Electrum’s system:

sequenceDiagram

    Admin->>+Portal Web: Register Provisioning Key {key-id, public-key, device info)

    Portal Web->>+Device Provisioning Service: register

    Device Provisioning Service->>Device Provisioning Service: validate request

    Device Provisioning Service->>+Device Provisioning DB: upsert by key-id

    Device Provisioning DB->>-Device Provisioning Service: existing BatchDeviceKey

    Device Provisioning Service->>-Portal Web: return success

    Portal Web->>-Admin: return success


Detailed Walkthrough of the Device Identity Registration Process

  1. Admin Initiates Key Registration
    The registration process starts with the Admin, who submits a provisioning request on the Portal Web interface. This request includes essential identifiers such as the key-id, public-key, and additional device details, which together form a Provisioning Key. This registration establishes a secure and unique identity for each batch of devices.
  2. Portal Web Forwards Request to Device Identity Service
    The Portal Web interface forwards the registration request to the Device Identity Service, which is responsible for processing, validating, and securely storing device identities in our backend.
  3. Device Identity Service Validates the Request
    The Device Identity Service performs an initial validation on the incoming request. This validation ensures that the structure and contents meet Electrum's security standards, confirming that the provisioning key includes all necessary fields and matches our expected structure.
  4. Database Upsert Operation
    Following validation, the Device Identity Service performs an upsert operation on the Device Identity Database. This operation updates an existing record if it matches the key-id; otherwise, it inserts a new record. This approach prevents duplicate records, ensuring that each device identity is stored uniquely.
  5. Database Confirmation and Success Message
    Once the Device Identity Database confirms the BatchDeviceKey record’s storage, the Device Identity Service sends a success response back to the Portal Web interface. This final message notifies the Admin that the device identity registration was successful, completing the process.

This registration workflow enables Electrum’s infrastructure to maintain secure, authenticated identities for each device batch, forming the backbone of Electrum’s IoT security model.


Access Token Generation and Login Sequence

Once devices are registered, the next essential step is to enable secure access to the Electrum network. The following sequence details the two-phased process of access token generation and device login, both fundamental to ensuring that only authenticated devices can connect and communicate within Electrum’s ecosystem.

sequenceDiagram

    Device->>+Device Gateway: request access token {dev-id, key-id, secret}

    Device Gateway->>+Device Provisioning Service: request access token

    Device Provisioning Service->>Device Provisioning Service: validate request

    Device Provisioning Service->>+Device Provisioning DB: lookup provisioning data by key-id

    Device Provisioning DB->>-Device Provisioning Service: existing provisioning-data

    Device Provisioning Service->>Device Provisioning Service: validate secret using public-key

    Device Provisioning Service->>+Device Service: register new access {dev-id, device-info}

    Device Service->>+Device Service DB: upsert device-info by dev-id

    Device Service DB->>-Device Service: device-info updated

    Device Service->>Device Service: generate new access-token

    Device Service->>+Device Auth Redis: add new access-token for dev-id, with TTL

    Device Auth Redis->>-Device Service: new access-token stored

    Device Service->>-Device Provisioning Service: return success {access-token}

    Device Provisioning Service->>-Device Gateway: return success {access-token}

    Device Gateway->>-Device: return success {access-token}

    Device->>+Device Gateway: login {dev-id, access-token}

    Device Gateway->>+Device Service: login

    Device Service->>+Device Auth Redis: get value by access-token

    Device Auth Redis->>-Device Service: dev-id

    Device Service->>Device Service: verify dev-id is same

    Device Service->>+Device Session Redis: add new session for dev-id, {dev-id, pod-id}

    Device Session Redis->>-Device Service: new session stored

    Device Service->>-Device Gateway: return success

    Device Gateway->>-Device: return success

Phase 1: Access Token Generation

  1. Device Requests Access Token
    Each device begins by submitting a request to the Device Gateway to obtain an access token. This request includes the dev-id, key-id, and the unique device secret, which together verify the device’s identity.
  2. Forwarding to Device Provisioning Service
    The Device Gateway forwards this request to the Device Provisioning Service, which is responsible for provisioning and authenticating each device in the network.
  3. Request Validation and Provisioning Data Lookup
    The Device Provisioning Service validates the incoming request, ensuring the provided data is formatted correctly and matches expected parameters. It then queries the Device Provisioning Database to retrieve the provisioning data associated with the provided key-id.
  4. Validation of Device-Specific Secret
    Using the associated public key, the Device Provisioning Service validates the device-specific secret, confirming that the request is legitimate and that the device is authorized.
  5. Device Access Registration
    Upon successful validation, the Device Provisioning Service registers the device’s access by storing the device ID and related device info in the Device Service Database via an upsert operation, avoiding duplicate entries.
  6. Access Token Generation and Storage
    A new access token is generated, authorizing the device to authenticate for subsequent operations. This token is stored in the Device Auth Redis cache with a Time-to-Live (TTL), which limits the validity of the token to a specific timeframe.
  7. Return Access Token to Device
    The access token is sent back through the Device Gateway to the device, authorizing it for login and enabling secure interaction with Electrum’s backend.

Phase 2: Login and Session Creation

  1. Device Initiates Login with Access Token
    Armed with the access token, the device sends a login request to the Device Gateway, containing the dev-id and access token to authenticate itself.
  2. Login Request Validation by Device Service
    The Device Gateway forwards this login request to the Device Service, which retrieves the token’s value from the Device Auth Redis cache and validates it against the dev-id.
  3. Session Creation
    After validating the token, the Device Service creates a session for the device by storing session information in the Device Session Redis cache, which includes the device ID and other session identifiers.
  4. Successful Login Confirmation
    The Device Service sends a success response back to the Device Gateway, which then notifies the device of a successful login. This confirmation indicates that the device now has an active, authenticated session, securing its ongoing communication within the Electrum network.

Reflecting on Electrum’s Journey: Achievements and Growth

Today, our progress is a testament to the vision, resilience, and technical innovation driving Electrum forward. We now have a fleet of over 3,000 electric bikes, supported by more than 250 battery-swapping stations across our service areas, with each bike covering an impressive 220 kilometers daily. This scale didn’t come easy—it’s the product of continuous learning, adapting to new challenges, and our commitment to creating a seamless, sustainable urban mobility experience.

The IoT infrastructure we’ve developed has been pivotal in making this growth possible. From monitoring every moving part to securing every data point, we’ve built a system that’s not just large but resilient and adaptable. Each decision along the way has brought its own set of lessons—sometimes anticipated, often surprising—and it’s those lessons that have strengthened our foundation.


Lessons Learned and Technical Takeaways

Through the process of building and scaling Electrum’s IoT ecosystem, some key lessons have come to light:

  • Make Security a Core Priority: Securing a large-scale IoT network demands constant vigilance. Building security measures right into the foundation of our platform has helped us ensure that user data and operations stay safe as our network expands.
  • Use Real-Time Data to Drive Excellence: Real-time data has been a game-changer for us. It lets us monitor fleet metrics and react in real time, which is essential not only for keeping things running smoothly but also for proactive maintenance that keeps our fleet ready and available.
  • Scalability Is a Journey, Not a Destination: Scalability is an ongoing process. Our platform continues to adapt to new demands, reminding us that building for the future is about being ready for the unexpected as we grow.

Conclusion

Our journey from concept to a scalable, IoT-driven fleet serving urban commuters has been one of constant innovation, learning, and adaptation. Each challenge we’ve encountered has only strengthened our belief that technology can truly transform urban mobility, making it more sustainable and user-focused. We’re committed not only to meeting the needs of our riders today but also to anticipating what tomorrow’s cities will require. We’re excited to keep pushing forward, and we’re grateful to have you on this journey with us.

Looking ahead, we see each kilometer covered, each battery swapped, and each new connection as an affirmation of what’s possible when engineering meets purpose. We’ve built a robust ecosystem, but this is just the beginning. With every system we refine and every insight we gain, we edge closer to a future where urban mobility is effortless, secure, and environmentally responsible.

Thank you for joining us on this journey. We’re excited to see where the road ahead will take us, and we look forward to sharing what’s next in Electrum’s story.