Encryption tools for MLS computers?

Discussions around using and interfacing with the Church MLS program.
RossEvans
Senior Member
Posts: 1346
Joined: Wed Jun 11, 2008 8:52 pm
Location: Austin TX
Contact:

Encryption tools for MLS computers?

Postby RossEvans » Tue Aug 18, 2009 7:42 am

MLS can export membership data in several formats, and policy dictates that those files be password-protected. Yet neither MLS nor the standard set of utilities installed on administrative computers can encrypt such files. This anomaly creates not only a Catch-22 but a real security weakness on the export media.

I suggest that this capability be provided. It would be good if it were provided by some standard method.

An easy solution might be to install some common utility such as commercial WinZip or open-source 7-Zip, both of which support 256-bit AES encryption. Alternately, MLS could build some encryption into the export function, perhaps creating an encrypted .zip file directly. Of course there are more complex solutions such as PGP available, which may be cryptographically superior, but I think AES is probably sufficient.

A church-provided solution would be better, easier and cheaper overall, but in its absence it seems that local units ought to do something to help local leaders and clerks comply with policy. Do any stake technology specialists install such software for local units, or just let them do it themselves?

There are individualized solutions such as portable software installed on flash drives, but they are expensive and/or complicated for end-users to deal with. I am experimenting with 7 Zip Portable myself, but I don't think it is optimal for everyone.

User avatar
aebrown
Community Administrator
Posts: 14693
Joined: Tue Nov 27, 2007 8:48 pm
Location: Sandy, Utah

Postby aebrown » Tue Aug 18, 2009 7:56 am

boomerbubba wrote:MLS can export membership data in several formats, and policy dictates that those files be password-protected.


What policy is that? I have never heard of such a policy. In the Policy and Guidelines for Computers Used by Clerks for Church Record Keeping, the Stake Technology Specialist is required to:

  • Ensure that computers, software, and confidential Church information are secure.
  • Ensure that authorized priesthood leaders who export membership data to PDAs use passwords to protect that data in the event the PDA is lost or stolen.
But it seems a stretch to say that these statements require that export files be password-protected when they are stored on a Church administrative computer, which is itself password protected and should have physical access controlled as well. It may be prudent, but I don't see how it is required. Am I missing some other policy statement?

RossEvans
Senior Member
Posts: 1346
Joined: Wed Jun 11, 2008 8:52 pm
Location: Austin TX
Contact:

Postby RossEvans » Tue Aug 18, 2009 8:17 am

Alan_Brown wrote:What policy is that? I have never heard of such a policy. In the Policy and Guidelines for Computers Used by Clerks for Church Record Keeping, the Stake Technology Specialist is required to:

  • Ensure that computers, software, and confidential Church information are secure.
  • Ensure that authorized priesthood leaders who export membership data to PDAs use passwords to protect that data in the event the PDA is lost or stolen.
But it seems a stretch to say that these statements require that export files be password-protected when they are stored on a Church administrative computer, which is itself password protected and should have physical access controlled as well. It may be prudent, but I don't see how it is required. Am I missing some other policy statement?


Perhaps I am wrongly interpreting general forum folklore as "policy." If the statement you quote is the only policy statement out there governing password-protection of export files, then I am wrong about policy in that sense. The quoted statement only governs the PDAs themselves (which am presuming might also include PCs, smartphones, etc. as the device.)

In another thread, jdlessley paraphrased a CHI passage about password-protected storage in a way that seemed more generalized. That is actually what jogged my thinking about the export files.

But even if it is not policy, I suggest it is still a good idea.

I am not talking about the exported files as they exist on the drive of the MLS computer, but the files as they exist on removable media being used to transport the files to another target device. The common media used to be floppies. Today it is flash drives. It is when the files are on such media in unencrypted form that they are most vulnerable.

User avatar
aebrown
Community Administrator
Posts: 14693
Joined: Tue Nov 27, 2007 8:48 pm
Location: Sandy, Utah

Postby aebrown » Tue Aug 18, 2009 8:40 am

boomerbubba wrote:I am not talking about the exported files as they exist on the drive of the MLS computer, but the files as they exist on removable media being used to transport the files to another target device. The common media used to be floppies. Today it is flash drives. It is when the files are on such media in unencrypted form that they are most vulnerable.


I missed that you were talking only about removable media (but you did indeed say "export media" in your post). Sorry about that.

I would actually tend to agree with you that it is a reasonable conclusion that once the data leaves the administrative computer, it should follow the same procedures and policies as a PDA. After all, it's just as easy (probably easier) for a flash drive to be lost or stolen than a PDA, so if the policy writers were careful to address the risk of PDA loss and thus require password protection, it seems logical that the same policy would apply to any electronic device or media that contains this highly confidential data.

I personally have used encrypted Zip files when I have needed to take such files off-site. It's simple and makes the files smaller while providing security. But it would be helpful to have a standard solution at least recommended, if not actually provided by the Church.

