New Zealand Government
TaaS SEEMail
What is TaaS SEEMail?
TaaS makes it easier for government agencies to easily and securely connect with each other and their customers. TaaS SEEMail is a New Zealand Government Solution that ensures secure emails between participating Public Sector organisations. It is an encryption and security service under control by the Department of Internal Affairs (DIA).
The new SEEMail service is being established under the TaaS framework due the old contract vehicle expiring.
Three Components of SEEMail
SEEMail Authentication, Key Generation and certificate directory capabilities (Managed by Cogito Group)
SEEMail Gateway (Managed internally in your agency or other third-party Gateway provider such as Liverton or SSS)
SMARTS Testing (Managing by Liverton)
Cogito Group’s Role
Cogito Group, in partnership with TaaS, has built and will operate the new TaaS based SEEMail PKI service. This includes a Certification Authority, Registration Authority and a Directory service.
Cogito Group currently provide the All of Government Authentication as a Service solution to a number of agencies for TaaS. We specialise in data protection, authentication and encryption solutions.
Cogito’s role is the certificate registration, generation and storage components only. The certificates will be used to ensure protection of data between agency gateways.
Unless you choose to change providers, there are no changes to who operates your SEEMail Gateway. You can continue to use your SEEMail Gateway Services provider for the Gateway itself. Cogito are only replacing the certificate component, that is, who you get the certificate off and where other agency certificates reside.
Cogito Group will not hold or see any of your SEEMail data. Cogito Group is not responsible for approval, release and blocking of emails. This remains the responsibility of the department or organisation that manages your gateway.
SEEMail Certificate Changes
There will be three changes involved:
1. You will need to access a new portal for a certificate and that will mean that the appropriate person(s) will need an account to access this system.
2. You will need to make a small update to the Certificate Authority (CA) certificate trust points. This update will involve adding one trust point and changing to where you point to. This will enable you to get trusted certificates for other agencies. If you have a SEEMail Gateway vendor managing this Gateway, you would likely be able to have them do this work for you.
3. You will need to point to a new directory (LDAP) for accessing certificates from other agencies. If you have a SEEMail Gateway vendor managing this Gateway, you would likely be able to have them do this work for you.
Certificate Signing Requests
A Certificate Signing Request (CSR) is what is required to allow for the creation of a digital certificate. Typically, as part of creating a CSR you also generate the key pair that will be used, being the private and public key. The private key (where possible) should be generated and remain on the device that it was generated for. The public key must be generated with the private key (as they are mathematically related) and is inserted into the CSR. It is not necessary to protect the public key and in fact it is important that this be known by parties wishing to use the keys for electronic transactions.
CSR Generation Approaches
Generation on the Gateway Service
Where CSRs can be generated on the device on which they are to be used this is the preferred method of creation of the CSR.
Generating CSRs on the device on which they are used allows the private key that is generated as part of the process to be stored within the available key store on the device and ensure it is never exposed externally to the device. Elimination of transferring the key from service to service significantly reduces the possibility of the private key being compromised.
Examples of this may be the generation of the private key within:
– A Hardware Security Module (HSM)
– A Smart Card
– The Windows Security Store
– A p12 or Pfx file
– Java Key Store equivalent
When generating a CSR and the private key is created within a key store, and depending on the capability of the key store, they can be marked as non-exportable or protected from export with PINs / Passphrases immediately ensuring that the risk of compromise is extremely limited.
Script/Batch File Process
CSRs could be generated through the use of a script or batch file process that generates the keys and CSR.
Generation of the CSRs by a batch or script file can be problematic where there is a requirement to run unsigned scripts or code on a user’s machine. This is considered poor security practice and the capability could or should be disabled by default and will most likely be disabled in organisations that have application whitelisting in place. Batches or scripts may also not use strong forms of key generation such as the use of accredited random number generators etc again making them a poor choice for CSR generation. Lastly this method often does not automatically clean up after itself (i.e. it can leave the private key exposed on the file system of the computer used to generate it. This can often be a client user machine (often a mobile device) that is exposed to greater risks than say a server.
CSR Generation within Jellyfish
While not the preferred method, Cogito’s Jellyfish product provides an alternative method to generating the CSR on the device or service for which it is intended, where this is not practical or desirable. Jellyfish has a simplified method of generating CSRs where the information required to generate a certificate can be entered into a form within the Jellyfish interface and the private key and CSR will be generated within the Client session.
Once the CSR is generated it is submitted for processing by the Certification Authority. When the certificate is signed and returned the interface creates a p12 file containing the certificate and the private key, which can then be saved by the user. If the user leaves the session before for the signed certificate is returned the private key is destroyed and the certificate must be re-requested.
The Jellyfish interface provides a more friendly non-technical, guided user experience to the generation of CSRs and also removes the private key from the service once the browser session is closed.
Whilst various options are available for the generation of CSRs only two options should be considered as viable:
– Generation on device as the primary means of creating a CSR
– Generation within the Jellyfish interface as a secondary means of creating a CSR
Generation on device provides the most secure option as it provides the most protection of the private key, it does have the drawback of requiring some technical knowledge of the application, service or device being used to generate the CSR.
Jellyfish provides a more user-friendly option for the generation of CSRs although does have the drawbacks of requiring the session to remain active and the private key being in memory during the request process. This is because Jellyfish request the key be held in the browser so that the application itself never sees the private key. It is also not as safe as generation on the device because the key will have existing on more than just the consuming device or service.
We would not recommend the use of batch files or scripts as often these will clash with application whitelisting in an enterprise and because they often expose the private key to more risk through the use of non-approved RNGs and by leaving the private key exposed on a file system.
Frequently Asked Questions
What is it and what is involved in training assistance?
SEEMail is secure encrypted email which secures email traffic between participating agencies within the New Zealand Public Sector.
Cogito can provide training and/or professional services to assist your organisation to consume the certificate services or provide advice on how certificates work including in the portal. We are putting this in the Subscription Agreement as an Optional Allowance and your agency will only be invoiced if you seek training or professional services from Cogito outside of the enablement of provisioning the service to your first two staff members (with those first two able to enable others). If you do not consume any professional services or training materials, you will not be charged.
If we choose to, what’s the timeframe for terminating the contract?
The Subscription Agreement is a month-to-month payment contract, therefore the timeframe of the termination of the contract is one month’s notice.
