End-to-end payload encryption made easy
Communicating securely on public networks with multiple protocols, platforms, and cloud services over different communication technologies with constrained bandwidth and devices is complicated.
We make it easy.
By innovative streamlining and packaging of proven industry standards, we enable developers, in just a few lines of code, to implement sophisticated, secure and scalable applications for Internet of Things and anything mobile.
The core of the Apptimate service is a message or object broker designed for scalability, secure and efficient queuing and robustness.
The broker connects multiple protocols: Our own internal Portable Message Protocol (PMP), our Asynchronous File Transfer and multiple standard protocols, like XMPP, HTTP, WebSockets, MQTT (available soon), CoAP (available soon) and AMQP (available soon). We will add more protocols upon customer requests.
All these communication mechanisms are then protected by an Object Security layer. A single asynchronous security model providing end-2-end payload encryption between any device on any protocol, with integrated Encryption Key Distribution Infrastructure.
Everything provided as separated binary SDK modules for integration into the device application. You can implement the whole service, just the message broker or add object security and payload encryption to your own communication mechanisms.
Characteristics of IoT Applications:
Currently, the trend is towards cloud hosted web services, hub-and-spoke architectures, and vertical integration. In the near future, IoT systems will also:
The solution to this is rapidly evolving need is a flexible message broker optimized for multi-protocol or polyglot brokering. An agnostic broker that is easy to implement in new and existing applications and deployable wherever the application requires.
Transport layer security is not sufficient in many applications. TLS/DTLS only supports trust models with fully trusted endpoints. Multiple end-to-end transport security sessions for the different clients and multiple handshakes would be heavy for constrained resource servers and is a very inflexible solution. HTTP supports TLS tunneled through a proxy, but, for instance, CoAP does not, so DTLS must be applied hop-by-hop.
Another important aspect is key distribution mechanisms that need to be transparent to all connected devices disregarding suppliers and protocols.
All this means very complicated security implementations. Apptimate reduces this to a single model for the application developer, meaning full end-2-end security in just a few lines of code.
Sending files or large chunks of data between two endpoints requires a secure tunnel with both parties awake and connected at the same time. This can be difficult in a mobile connection, especially if a device saves battery by staying asleep as much as possible.
Apptimate has implemented a specific protocol to solve this problem; SAFT – Secure Asynchronous File Transfer. This means that the sending device just encrypts and sends the file disregarding if the recipient is online. It also handles the case of a recipient dropping out in the middle of a transfer. The parts not received is kept waiting in a secure cloud-based queuing system in encrypted and non-accessible format. When the recipient comes online the queues are read and emptied.
This powerful protocol is, for instance, highly suitable for over-the-air firmware updates, or system integration of batch generated data files.
RIKS provides multicasting (1 sender to N receivers) of symmetrically encrypted messages while sharing the associated keys to a selected subset of the N receivers. Key sharing is not restricted to occur before sending a message, i.e. a key can be requested after receiving an encrypted message.
This protocol makes backward security flexible; a message recipient can retroactively be given access to priorly obtained or cached messages without re-encrypting them with a new key known to the recipient. This allows for simple adding and removal of users in a group, unlocking historical data for new group members while providing simple revocation of access when members leave the group.
Implementations can be, for instance, in central storage of encrypted data that is only accessible at a later stage when the key is distributed to a group of users, like group messaging, or when you need to protect subsets of data in a central application server from access by anyone except a specific group of users and devices.