DIMO and User Privacy
When a car is connected to DIMO, data is stored in the following way:
- Public data: vehicle make, model, year and place of manufacture, the blockchain user address of the owner and other owners
- Private data: everything else can only be seen by the user and those they opt-in to sharing data with. This private data includes vehicle telemetry data, location, VIN, documents, and more.
Today, users who connect through DIMO Mobile are asked to opt-in to share their anonymized and aggregated data with Digital Infrastructure Inc, the core company responsible for developing the DIMO project. Digital Infrastructure Inc. works to monetize data through sales, and this can help reduce the cost (via passed through earnings) to those using DIMO.
The only place to purchase that data today is through direct contact with Digital Infrastructure Inc. This data cannot be linked to a specific VIN. Examples include cellular coverage information, weather data, road quality. In summary, “public goods” use cases that we benefit from collectively.
It’s important to remember that the primary use case for data is for customers to use it themselves in their own day-to-day operations and in the DIMO marketplace.
How DIMO Secures User & Device Data
We adhere to principles of transparency (no security through secrecy) and least privilege. Our communication channels are end-to-end encrypted/ All data access is scoped by roles and we rely on strong user authentication to identify requesters.
All traffic is encrypted with a minimum supported TLS version of 1.2 and HSTS for any communication between user and platform, device to platform or between services in the platform
DIMO uses hardware based security modules for storage of asymmetric and symmetric encryption keys. Private keys are never exposed anywhere outside of the HSM and DIMO cannot retrieve them.This is for both web services and hardware devices themselves.
DIMO takes full database snapshots on a daily basis and uploads transaction logs for database instances to backup storage every 5 minutes. These snapshots are stored for 7 days, accordingly DIMO can safely restore databases to any point in the last week (with 5 minute granularity) as needed.
DIMO-managed databases are encrypted at rest, independently from the fact that any user-data is itself encrypted end-to-end. This includes
DIMO system currently has immutable audit logs generated via Amazon Cloudwatch. Every wrapper key generation, and data key encryption or decryption event appends an entry to the log. In parallel, DIMO logs data accesses from the KMS. DIMO plans to open up these logs to all users and developers in the near future. This will enable end-users to verify how their data is used, as well as developers to audit HSM usage on their end.
Public data: vehicle make, model, year and place of manufacture, the blockchain wallet address of the owner and various role holders who can see vehicle data, and the user generated image.
Private data: everything else can only be seen by the user and those they opt-in to sharing data with. This private data includes vehicle telemetry data, location, VIN, documents, and more.
As an open and extensible building block, further data can be attached over time, increasing the value of the vehicle ID as a digital asset.
Each device in the DIMO network must have its own ID which conforms to a W3C standard. Such identity exists without any central authority and is securely and privately linked to other identities (e.g., an owner and authorized drivers). This allows the device to manage its own data and, in the future, transact with other devices.
The cost of minting the device on-chain as an NFT provides some protection from sybil attacks, and DIMO apps are required to provide a proof that they've received telematics or verified documentation from the vehicle owner prior to minting, and the same vehicle cannot be minted with an "Active" status twice.
Each device ID will reference where the encrypted and signed data is stored. This will provide a future-proof way to address the device as well as integrate with other distributed systems.
To guarantee the security and authenticity of the device data being sent over the network, the data is signed by an Ethereum (or similar) wallet using secp256k1 ECDSA signing and verification. The data will be validated on receipt and checked against historical data from the device, and other meta-information contained in the payload.