Did you know that in our LINK App you can compare Word files?
Compare two files
Compare two versions of a file
Compare an attachment in email to a file in DMS
Watch this 16 second video to view comparing two versions of a file in iManage Work in the LINK App.
LINK has the compareDocs engine from DocsCorp built-in for high fidelity comparison results within the LINK secure container.
LINK is integrated with iManage Work®, NetDocuments DMS, OpenText eDocs, and Outlook email. In a single app, compare your files, then email or check-in to DMS.
Watch this video to see full workflows using in-app comparison and using the Word app for editing.
If have any questions, write to us at: contact at mobilehelix dot com. We’d be happy to answer your questions.
We have developed several editing workflows using the Word app over the years. Our newest one is the easiest one which we have seen anywhere. This is in part because our LINK app securely integrates your Document Management System and Email with the Word app. Therefore, you can choose to edit a file from DMS or an email attachment and it will open directly in Word.
Take a look at our 2 minute, 44 second video to see this workflow.
Here’s what you don’t have to do in our workflow:
No need to copy the file in the Word app. LINK encrypts the file and moves it to Word.
No need to save the file as .docx in the Word file. LINK converts .doc to .docx for you.
No need to delete the file from the Word app after editing. LINK deletes it.
This video shows how straightforward it is to edit from LINK with the Word app.
LINK is integrated with iManage Work® 10, on-prem and in the Cloud; NetDocuments DMS; OneDrive; Network File Shares; and OpenText eDocs is in development. LINK is also integrated with Microsoft Exchange, therefore, you have your Outlook Email, Contacts, Calendar, Tasks, and Notes within the LINK App.
If your attorneys are looking for a simple way to edit files in DMS or in Outlook email with the Word app, email me. We are happy to show you a demo of this workflow.
iOS has solid encryption, there is no backdoor, hence, your firm’s data is safe under lock and key, correct? Not necessarily. Enlightening new research by cryptographers at Johns Hopkins University (1) has surfaced weaknesses in the iOS and Android encryption schemes. Ironically, in the case of iOS, part of the weakness is related to a security hierarchy which is often unused.
“Apple provides interfaces to enable encryption in both first-party and third-party software, using the iOS Data Protection API. Within this package, Apple specifies several encryption “protection classes” that application developers can select when creating new data files and objects. These classes allow developers to specify the security properties of each piece of encrypted data, including whether the keys corresponding to that data will be evicted from memory after the phone is locked (“Complete Protection” or CP) or shut down (“After First Unlock” or AFU) …
… the selection of protection class makes an enormous practical difference in the security afforded by Apple’s file encryption. Since in practice, users reboot their phones only rarely, many phones are routinely carried in a locked-but-authenticated state (AFU). This means that for protection classes other than CP, decryption keys remain available in the device’s memory. Analysis of forensic tools shows that to an attacker who obtains a phone in this state, encryption provides only a modest additional protection over the software security and authentication measures described above.” (JHU – bold is our addition)
The reality is that most of our iPhones are commonly in “After First Unlock” state because we rarely reboot our phones. To achieve maximum security, we would have to power down our iPhones and authenticate after each use. That is, scores or hundreds of times per day. Otherwise, all data in the AFU state is vulnerable to law enforcement agencies or criminals with the right forensic tools. As the Hopkins researchers noted, “Law enforcement agencies, including local departments, can unlock devices with Advanced Services for as cheap as $2,000 USD per phone, and even less in bulk, and commonly do so.”
“There’s great crypto available, but it’s not necessarily in use all the time,” says Maximilian Zinkus, Johns Hopkins University. The Hopkins researchers also extended their analysis to include the vulnerability of iCloud services and device backups:
Device owners may take actions to ensure greater security. Apple Insider cites a few user actions including: Use SOS mode; use the setting which locks iOS devices after 10 failed login attempts; and don’t use iCloud back-ups. But these user-optional mitigations are not adequate for enterprise security, and they don’t address the forensic techniques used to steal data in the AFU state. Enterprises need systematic approaches across all firm-managed devices.
Why Secure Containers Are Needed
Sophisticated attackers and government agencies have a variety of available tools at their disposable to extract sensitive data from a seized or stolen device. The preponderance of evidence shows that law enforcement is largely successful in cracking open a device and extracting sensitive information as needed. Evidence further suggests that these techniques are ported to even the latest iOS versions and devices (take a close look at https://www.grayshift.com/ – they offer the state-of-the-art in device forensics). What can you do to truly protect sensitive data? The built-in capabilities of the operating system are not sufficient.
Secure containers provide an additional layer of encryption by implementing an entirely independent encryption mechanism to protect data. To examine the protection offered by secure contain apps, we will refer to our LINK app in this discussion. LINK not only uses its own, independent encryption scheme, Link also uses its own built-in encryption technology. In other words, the LINK encryption software stands entirely independent from the operating system, regardless of whether that operating system is intact or compromised. As long as encryption keys are protected well, then secure containers can provide the kind of locked-down encryption that law firms want to protect email and documents, which encapsulate a large majority of a firm’s most sensitive data.
LINK’s data protection exceeds iOS in a few significant ways:
LINK is an app, and iOS apps are routinely removed from memory. Hence, while LINK does necessarily keep encryption keys in memory when the app is active, once the app is removed from memory its encryption keys are too. This stands in contrast to iOS’ “AFU” encryption.
LINK allows IT to identify data that is only accessible when the device is online. This makes it awfully difficult to get the encryption keys for that data, especially once the device has been identified as lost or stolen and flagged for a remote wipe.
LINK’s online encryption keys are really hard to guess. Offline keys are hard to guess too, as long as your organization uses complex A-D passwords. Online keys are not derived from a user’s passcode or even a user’s A-D password. LINK’s encryption keys are derived from randomized 32-character strings that are generated on the LINK servers using entropy available on the server. Brute-forcing the key derivation is unlikely to work, which means an attacker would have to compromise the LINK Controller that sits safely inside our customers’ networks, then break the encryption scheme protecting sensitive data stored in our Controller database. Getting LINK data is a lot more complicated than stealing or seizing a mobile device.
LINK aggressively limits the amount of data available on the device, online or offline. We do so by simply expiring away data that sits unused on the device. This is a really simple way to limit exposure without much practical impact on a user. Users can always go back to their email (via search) or to the document management system to find what they were working on. There is no practical reason to store lots of old, unused data on a device that is easy to steal and, as it turns out, compromise once stolen.
LINK’s data is useless when obtained from an iCloud backup or a local backup to a Mac device. LINK’s encryption keys are never backed up. An attacker’s best hope is to brute force both the iOS device passcode and the user’s A-D password before IT notices that the device is lost or stolen. This is incredibly difficult to accomplish given Apple’s built-in protections against brute-forcing passcode and given a reasonably complex, hard-to-guess A-D password.
The JHU research simply reminds us that Apple’s interests diverge widely from those of an individual law firm. Apple has to balance the needs of law enforcement and users to make data accessible while still providing a reasonable degree of protection. Law firms’ best interests lie in maximally protecting data against unauthorized access. In order to achieve this latter goal, Apple’s built-in technology simply won’t suffice.
-Seth Hallem
Seth Hallem is the CEO, Chief Architect, and Co-Founder of Mobile Helix, makers of the LINK App. With LINK professionals can review, annotate, compare, and email files, as well as use the firm intranet, using a single secure container app. www.mobilehelix.com
For easy and secure document review, we have integrated our own document viewer in our LINK app. When you tap on a document name in LINK, it automatically opens in the LINK document viewer. LINK renders all documents as a PDF for high fidelity to the original. If there are Tracked Changes or redlines in the document, they are rendered as well. Or, you can elect to accept them and view a clean copy of the document.
I’m a current events junkie. I’ll admit it. And I work with law firms. Thus, my favorite podcast? “Stay Tuned with Preet.” Yes, this is Preet Bharara, the former U.S. Attorney for the Southern District of New York. Check out an episode. Preet takes a few questions about the law at the beginning of each episode. Then he has a guest. Preet is not only smart, but surprisingly personable. It’s a fast-moving hour.
A recent guest was John P. Carlin, former Assistant Attorney General for the National Security Division at the Department of Justice and Chief of Staff to Robert Mueller at the FBI. He is currently a partner with Morrison & Foerster. Carlin is an international cybersecurity expert.
One of the things which caught my attention in this episode was Carlin’s story of the US subsidiary of a German company whose data was stolen by hackers in the Chinese military. The company, SolarWorld, in Hillsboro, Oregon, made solar energy components.
How was the data stolen? Email. Carlin said, “Email. It is the least protected part of the system, usually. Not like Intellectual Property which is encrypted or where special measures are taken to protect it. They stole email traffic.”
In the investigations of Paul Manafort and Michael Cohen, the FBI has retrieved messages from Signal, Telegram and WhatsApp. While there are weaknesses inherent in all of these apps, the question remains: What does a good data protection scheme look like?
A few days ago, the FBI revealed that Michael Cohen’s messages sent with Signal and WhatsApp
are now available as evidence in the on-going investigation into his
various dealings. While thousands of emails and documents have already
been recovered from Cohen’s devices, home, hotel room, and office, the
recovery of data from messaging apps that promise end-to-end encryption
is surprising. One would presume that end-to-end message encryption
should ensure that those messages are unrecoverable without assistance
from Mr. Cohen. However, clearly that is not the case.
By Seth Hallem, Moble Helix CEO, Co-founder, & Chief Architect
Secure email using S/MIME and OpenPGP is fundamentally broken. Our CEO explains the EFAIL vulnerability and why our LINK Email is not susceptible to EFAIL. What do we do next to protect email?
On Sunday night, a team of researchers from Germany and Belgium dropped a major bomb on the world of encrypted email by describing a simple, widely applicable, and wildly effective technique for coercing email clients to release encrypted email contents through “Exfiltration channels.”[1] The concept is simple – by using a combination of known manipulation techniques against the encryption algorithms specified in the S/MIME and OpenPGP standards and lax security choices in a wide variety of email clients, the research team was able to intercept and manipulate encrypted emails such that large blocks of the encrypted text are revealed to a malicious server.
What is most brilliant (and most dangerous) about this attack, is that the attack does not require decrypting the email messages or stealing encryption keys. Hence, the attack can be deployed as a man-in-the-middle attack on the infrastructure of the internet itself, rather than requiring that a specific email server or email client is compromised.
The essential idea behind this attack is simple – HTML emails expose a variety of reasons to query remote servers to load parts of those emails. The simplest (and most common) example of this concept is displaying embedded images. Many marketing emails use tiny embedded images to monitor who has opened an email. This technique is so pervasive that many of us have become desensitized to clicking the “Allow images from this sender” prompt in Outlook. It is common practice for marketing emails to contain embedded images with essential content, which encourages users to allow the client to load all images in that message. However, doing so loads both visible images and tiny, single pixel images that marketing tools use to uniquely determine that we have opened the email message in question.
