As an extension, this is also relevant for other applications of Profiles other than enforcement, where any form of sensitive document is attached; e.g., financial records, staff photos/profiles, etc.

This probably needs to be an user configurable option. For sites that are happy as-is, I can see slowing down everything as a big negative for them with no benefit if they don't care about attachment security.

Yes, I can see the time-delay this introduces, potentially undermining the strength of Profiles (that it is quick & easy to use).

Two points if I may;

1. No misleading: The passwords and user-account-access features built into SMART give an impression that it is secure, so if encryption isn't a default setting, I suggest SMART should be explicit about this. Perhaps the upload attachment box should include a warning "Be aware that files attached are not currently being encrypted [and will be accessible to anyone with the conservation area file]"

2. Two types of attachment - can we treat them differently?

Attachments to make Profiles effective: e.g., having intelligence-specific layers on the basemap, and thumbnail photos of suspects, are two example of attachments which contribute significantly to the appeal of Profiles

Attachments for record-keeping: On the other hand, just appending a report of an incident, isn't essential (although is still very desirable) and could be managed through a secure referencing system outside of SMART.

Following on from your idea about a user configurable option, is it possible to have different storage areas for attachments so that users can specify which attachments should be encrypted?

To be clear the database data is not encrypted either. Anyone can access this data and with the information found on the Assembla site.

The only data encrypted in SMART was the original intelligence informant data.

How secure does this need to be?

Is the idea to simply make it so the files are not viewable from the windows file explorer, but if somebody knows how to access the database they can get a key from the database and de-crypt the files?
OR
Does does it need to be secure so that no-one without a "strong" password can access the files? In this case how do we deal with the management of the password - if a user forgets their password we are going to be unable to decrypt these files and all that data will essentially be lost.

Thanks for these questions, it's helpful to understand the levels of encryption.

@egouge, can I ask, when you say "anyone can access this data", do you mean someone with access to the conservation area folder could use Windows Explorer to access any data in SMART Profiles, in say, an intelligence report?

The intention is to ensure there is no 'open back door' to data - anything really, in SMART Profiles. Accessing any data within Profiles should be through the user login screen only.

@egouge, to your second question, this is a good question, I would probably suggest the second option where recovery of data is impossible without a correct password - and we build into the user protocols that there should be user accounts held by a super-user or senior analyst to reset passwords if a user forgets theirs.

Clearly there is a big risk if this is not done properly and data is lost. I assume there wouldn't be a chance of SMART throwing an error which would cause passwords to corrupt? That would be regrettable.

In my opinion, the slim risk of losing an intel database through several people all forgetting their passwords would be better than a situation where open-source methods exist to 'hack' into Profiles.

@rsapickles, do you have any thoughts on the issue of encryption?

Currently, the database data is stored in an un-encrypted derby database. You cannot view the data in a text editor, however with the instructions provided on Assembla (Connecting_to_Derby_via_Squirrel) and some familiarity with databases you can access and view all the data. At one point we did encrypt users passwords so they are not stored as plain text (since SMART 4.0? maybe), but all other data is plain text.

In regards to the second issue about SMART corrupting data. SMART should not be corrupting data, however it is possible for data to become corrupted from any number of factors outside of our control (failing hardware, unexpected shutdowns etc.) However, users should have in place a decent backup system so this is not a problem.

Yes I agree, backups will address the risk of corrupted files. In that case I suggest we go for full encryption of everything within Profiles?

For 6.0.0 the requirements are to encrypt files to the extent where windows explorer won't preview the files and it is not "easy" to preview/view the files, however and advanced computer user with the correct know-how and skills could still access the raw data (for example we may encrypt the files with a key stored in the database).

Encryption used is a AES algorithm using CBC block cipher with PKCS5Padding padding.
Key is not secure and person with the required knowledge can determine key and decrypt the files.

All attachments files are encrypted - this includes observation & waypoint attachments (for patrols, assets, missions etc), all attachments associated with records and entities in the profiles plugin, and original intelligence attachments.

Files that are NOT encrypted include: basemap files, report definition files, cybertracker files, configurable model icon files, icons specified for entity types etc

In order to view the files in SMART they must be decrypted. These decrypted files are temporarily stored in the filestore (decrypted) and can be viewed in the file explorer They are removed with the software is done with them or when the software is shutdown or the software is started. If the software is not shutdown in the normal fashion these decrypted files may remain in the filestore until it is started up again.

When attachments are exported they are decrypted. For example all patrol xml exports, independent incident xml exports, entity xml exports etc include the decrypted version of the attachment. Report HTML exports also include the decrypted version of the attachments.

On Connect (for reports) attachments are decrypted to a directory that is accessible for the web browser. They are only deleted when the SMART Connect clean up script is run (this is configurable and generally set to run once very 24 hours).

Connect is going to require an additional upgrade step:
1. backup the connect filestore/database
2. upgrade the database (use the script as normal)
3. restart tomcat (normal)
4. goto server/upgradeconnect page
This will automatically upgrade all the files in the filestore and let you know once it is done. You will not be able to log into SMART until this is complete. You cannot run it more than once. If it fails you will need to restore the backup and try again.

Needs to be tested with a large number of files in the filestore to ensure it doesn't time out.

When adding a new Field Sensor image the datastore created a temporyfiles directory that contained an unencrypted copy of the newly imported and saved image. After restarting the application the image was removed from this directory and encrypted. If this is not an issue then the ticket can be closed down.

@darrinc I don't see this behaviour. The imported file is not shown in the temporaryfiles folder for me.

Is there anything in the log file or some reason why SMART would not be able to delete files in this folder (have you locked it for some reason)?

The pictures appear in the temporyfiles directory after being viewed in SMART. The pictures will persist there until the application is shut down or restarted. Its not a big issue unless these pictures actually persist in the directory. I wanted it mentioned as it was the only case of an image not being encrypted.

The name of this ticket mentions Map Layers and I was able to view the contents of the Shapefile DBF's. Encryption for these files should be reviewed.
Image not found...

You have to open the image in SMART for this to appear in the filestore. I cannot delete the file after they open it or the tool they open it in may complain. So I don't think there is anything else we can do here. The assumption would be that if they have access to view the image in SMART that viewing it on the filestore should not be an issue.

Shapefiles are a different issue and will not be encrypted at this time. We are only encrypting "attachments" (files associated with waypoints). This prevents users from viewing them in the file explorer. Viewing shapefiles in the file explorer doesn't easily provide information. Plus performance would not be great if we had to encrypt these files each time we ready them unless we cached a decrypted copy of them.