User avatar
mkmurray
Senior Member
Posts: 3241
Joined: Tue Jan 23, 2007 9:56 pm
Location: Utah
Contact:

Postby mkmurray » Tue Aug 18, 2009 10:57 am

One could also just standardize on a requirement at the stake level that necessitates that the flash drive have password protected access when exporting such files.
Many questions are already answered on the LDSTech wiki. Check it out!

RossEvans
Senior Member
Posts: 1346
Joined: Wed Jun 11, 2008 8:52 pm
Location: Austin TX
Contact:

Postby RossEvans » Tue Aug 18, 2009 11:07 am

mkmurray wrote:One could also just standardize on a requirement at the stake level that necessitates that the flash drive have password protected access when exporting such files.


I don't think that just articulating a policy requirement solves the problem. I am suggesting that there be a standardized technical solution (which could also be done at the stake level).

By that I mean: What is the actual software that would be used, and who would install it on the administrative boxes?

russellhltn
Community Administrator
Posts: 20781
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

Postby russellhltn » Tue Aug 18, 2009 11:24 am

boomerbubba wrote:I don't think that just articulating a policy requirement solves the problem.


How does it not solve the problem? The password protected flash drives I've seen install the needed software automatically.

Any solution the stake comes up with can be bypassed just as easily.
Have you searched the Wiki?
Try using a Google search by adding "site:tech.lds.org/wiki" to the search criteria.

User avatar
mkmurray
Senior Member
Posts: 3241
Joined: Tue Jan 23, 2007 9:56 pm
Location: Utah
Contact:

Postby mkmurray » Tue Aug 18, 2009 11:25 am

boomerbubba wrote:I don't think that just articulating a policy requirement solves the problem. I am suggesting that there be a standardized technical solution (which could also be done at the stake level).

By that I mean: What is the actual software that would be used, and who would install it on the administrative boxes?

Sometimes "process" solutions solve technical problems better than technical solutions solve technical solutions. I'm not exactly sure why you say it wouldn't solve the problem, as it would and it would be the simplest solution. Not the most enforceable or efficient, but the simplest.

Plus, your proposed solution seems it would create just as much (if not more) "process" in addition to the technical solution. All third-party uses of the export files would now not be able to consume the export files as is, as they currently do. Code would have to change, or users would have to learn the process of decrypting (and possibly encrypting as well) before running the export data into other tools.

With thumb drives, you stick it in the USB slot, let the driver install, and the OS takes care of the rest as far as password prompting and securing. That's it.
Many questions are already answered on the LDSTech wiki. Check it out!

RossEvans
Senior Member
Posts: 1346
Joined: Wed Jun 11, 2008 8:52 pm
Location: Austin TX
Contact:

Postby RossEvans » Tue Aug 18, 2009 11:45 am

mkmurray wrote:Plus, your proposed solution seems it would create just as much (if not more) "process" in addition to the technical solution. All third-party uses of the export files would now not be able to consume the export files as is, as they currently do. Code would have to change, or users would have to learn the process of decrypting (and possibly encrypting as well) before running the export data into other tools.

With thumb drives, you stick it in the USB slot, let the driver install, and the OS takes care of the rest as far as password prompting and securing. That's it.


The problem with your idea, I think, is that it relies on each end-user to provide his own technical solution. And I think the end-users are the weakest link in this process. (I am envisioning some hapless clerk, perhaps not a techie himself, when a non-techie bishop tosses him a proprietary flash-drive product he just bought and asks him to populate it.)

Encrypted thumb drives are not all as plug-and-play as you suggest. (Maybe yours is.) I have had to research, download and test a solution that would run off a generic drive. Most flash drives have no password-protection at all.

The reason I suggested WinZip is that most Windows users are familiar with it and MLS runs on a Windows box. My biggest qualm about it is wondering whether Mac / Linux users have utilites that can decrypt the .zip files, too. Decompressing them is no big deal, but I wonder about decrypting them.

I don't worry so much about the processes consuming the data. I think most end-users are pretty familiar with extracting from .zip files somehow.

EDIT: Upon reflection, I think you make some good points. It may be better to give users the option of supplying their own USB-based solution. I have a SanDisk U3 at home that I will try out again. (It now has the U3 launcher and security disabled because I was using it for another purpose.) That well known brand may well be a better solution than my own generic methods.

These solutions are not mutually exclusive, however. It would still be handy to have WinZip or 7-Zip installed on the administrative computer for others to use on generic flash drives.

russellhltn
Community Administrator
Posts: 20781
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

Postby russellhltn » Tue Aug 18, 2009 1:25 pm

boomerbubba wrote:The reason I suggested WinZip is that most Windows users are familiar with it and MLS runs on a Windows box.


The problem with WinZIp is that it's not freeware, it's trialware. Unless the unit buys it, it shouldn't be installed as a permanent solution.
Have you searched the Wiki?

Try using a Google search by adding "site:tech.lds.org/wiki" to the search criteria.


Return to “MLS Support, Help, and Feedback”

Who is online

Users browsing this forum: No registered users and 1 guest