« Mick Moignard: Has Word Hindered Collaboration? | Main| Domino Designer 8.5 Tip: Where Working Sets Are Stored »

iNotes Encryption Puzzler: How to Permanently Decrypt All Messages?

Category    

iNotes (aka Domino Web Access/DWA) has for a while provided us the ability to read and write encrypted email by attaching the user's Notes ID to a profile document named (what else?) $shimmerid. Any time the user opens an encrypted message in iNotes they are prompted for their Notes ID password. Well, not necessarily their "current" password but the password of the ID when it was imported into their mail file way back when. Anyway, it's a process that is a little kludgey, but works well enough and certainly achieves the goal of making it hard for people who are not you to read your extra special secret messages. Which is great until you *want* someone else to be able to read your extra special secret messages (e.g. your Admin Assistant, or maybe your corporate audit department). If we were all using the Notes rich client, this would be no big deal, but some folks *only* use iNotes. so it is a big deal.

So I need to figure out a way to permanently decrypt (i.e. save without encryption) all "encrypted" messages without involving the user logging into the Notes client.
 
Considering the ID file is (sort of) available on the server in the aforementioned $shimmerid profile document, it *should* be possible to achieve this by either a) utilizing an agent running on the server provided that the password of the stored user ID file is also stored in some form that the server can access, b) triggering a similar process when the user opens iNotes and enters their id password, or c) performing some other clever trick which you are going to share with us.

I've had some partial success by adding a webqueryopen agent (i.e. user triggered) that is able to *copy* an individual message in decrypted form but cannot save any changes to the current document if it is encrypted (which is kind of the point). The error thrown is "Cannot update note due to NOTE_FLAG2_NO_UPDATE being set" whatever that means. The copy approach is not a bad fall back, but does require the owner to actually read every encrypted message, which may not happen, at least not in a timely fashion.

The automated approach is obviously favored, and at the moment I am looking at the C API as my best hope of accessing that stored id file and using it to decrypt everything on a scheduled basis. The particular functions that appear to be most relevant are SECKFMOpen and SECKFMClose to access the id file and NSFNoteCipherDecrypt to actually do the decryption. I have been attempting to call these functions from within LotusScript but with little success so far (I am alas not a C API expert). Since the regular iNotes process to read encrypted messages apparently involves a server task, likely using these functions, you would think it ought to work.
 
So is there reason to hope for success in this endeavor? Have you been down this road only to see it dead end? Can the ID Vault's auditor functions be tapped programmatically? Do you have a better approach entirely? Your helpful thoughts are most welcome.

Comments

1 - I'm not sure I can add much to it, but I'd be *very* wary of a server having access to both my password and user id. I'd probably fail an app on a security audit because of that. I'm guessing that the server-side decrypt process is a very secure engine using a password hash or something similar.

From an admin point of view, I'd like to see some client side code to do the decrypt - so the users' password never leaves the browser.

I'd also be concerned about leaving a good audit trail behind - so creating a new, unencrypted, document wouldn't be that bad an idea.

2 - Thanks Warren. You're right that giving the server access to both the IDs and passwords is going to make it very hard to ensure security of databases well beyond mail. At a minimum I would sign the agent doing the decrypting with a special purpose id with the necessary access and not the server id. It's much too easy to sneak another agent signed by the server into the environment which can then scoop up all that "secure" password information.

The point about the method of transmission of the password via the web is also good. I was hoping to avoid having to come up with a custom approach for that, instead relying on the built-in feature which is already tested.

By the way, for anyone out there now trying to peek at how the built-in process works, it might help to know where the obfuscation translation file is located. If you look in the Forms8.nsf or Forms85.nsf design for a file resource called "ObfuscationList.txt" you will get the translations of all the various 2- and 3-character abbreviations used throughout iNotes to reduce network traffic.

3 - Newer iNotes ID Vault integration in 8.5.1 should keep the most recent ID (and associated password) within the mail file. Why is sending the password to the server via SSL not secure?

These are probably the APIs you are seeking:
{ Link }

If you wanted your AA to be able to read your encrypted messages with Notes, wouldn't you have to give him/her your id file and password? If so, is that different than letting them login directly to iNotes as you from the browser?

I've thought about allowing AAs to send encrypted messages from an administered mail file in the future, and that would require they be able to access their ID while within another mail file.

Post A Comment

:-D:-o:-p:-x:-(:-):-\:angry::cool::cry::emb::grin::huh::laugh::lips::rolleyes:;-)

Your Host

KevinPettitt.jpg
Kevin Pettitt View Kevin Pettitt's profile on LinkedIn

Tools I Use

Idea Jam

Subscribe to This Blog

 Full Posts  Comments

MyYahoo
netvibes Add to Netvibes

Contact

Hosted by

OpenNTF

Disclaimer

This site is in no way affiliated, endorsed, sanctioned, supported, nor blessed by Lotus Software nor IBM Corporation, nor any of my past or future clients (although they are welcome to do so). The opinions, theories, facts, etc. presented here are my own and in no way represent any official pronouncement by me on behalf of any other entity.

© 2005-2017 Kevin Pettitt - all rights reserved as listed below.

Creative Commons License
Unless otherwise labeled by its originating author, the content found on this site is made available under the terms of an Attribution / NonCommercial / ShareAlike