It’s fairly clear from discussions surrounding Cisco’s Spark platform at Cisco Live that the UC giant is putting a lot of its weight behind business messaging and team collaboration. During my time at the conference in Vegas I had a chance to not only speak with Jonathan Rosenberg and Jens Megger, but also sit in on their discussions of Spark and where the platform will go next. Safe to say Cisco is looking to leverage its massive user base of 215 million customers to take full advantage of Spark, and really push it into the mainstream.
Rosenberg said during his Enterprise Messaging keynote that Business Messaging will be the next big shift in communication technologies for teams both large and small. Previously it was calling, every office needed a phone system to keep in touch (and eventually video calling can be included in here), and then when email came along, everyone had to adopt the instant, electronic mailbox. Now, Rosenberg said, Business Messaging is rising to take the place of email. Not that email will go away, just like our standard snail mail hasn’t dissolved yet, but it team collaboration platforms will empower teams to accomplish more, faster.
Security is Key
But when you expect large Enterprise players to adopt your platform, you have take into account at least one major aspect – and that’s security. No business wants a third party snooping around their internal communications, even if that means the provider of the service themselves. To ensure everyone will adopt your platform, you have to ensure everyone will feel safe utilizing it. Cisco went out of their way to tick all of the boxes when they were building Spark from the ground up – they even went the extra mile to establish end-to-end encryption into the ground level fabric of Spark. The entire system has been developed with security, and encryption in mind.
A key benefit of Cloud Services is the fact that updates to the platform can happen as quickly as the cloud service provider can deploy them. A new feature can roll out the second its ready to go, and quickly be pushed to the existing user base, this could be called “adding value.”
Cisco’s Answer
However, for most consumer products adding value is done at the expense of the users. Usually requiring full access to user data and content the service can feel vulnerable. Or, on the flip side, locked down services that ensure security will sacrifice these value-added features in order to keep everything nice and secure. When compared to other solutions like Slack, Spark earns some extra points when it comes to its high level of security.
What Cisco did with Spark is strike a nice balance in the middle. End-to-end encryption that offers enterprises the ability to choose specifically which value-added integrations they would like to include. Going one-step further, while Cisco locks themselves out of your data, the Enterprise can have full access as it chooses.
Cisco said the system relies on an “open architecture for secure distribution of encryption keys and confidentiality of data.” This essentially means that content is encrypted on each user’s client and remains so until it reaches the recipient. Nothing in between each client has access to the decryption keys, unless the Enterprise decides to provide such access to users.
So How Does It All Work
In order to allow access to decryption, Cisco introduced a key system to provide full access to the data if necessary, and if granted to users. This system, the Key Management Server (KMS) is the foundation of the end-to-end encryption in Spark. This server will create, store authorize and provide access to the encryption keys. Essentially, the KMS is the gatekeeper to all your data and files. Based on permissions set by the Enterprise, only certain users may have access (IT individuals), while Cisco themselves are unable to see your content. Each Enterprise has its own unique KMS.
KMS = Key Management Server, your Cisco Spark Gatekeeper
The KMS itself is separate from the Core unit of Spark, they are their own “realms” working in conjunction. While the KMS is located in the Security Realm, everything else can be labeled as the Core unit of Spark. Keeping the realms separate is what ensures end-to-end encryption. The core elements of the platform do not have access to the encryption keys, and the system relies on the KMS to authenticate access tokens that aren’t used anywhere else in the cloud.
As Cisco puts it, this “ensures appropriate access to the encryption keys, while also guaranteeing no core service components can access those communications or keys that the KMS stores.”
In just another step to provide total control to the end user, Cisco even allows the option of the security realm as a hosted solution – that way Cisco does all the heavy lifting – or an on premise solution for the extra cautious Enterprise that really wants to lock everything down. With a hosted solution, all services in the Security Realm are located and operated in a separate tenant on a separate infrastructure. With on premise, well that’s up to the business to decide.
The Process in Action
To make a long story short, when a user wants to send a message to Spark room, that user’s client’s first step is to establish a secure channel between the client and the KMS. This step requires an authentication process between the client and the KMS, making it impossible for Cisco or any third parties to view or even modify any of the information in transit. After the authentication process, the client will use the established channel to request a new encryption key necessary to encrypt the content that will be sent to another client.
After the message is written, the client encrypts the message with a conversation key and labels it with the room ID of the destination Spark room, and sends it off to the core. The core then receives an encrypted message, and since it is kept separate from the Security Realm, does not have any access to the conversation keys needed to decrypt said message. The core looks for the recipient, and sends the encrypted message on its way to the receiving room, but also stores the message in a database associated with the receiving room.
Now the process happens in reverse, the receiving client is given an encrypted message, and contacts the KMS to get the necessary key to decrypt the message. The KMS authenticates both users to verify the necessary permissions to open the message and distributes the conversation key to the recipient so its client can unpack and read the message.
If Everything is Encrypted, How Does Search Work?
Since the Core itself never sees any of the content you’re transmitting, you cannot allow for simple message searching through the cloud service itself. To counter this, Cisco came up with something pretty unique – they built in an Indexer component directly into the Security Realm. Just as the KMS, the Indexer is completely separate from the Core, yet it is very close to the KMS. Essentially, the Indexer builds and queries the search index within the KMS. This way everything stays encrypted, yet searchable.
Turns out, the Indexer is actually a Spark Bot that is invited to every room, depending on the Enterprise policy. Every time a user sends a message, the Indexer receives a copyof the encrypted content, 
and like the client, talks with the KMS to access the necessary conversation key to open the message. The Indexer applies a hash, a way one authentication, to each word within the sent message and complies a list of all hashed words that belong to the specific room where the message was received.
The Indexer is even clever enough to add in random words to fully ensure the messages cannot have their encryption reversed. The list of hashes is then sent to the Spark Cloud and stored within the search index while in their encrypted state. Now you have a searchable, fully encrypted index.
The Best of Both Worlds
Cisco wanted to really provide the peace of mind that even the most paranoid Enterprise could feel secure sending its data and files through the Spark Cloud platform. Other consumer applications allow for, or may even rely on, access to the data by the service itself. With end-to-end encryption so deeply rooted into the development of Spark, and even the ability to host your own security realm, set your own parameters and provisions, you have the Fort Knox of Business Messaging and Team Collaboration.
