SEEMail - FAQs
You are viewing an ARCHIVED page.
- How secure is SEEMail ?
- Is SEEMail approved for SENSITIVE information by GCSB ?
- How many bits is it ?
- Is SEEMail an Internet standard ?
- Who else uses it ?
- Why did you not specify a single product ?
- Why didn't SEEMail implement individual-to-individual secure e-mail ?
- Why doesn't SEEMail encrypt the "To:", "From:" and "Subject" fields?
How secure is SEEMail?
SEEMail ensures e-mail confidentiality, integrity and authentication over the Internet, between the sending and receiving gateways. Once the e-mail is decrypted at the receiving gateway, the receiving agency is responsible for the proper handling and use of the information, as dictated by the "Security In Government Departments" manual issued by the Department of Prime Minister and Cabinet and the New Zealand Security Information Technology (NZSIT) standards issued by GCSB.
SEEMail products are commercial "Off-The-Shelf" offerings, using industry standard encryption and authentication mechanisms. The products have not been customised. As with any software product, the S.E.E. agencies accept and manage the risk that they might not do the job as expected, and could have exploitable security vulnerabilities.
SEEMail in no way negates the need for a tightly configured firewall on any connection to the Internet.
Is SEEMail approved for SENSITIVE information by GCSB ?
Each SEEMail product must be seperately endorsed by the Government Communications Security Bureau, GCSB. MailMarshall Secure and Content Technologies SecretSweeper are both provisionally endorsed for the protection of RESTRICTED, SENSITIVE and IN CONFIDENCE information transferred across the New Zealand portion of the Internet.
GCSB can only provide provisional endorsement because of the level of uncertainty about the strength of the products. To achieve higher assurance the manufacturers would have to submit their products to an Australasian Information Security Evaluation Programme (AISEP) certified testing laboratory for formal Common Criteria evaluation to an Evaluation Assurance Level (EAL) of 3 or higher.
Tests done by the S.E.E. project team indicate the products behave as expected under normal conditions. The product documentation - in association with the SEEMail configuration guidelines - provides adequate guidance to install and manage the system effectively.
How many bits is it ?
SEEMail uses Triple DES 168-bit encryption, with SHA1 160-bit signing algorithm and RSA-1024/2048-bit key length digital certificates.
Is SEEMail an Internet standard ?
SEEMail uses several recognised standards, including S/MIME v3 and X.509 v3 digital certificates. The way in which it works is very similar to a newly proposed IETF standard, " Domain Security Services using S/MIME".
Who else uses it ?
No one (yet). There have been expressions of interest from several sector groups in New Zealand. Overseas, a pilot was run by the Massachusetts Health Data Consortium.
Why did you not specify a single product ?
Having multiple vendors increases competition. This has kept prices down.
Why didn't SEEMail implement individual-to-individual secure e-mail ?
Security - allowing encrypted content into an organisation can be a security risk if not tightly managed. Many agencies currently scan e-mail for malicious or inappropriate content at their e-mail gateway. E-mail encrypted for an individual can bypass these security checks, (unless the e-mail is also encrypted/cc'd to the content checking gateway).
Information Management - storing information in encrypted form means it is unavailable as a corporate resource. In the short-term this means that other authorised people are not necessarily able to access it. The business processes necessary to confidently archive and retrieve encrypted material are not widely developed, and may have long-term implications to the organisation.
Product immaturity - the installed base of email client software does not have mature S/MIME support.
Individual-to-individual secure e-mail is appropriate for high-end security, when between small numbers of people, with rigorous processes in place. If content filtering is enabled at the e-mail gateway, then depending upon the SEEMail product chosen, SEEMail can be cc'd the encrypted message for scanning.
These findings were consistent with the findings of the Massachusetts Health Data Consortium individual digital certificate trial.
Why doesn't SEEMail encrypt the "To:", "From:" and "Subject" fields?
SEEMail products are "Off-The-Shelf" commercial offerings. They have not been customised. Accordingly we have had to live with the vendors implementations of the S/MIME standard. SEEMail users are advised to consider the risk of traffic analysis (unknown people reading the "To:", "From:" and "Subject:" fields) while the e-mail is in transit.
We have preliminary requirements defined for mail-bagging to defeat traffic analysis. Until SEEMail agencies express interest, this concept will not be developed further.
Isn't SEEMail just S/MIME?
The SEEMail business requirements go into greater detail than the RFCs on which S/MIME is based. By specifying our requirements in such a manner, we reduce system management and interoperability issues. SEEMail version 2.0 has achieved:
- Greater automation of routine certificate management tasks, such as
retrieval of replacement certificates.
- Improved fail-safe certificate processing to cater for invalid
certificates, expired certificates, faulty implementations.
- Improved security, by re-certification at any time, of a
Participating Agency, via SMARTS (SEEMail Automated Reference Test
Server).
- Increased cost-effectiveness, by defining how an individual
Participating Agency can establish an encrypted link to their business
partner (e.g. bank, law firm, etc).
- Optionally, greater automation of routine encryption management tasks, by defining how gateways can adjust encryption capabilities based upon S/MIME capability attribute.
