concerns about Trustcor
49,233 views
Skip to first unread message
Prof. Reardon
Nov 8, 2022, 10:52:25 AM11/8/22
to dev-secur...@mozilla.org
Hello all:
I'm Joel Reardon, a professor at the University of Calgary, who researches
privacy in the mobile space. Earlier this year, collaborators and I uncovered
and disclosed a spyware SDK embedded in apps that were invasively tracking users
[1]. The SDK was banned from the Play Store and apps that included this SDK were
told to remove it or they would be removed from the Play Store.
The SDK was from a Panamanian company [2] called Measurement Systems [3]. Their
website's WHOIS information listed Vostrom Holdings [4] as their owner when
I had started the investigation; it is now anonymized for privacy, but historical
information is available [5].
Along with investigative journalists at the Wall Street Journal, we discovered
that Vostrom Holdings is doing business as Packet Forensics [6], a
company that sells lawful-intercept products [7]. The Measurement Systems
company was also registered in Virginia [8] by "Raymond Alan Saulino", which was
then made inactive when Google took action against the SDK [9]. "Raymond A
Saulino" is also an officer for Packet Forensics International LLC [10], and
despite the middle name not being an exact match, they both list the same
residential address [11, 12].
So now let's get to why I'm talking about this here on this forum. After we found
that the SDK domainss were registered by Vostrom, we looked to see what else was also
registered [13]. One of the domains stood out: trustcor.co, which redirected at
the time to the TrustCor CA's website. The NS records continue to point to
nsX.msgsafe.io [14], the same as trustcor.com itself [15]. Msgsafe is a TrustCor
encrypted email product [16].
Like Measurement Systems, Trustcor is also registered in Panama [17]. They were
registered a month apart and they share an identical set of corporate officers
(cf. [1]). It is my understanding that these officers only are involved in three
companies, so it does not appear that they register, e.g., many companies in
Panama. One of these officers is Frigate Bay Holding LLC [18]. Shortly after
the WSJ article was printed, a "Raymond Saulino" filed paperwork for Frigate Bay
Holdings LLC listed as its manager [19]. Raymond Saulino has also spoken to press
publicly on behalf of Packet Forensics in the context of a Wired article about
subverting SSL [20].
Trustcor also talks about their "geo-jurisdiction advantage" on an entire page
[21] where they state that "TrustCor is a Panamanian registered company, with
technical operations based in Curaçao---one of the most secure, privacy oriented
jurisdictions in the world." Despite that, they have job openings for PKI
Engineer and Systems Engineering in Phoenix, AZ [22, 23], the latter stating that
the applicant "MUST be located near the Phoenix, AZ area - job is remote with
occasional trips to data center facilities". Their own audit reports state that
they are Canadian, with their data centres in Phoenix, AZ [24]. I am not
particularly troubled by where they have their technical operations, but I think
that it is strange to omit that the data centres are in Arizona on the lengthy
descriptions of the "geo-jurisdiction advantage". Certificate authorities are
about trust.
I have also tested the Msgsafe encrypted email product in the browser, while
saving the resulting traffic using Firefox and Chrome's "save to HAR" file option.
I am not convinced there is E2E encryption or that Msgsafe cannot read users'
emails. I see that email contents and attachments are sent plaintext
(over TLS) to api.msgsafe.io, even when sending to other Msgsafe users or when
using PGP or SMIME to send to non-Msgsafe users. The SMIME cert is sent inbound
from the server, and there is no outbound traffic that embodies the public key
to be signed. The password is sent plaintext to the server (over TLS) and thus
any key derived from that password would also be known by the server. Hanlon's
razor tells me I should not attribute these errors to malice; it could just be a
developmental failure [25]. Nevertheless, I think it is reasonable expectation
that a root certificate authority can get the crypto right, and so I'm concern
regardless of the reason why.
Another strange thing is that whois information lists Wylie Swanson as the
registrant for a number of domains that closely mimic other encrypted email
products [26]. This includes hushemail.net, protonmails.com, and tutanoto.com,
which shadow competing services, and which redirect users who visit them to
msgsafe.io. Wylie Swanson is the co-founder of Trustcor [27]. In my opinion,
it looks like typo squatting and I would not expect that a root certificate
authority to be engaged in this kind of behaviour.
To be clear, I have found no evidence of Trustcor issuing a bad certificate or
otherwise abusing the authority they have in code signing, SMIME, and domain
validation. I have only checked the public certificate transparency logs because
I am unaware of comparable public auditing for code signing and SMIME. Perhaps
Vostrom registered a similar-sounding domain for Trustcor and redirected it
as an act of service. Perhaps the identical ownership of Trustcor and Measurement
Systems is a coincidence. Perhaps the Raymond Saulino of Frigate Bay holdings is
a different Raymond Saulino than the one representing Packet Forensics.
I'm not familiar with the full policy side of how CA membership works, so I
don't know if there is an expectation of candor regarding a CA's foreign
ownership or connection to lawful intercept companies. Perhaps what I'm
reporting is already known and not a concern, or perhaps there is a totally
reasonable explanation for all these coincidences. Nevertheless, I feel I should
disclose my findings just in case it ends up being useful, because I think that
it is reasonable for a root certificate authority to assuage my concerns.
A final coincidence: one of Msgsafe's email domains is decoymail.com, which
Msgsafe users can request and which redirects to msgsafe.io [28]. In 2014 it was
registered to VOSTROM Holdings, Inc., while in 2015 it was registered to TRUSTCOR
SYSTEMS S. DE R.L. [29]. DecoyMail was a company created by Rodney Joffe [30],
who is the person who also filed the original registration of Packet Forensics
[31] and was still an authorized agent for Packet Forensics in a 2019 filing
[32] and a Manager for Packet Forensics in a 2021 filing [33]. The email
rjo...@centergate.com is linked to the domains rodneyjoffe.com,
packetforensics.com, and decoymail.net [34]. Decoymail.net currently redirects
to msgsafe.io.
Just to restate: I have no evidence that Trustcor has done anything wrong, and I
have no evidence that Trustcor has been anything other than a diligent competent
certificate authority. Were Trustcor simply an email service that misrepresented
their claims of E2E encryption and had some connections to lawful intercept
defense contractors, I would not raise a concern in this venue. But because it is
a root certificate authority on billions of devices---including mine---I feel it
is reasonable to have an explanation.
[1] https://archive.ph/AuNOy (archive of WSJ article)
[2] https://opencorporates.com/companies/pa/2337L
[3] https://measurementsys.com/
[4] https://vostrom.com/about.opp
[5] https://www.whoxy.com/measurementsys.com
[6] https://cis.scc.virginia.gov/CommonHelper/DocumentStorageLocalFileget?DocumentId=1542553&sourceType=1
[7] https://www.packetforensics.com/products.safe
[8] https://cis.scc.virginia.gov/CommonHelper/DocumentStorageLocalFileget?DocumentId=3476851&sourceType=1
[9] https://cis.scc.virginia.gov/CommonHelper/DocumentStorageLocalFileget?DocumentId=12188858&sourceType=1
[10] https://opencorporates.com/companies/us_nv/E0518742015-4
[11] https://opencorporates.com/officers/429641126
[12] https://opencorporates.com/officers/168691865
[13] https://www.whoxy.com/company/20189182
[14] https://www.whoxy.com/trustcor.co
[15] https://www.whoxy.com/trustcor.com
[16] https://trustcor.com/news/12012016.php
[17] https://opencorporates.com/companies/pa/2326L
[18] https://opencorporates.com/companies/us_wy/2020-000946985
[19] https://wyobiz.wyo.gov/Business/FilingDetails.aspx?eFNum=230084239221021253238165142128171020141144245186
(click on history, then address update pdf)
[20] https://www.wired.com/2010/03/packet-forensics/
[21] https://trustcor.com/curacao
[22] https://careers.jobscore.com/careers/trustcor/jobs/pki-security-engineer-cGlJUDydTp67nWF6LOxNC0?ref=rss&sid=68
[23] https://careers.jobscore.com/careers/trustcor/jobs/systems-engineer-aNkuyi0pKr6R6NaKlhlxBf?ref=rss&sid=68
[24] https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=c4f0e7c6-b310-4f5c-9907-8ecfad68366e
[25] https://en.wikipedia.org/wiki/Hanlon%27s_razor
[26] https://www.whoxy.com/email/28298508
[27] https://trustcor.com/leadership
[28] https://decoymail.com
[29] https://securitytrails.com/domain/decoymail.com/history/a (need to create account)
[30] https://ecorp.azcc.gov/CommonHelper/GetFilingDocuments?barcode=00396622
[31] https://ecorp.azcc.gov/CommonHelper/GetFilingDocuments?barcode=02780271
[32] https://ecorp.azcc.gov/CommonHelper/GetFilingDocuments?barcode=19121111449561
[33] https://bizfileonline.sos.ca.gov/api/report/GetImageByNum/190229140180179177132144027172122051178173016008
[34] https://www.whoxy.com/email/23160817
I'm Joel Reardon, a professor at the University of Calgary, who researches
privacy in the mobile space. Earlier this year, collaborators and I uncovered
and disclosed a spyware SDK embedded in apps that were invasively tracking users
[1]. The SDK was banned from the Play Store and apps that included this SDK were
told to remove it or they would be removed from the Play Store.
The SDK was from a Panamanian company [2] called Measurement Systems [3]. Their
website's WHOIS information listed Vostrom Holdings [4] as their owner when
I had started the investigation; it is now anonymized for privacy, but historical
information is available [5].
Along with investigative journalists at the Wall Street Journal, we discovered
that Vostrom Holdings is doing business as Packet Forensics [6], a
company that sells lawful-intercept products [7]. The Measurement Systems
company was also registered in Virginia [8] by "Raymond Alan Saulino", which was
then made inactive when Google took action against the SDK [9]. "Raymond A
Saulino" is also an officer for Packet Forensics International LLC [10], and
despite the middle name not being an exact match, they both list the same
residential address [11, 12].
So now let's get to why I'm talking about this here on this forum. After we found
that the SDK domainss were registered by Vostrom, we looked to see what else was also
registered [13]. One of the domains stood out: trustcor.co, which redirected at
the time to the TrustCor CA's website. The NS records continue to point to
nsX.msgsafe.io [14], the same as trustcor.com itself [15]. Msgsafe is a TrustCor
encrypted email product [16].
Like Measurement Systems, Trustcor is also registered in Panama [17]. They were
registered a month apart and they share an identical set of corporate officers
(cf. [1]). It is my understanding that these officers only are involved in three
companies, so it does not appear that they register, e.g., many companies in
Panama. One of these officers is Frigate Bay Holding LLC [18]. Shortly after
the WSJ article was printed, a "Raymond Saulino" filed paperwork for Frigate Bay
Holdings LLC listed as its manager [19]. Raymond Saulino has also spoken to press
publicly on behalf of Packet Forensics in the context of a Wired article about
subverting SSL [20].
Trustcor also talks about their "geo-jurisdiction advantage" on an entire page
[21] where they state that "TrustCor is a Panamanian registered company, with
technical operations based in Curaçao---one of the most secure, privacy oriented
jurisdictions in the world." Despite that, they have job openings for PKI
Engineer and Systems Engineering in Phoenix, AZ [22, 23], the latter stating that
the applicant "MUST be located near the Phoenix, AZ area - job is remote with
occasional trips to data center facilities". Their own audit reports state that
they are Canadian, with their data centres in Phoenix, AZ [24]. I am not
particularly troubled by where they have their technical operations, but I think
that it is strange to omit that the data centres are in Arizona on the lengthy
descriptions of the "geo-jurisdiction advantage". Certificate authorities are
about trust.
I have also tested the Msgsafe encrypted email product in the browser, while
saving the resulting traffic using Firefox and Chrome's "save to HAR" file option.
I am not convinced there is E2E encryption or that Msgsafe cannot read users'
emails. I see that email contents and attachments are sent plaintext
(over TLS) to api.msgsafe.io, even when sending to other Msgsafe users or when
using PGP or SMIME to send to non-Msgsafe users. The SMIME cert is sent inbound
from the server, and there is no outbound traffic that embodies the public key
to be signed. The password is sent plaintext to the server (over TLS) and thus
any key derived from that password would also be known by the server. Hanlon's
razor tells me I should not attribute these errors to malice; it could just be a
developmental failure [25]. Nevertheless, I think it is reasonable expectation
that a root certificate authority can get the crypto right, and so I'm concern
regardless of the reason why.
Another strange thing is that whois information lists Wylie Swanson as the
registrant for a number of domains that closely mimic other encrypted email
products [26]. This includes hushemail.net, protonmails.com, and tutanoto.com,
which shadow competing services, and which redirect users who visit them to
msgsafe.io. Wylie Swanson is the co-founder of Trustcor [27]. In my opinion,
it looks like typo squatting and I would not expect that a root certificate
authority to be engaged in this kind of behaviour.
To be clear, I have found no evidence of Trustcor issuing a bad certificate or
otherwise abusing the authority they have in code signing, SMIME, and domain
validation. I have only checked the public certificate transparency logs because
I am unaware of comparable public auditing for code signing and SMIME. Perhaps
Vostrom registered a similar-sounding domain for Trustcor and redirected it
as an act of service. Perhaps the identical ownership of Trustcor and Measurement
Systems is a coincidence. Perhaps the Raymond Saulino of Frigate Bay holdings is
a different Raymond Saulino than the one representing Packet Forensics.
I'm not familiar with the full policy side of how CA membership works, so I
don't know if there is an expectation of candor regarding a CA's foreign
ownership or connection to lawful intercept companies. Perhaps what I'm
reporting is already known and not a concern, or perhaps there is a totally
reasonable explanation for all these coincidences. Nevertheless, I feel I should
disclose my findings just in case it ends up being useful, because I think that
it is reasonable for a root certificate authority to assuage my concerns.
A final coincidence: one of Msgsafe's email domains is decoymail.com, which
Msgsafe users can request and which redirects to msgsafe.io [28]. In 2014 it was
registered to VOSTROM Holdings, Inc., while in 2015 it was registered to TRUSTCOR
SYSTEMS S. DE R.L. [29]. DecoyMail was a company created by Rodney Joffe [30],
who is the person who also filed the original registration of Packet Forensics
[31] and was still an authorized agent for Packet Forensics in a 2019 filing
[32] and a Manager for Packet Forensics in a 2021 filing [33]. The email
rjo...@centergate.com is linked to the domains rodneyjoffe.com,
packetforensics.com, and decoymail.net [34]. Decoymail.net currently redirects
to msgsafe.io.
Just to restate: I have no evidence that Trustcor has done anything wrong, and I
have no evidence that Trustcor has been anything other than a diligent competent
certificate authority. Were Trustcor simply an email service that misrepresented
their claims of E2E encryption and had some connections to lawful intercept
defense contractors, I would not raise a concern in this venue. But because it is
a root certificate authority on billions of devices---including mine---I feel it
is reasonable to have an explanation.
[1] https://archive.ph/AuNOy (archive of WSJ article)
[2] https://opencorporates.com/companies/pa/2337L
[3] https://measurementsys.com/
[4] https://vostrom.com/about.opp
[5] https://www.whoxy.com/measurementsys.com
[6] https://cis.scc.virginia.gov/CommonHelper/DocumentStorageLocalFileget?DocumentId=1542553&sourceType=1
[7] https://www.packetforensics.com/products.safe
[8] https://cis.scc.virginia.gov/CommonHelper/DocumentStorageLocalFileget?DocumentId=3476851&sourceType=1
[9] https://cis.scc.virginia.gov/CommonHelper/DocumentStorageLocalFileget?DocumentId=12188858&sourceType=1
[10] https://opencorporates.com/companies/us_nv/E0518742015-4
[11] https://opencorporates.com/officers/429641126
[12] https://opencorporates.com/officers/168691865
[13] https://www.whoxy.com/company/20189182
[14] https://www.whoxy.com/trustcor.co
[15] https://www.whoxy.com/trustcor.com
[16] https://trustcor.com/news/12012016.php
[17] https://opencorporates.com/companies/pa/2326L
[18] https://opencorporates.com/companies/us_wy/2020-000946985
[19] https://wyobiz.wyo.gov/Business/FilingDetails.aspx?eFNum=230084239221021253238165142128171020141144245186
(click on history, then address update pdf)
[20] https://www.wired.com/2010/03/packet-forensics/
[21] https://trustcor.com/curacao
[22] https://careers.jobscore.com/careers/trustcor/jobs/pki-security-engineer-cGlJUDydTp67nWF6LOxNC0?ref=rss&sid=68
[23] https://careers.jobscore.com/careers/trustcor/jobs/systems-engineer-aNkuyi0pKr6R6NaKlhlxBf?ref=rss&sid=68
[24] https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=c4f0e7c6-b310-4f5c-9907-8ecfad68366e
[25] https://en.wikipedia.org/wiki/Hanlon%27s_razor
[26] https://www.whoxy.com/email/28298508
[27] https://trustcor.com/leadership
[28] https://decoymail.com
[29] https://securitytrails.com/domain/decoymail.com/history/a (need to create account)
[30] https://ecorp.azcc.gov/CommonHelper/GetFilingDocuments?barcode=00396622
[31] https://ecorp.azcc.gov/CommonHelper/GetFilingDocuments?barcode=02780271
[32] https://ecorp.azcc.gov/CommonHelper/GetFilingDocuments?barcode=19121111449561
[33] https://bizfileonline.sos.ca.gov/api/report/GetImageByNum/190229140180179177132144027172122051178173016008
[34] https://www.whoxy.com/email/23160817
Serge Egelman
Nov 8, 2022, 11:38:07 AM11/8/22
to dev-secur...@mozilla.org, joel.r...@ucalgary.ca
I want to follow this up with some additional details that I've found:
We initially came across this CA after discovering the malware SDK that Joel described. We went through some of our app analysis data to find all the apps impacted and reported those to Google. In every case, save one, that SDK was heavily obfuscated (going so far as to encrypt strings, which were then decrypted dynamically at runtime). We found a pre-release beta of the MsgSafe app that contained the only unobfuscated version of the SDK that we had seen in the wild. For example, here's a screenshot made after decompiling that app using apktool:
You can see full debug symbols, which don't exist in any other version of the app that we've found.
According to their Twitter feed, they released a beta of their Android app in late 2017:
While that app is no longer in the Play Store, there are third-party app archives that have made it publicly available. For example:
Like most Android apps, it's signed, so someone else can probably independently verify its provenance.
So the question is, why did MsgSafe appear to bundle an unobfuscated version of this SDK in their app? How was it obtained, if as Rachel says, they have nothing to do with the company that is spreading it? According to her email, they don't have a public app; someone should probably tell that to their social media person...
serge
Kathleen Wilson
Nov 8, 2022, 1:03:35 PM11/8/22
to dev-secur...@mozilla.org, ege...@cs.berkeley.edu, joel.r...@ucalgary.ca
Thank you, Joel and Serge, for bringing this to the attention of Mozilla and the wider community.
We understand from your post that:
Measurement Systems distributed an SDK containing spyware to Android users (also reported by the Wall Street Journal in April 2022).
There is substantial evidence that Measurement Systems and TrustCor are closely related:
Both had their domains registered by Vostrom Holdings. (as illustrated in this post by AppCensus on the basis of whois lookups)
They have identical corporate officers: Measurement Systems, Trustcor Systems
TrustCor operates the mail encryption product MsgSafe and a beta version of MsgSafe contained the only known unobfuscated version of the spyware SDK. (Beta APK, inspected by Joel and signed by Google)
The MsgSafe product relies in part on SMIME certificates issued by TrustCor (MsgSafe Website)
You found no evidence of the CA mis-issuing certificates.
We find this information to be very concerning and in line with our Root Store Policy, (Section 7.3 Removals), we intend to carry out the following actions:
1) Request that a representative of the TrustCor CA, who we have also contacted over email, respond here in this discussion thread with the following information as soon as possible, and no later than November 22, 2022.
Response to the concerns raised in Joel’s post, including
How was an unobfuscated version of the Measurement Systems SDK incorporated into MsgSafe?
Explanation of the ownership, governance, and relationship between Trustor, Measurement Systems and Packet Forensics International, especially focusing on how the documented actions by other Vostrom Holdings organizations such as Measurement Systems impact TrustCor and its operations.
To what extent does TrustCor today maintain a business relationship or share ownership/ corporate officers with Measurement Systems or Packet Forensics?
If Trustcore today does not maintain a business relationship or share ownership/corporate officers, has it done so in the past? If so, when? When was the relationship disolved?
What in general explains the shared corporate officers across the companies?
Do you have separate corporate registration documentation demonstrating that the TrustCor CA is a different organization than the Trustcor entity that shares corporate officers with Measurements Systems. If so, please provide it.
State the number of SMIME certificates whose private keys were stored in versions of the MsgSafe app which included the identified malware. State TrustCor CA’s plan for those certificates; e.g. timeline for revoking them.
Self-assessment of risk versus benefit of the TrustCor CA’s root certificates being included in Mozilla’s root store with the websites (TLS) and email (S/MIME) trust bits enabled. Please see https://wiki.mozilla.org/CA/Quantifying_Value for the information to be provided.
Statement of Auditor’s Qualifications, as explained here: https://wiki.mozilla.org/CA/Audit_Statements#Providing_Auditor_Qualifications
2) Depending on our own further investigations, relevant external developments, and on TrustCor’s response, we intend to enact the following options.
If our concerns have not been resolved by November 22 and further investigation and discussion is still needed, then set “Distrust for TLS After Date” and “Distrust for S/MIME After Date” to November 29, 2022, for the 3 TrustCor root certificates (TrustCor RootCert CA-1, TrustCor ECA-1, TrustCor RootCert CA-2) that are currently included in Mozilla’s root store. This means that for certificates chaining up to those root certificates, Mozilla will not trust end-entity certificates that have a Valid-From date later than the distrust-after date. Certificates with a Valid-From date earlier than the distrust-after date will continue to be trusted until a decision is made about TrustCor’s risk to the CA ecosystem, including via their response to this message
If the TrustCor CA representatives are able to provide satisfactory evidence demonstrating that the accusations are without merit and no evidence emerges that the CA has mis-used certificates, then remove the distrust-after values (if they have been set), and allow TrustCor CA to continue to be a fully-operational CA in Mozilla’s root store.
If the concerns are founded, but there is no reason to believe that the CA has mis-used certificates, keep the distrust-after values set until all of the existing end-entity root certificates have expired, then remove the root certificates from Mozilla’s root store.
If there is reason to believe that the CA has mis-used certificates or the CA backdates certificates to bypass the distrust-after settings, then remove the root certificates from Mozilla’s root store in an expedited timeline, without waiting for the end-entity certificates to expire.
Mozilla retains the right to take any necessary steps we deem appropriate to protect the security and privacy of our users, including disabling (partially or fully) or removing a certificate and certificate authority from our Root Store program.
Whilst we appreciate TrustCor’s rapid response to the Washington Post article, these concerns need to be thoroughly addressed in order to maintain trust in the CA ecosystem.
If anyone has additional information about the TrustCor CA and these concerns, your input to this thread will be greatly appreciated. You can also write to Mozilla privately at certif...@mozilla.org.
Thanks,
Kathleen
Rachel McPherson
Nov 8, 2022, 1:58:03 PM11/8/22
to dev-secur...@mozilla.org, Serge Egelman, joel.r...@ucalgary.ca
Hi Joel and Serge,
Interesting that this is the first time you or anyone else in your research group has reached out to us, except if you count the Washington Post journalist who claims in his article that we did not respond, which is one of the many false claims made in the article since we responded very quickly to his contact. And before I begin, you should probably clarify if your views are representing The University of Calgary’s views, The University of California at Berkeley’s views, or your commercial endeavor AppCensus’s views, or your views representing any customer, agency, etc…? If in fact these views are completely independent and personal, that is also helpful to note.
For any of the technical details about MsgSafe.io’s email software and service, that belongs in a different forum as it is not related to CA operations or CA public policy based on your description. I know you guys promote some kind of app security solution commercially, but I did note in my earlier response that our company and MsgSafe has never shipped an app that was not in BETA only and that the 5-year-old app beta was abandoned years ago and replaced with a mobile-first web experience that we think is really quite awesome on the phone browser itself without having to install any app software which is (as you guys well know) dangerous when it comes to navigating the 3rd party software that helps make apps easier to use or helps monetize them or whatever, but may also contain other stuff bad guys use for their own purposes. We abandoned mobile development years ago (as you can clearly tell) and instead of replacing it we just suggest users make use of their built-in browsers only to use the service which as you can see for yourself works amazingly well now based on React Native’s mobile capabilities. This is by far the safest way to use the email app from what I’ve been told by the team, but again in that other forum please share your suggestions because of course we want to make it even better. I encourage you to follow those up with the MsgSafe.io directly via their customer support channels and I know for a fact they will be thrilled if you can provide any positive suggestions for improving that product suite, and thank you in advance for that. I know they get a lot of suggestions, but everything helps when it comes to making products better and more secure, I think that’s one thing we all agree on. My suggestion is you don’t start the conversation with them talking about an abandoned app beta from many years ago (except maybe to say remove it), and instead focus on improving their production web application for mobile.
Specific to your commentary on the certificate authority and policy pertinent to this forum, I appreciate that you recognize and stated multiple times throughout your post that you have found no evidence of TrustCor mis-issuing certificates or otherwise abusing our authority or violating established CA policies or root policies. We obviously agree. I’m going to comment on a few of your other points for the benefit of this forum, and then I suggest we take things off-line (sideline at least) and either meet in person or have phone calls or professionally approach our discourse some other way, without you guys using the media, your twitter forces or slinging more false claims, which isn’t good for anyone including the public that we both hope to serve.
I’m not an attorney, but when a company registers itself as a corporate entity and lists its officers and addresses and mailing addresses and uses attorneys to do those things, often times the company initially gets registered to the attorney or there and then that information gets immediately obsoleted through amendments pointing to the real officers. I can tell you we don’t have any crossover between our officers and the officers of the other companies you mention, for certain. As for the ownership or beneficial shareholders of the company, the names you list are close, but wrong. We have had the same beneficial owners for 7 years, and while their names are "similar to" the names you mentioned, they are not identical and we certainly never had any ownership from companies registered in the USA. As for the cross-over between officers, I am as perturbed as you because what that website is showing (open corporates) and probably what the gov attorneys have in our records is absolutely not what exists in my files, so obviously it is my duty to reconcile this with the ownership and get it corrected and most importantly explained. Without having researched any of that, I will again refer to those other random USA companies that are not us, and that were created in other jurisdictions 7 years after we were incorporated, that sound similar to our ownership, and their potential for foul play against us in this way along with the insurance information attempt I mentioned before. It looks like the real companies were there before, but were modified and the attorneys and individuals were added to the record, whereas our records show slightly different names and without that individual. Again, I will reconcile and explain after I’ve done more research and compared these things on the complete timeline of events.
Also, we are not in USA territory based on ownership, though as you pointed out we do host some equipment in the USA. I don’t think it’s common for companies to disclose where any of their critical hosting infrastructure is located, but yes we have infrastructure in the USA and in the Caribbean, and our key locations are properly documented in our CA audits and insurance filings.
When I read your comments about the company names and the domain name, it seems like we already explained this in our initial reply to the extent my attorney is comfortable with me explaining publicly because we are concerned about follow-on civil lawsuits. Plainly stated, it looks like 7 or so years after we were founded, someone went and created companies with similar names (but instead of creating them where they belong and are already registered, they created them inside the USA). I don’t know for a fact why anyone would do this, we certainly did not do it. Our attorneys believe someone could have done this (and it agrees with our event timeline we’re creating as we investigate) for physical actions taken and may have used this with insurance companies to obtain additional nonpublic information about our company and our insurance infrastructure which is large and complicated just like every CA’s insurance has to be. When you pair that with someone also having a lookalike domain name, obviously that could be used for bad purposes (phishing, etc) against our clients or against us or against our vendors I guess, … that doesn’t look like a good combination. It looks quite nasty, actually. When we realized the domain name was out there, we took legal action and we had asserted international trademark claims and we were able to force the domain be sold to us and we have it and use it today. Who would register those companies or domain or do these things to us and why? That’s beyond me, but none of it sounds like good behavior to me or to our attorneys. If you guys have any actual evidence of better ideas as to how these could have been used, I’d like to share that with our attorneys.
I think I’ve hit on all the big points I can talk about publicly, obviously I can’t comment on prior (whether deceased or not) employees, etc.
Oh and on our own domain ownership or prior employee domain ownership, frankly that again has to do with that MsgSafe email product and not CA operations, but our customers and the company and prior and current employees etc all register domains through it by the hundreds or thousand(s) there are at some level of provisioning or not, and we really can’t be responsible for what they all register. Certainly if any violate any guidelines we try to handle that on an individual case basis, but hopefully abuse is kept to a minimum and we have a lot of protections built-in like checking against Alexa top sites and other things CAs do operationally as part of the business. Some but not all of these protections are extended to the MsgSafe email product but that can be blurry because people register some really weird domains quite naturally and without any malice that contain weird words or substrings or whatever…
As I said happy we are to take this offline with our CA operational partners and fellow root program stakeholders and administrators, etc.
Thank you everyone,
Rachel
Please note: this message is not in direct reply to Kathleen’s message that just came in, we have not yet had time to absorb her post and will reply to Kathleen’s message on all mentioned points within the timeframe allotted. However, we did not feel the need to delay our response to Joel and Serge.
On Nov 8, 2022, at 11:38 AM, Serge Egelman <ege...@cs.berkeley.edu> wrote:
I want to follow this up with some additional details that I've found:We initially came across this CA after discovering the malware SDK that Joel described. We went through some of our app analysis data to find all the apps impacted and reported those to Google. In every case, save one, that SDK was heavily obfuscated (going so far as to encrypt strings, which were then decrypted dynamically at runtime). We found a pre-release beta of the MsgSafe app that contained the only unobfuscated version of the SDK that we had seen in the wild. For example, here's a screenshot made after decompiling that app using apktool:
<Screenshot 2022-11-08 at 8.26.43 AM.png>You can see full debug symbols, which don't exist in any other version of the app that we've found.According to their Twitter feed, they released a beta of their Android app in late 2017:
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/f5ab3236-2a16-42e6-b33d-6e142c1b49cen%40mozilla.org.
<Screenshot 2022-11-08 at 8.18.04 AM.png><Screenshot 2022-11-08 at 8.26.43 AM.png>
Ryan Dickson
Nov 9, 2022, 8:10:41 AM11/9/22
to Rachel McPherson, dev-secur...@mozilla.org, Serge Egelman, joel.r...@ucalgary.ca
All,
The Chrome Root Program is aware of the allegations against TrustCor by AppCensus and described in this Washington Post article. Chrome maintains a variety of mechanisms to protect its users, and is prepared to use them as necessary.
To be clear, behavior that attempts to degrade or subvert security and privacy on the web is incompatible with organizations whose CA certificates are included in the Chrome Root Store.
The research by AppCensus, along with our own, has identified what could be described as “coincidences” that, when compiled, could call into question the honesty and security of a publicly-trusted root CA owner or operator. As described by Kathleen Wilson, we believe it is TrustCor’s responsibility to assuage community concern by publicly addressing the questions outlined in her message.
Additionally, we noted the following coincidences and request further clarification from TrustCor:
Coincidence #1 Audit Irregularities
TrustCor uses Princeton Audit Group (PAG) as its auditor.
According to CCADB records, PAG does not audit any other publicly-trusted CAs.
TrustCor’s most recent audit statements ([Standard] and [BR - TLS]) describe CA operations in Toronto, Ontario, Canada.
PAG is listed as a licensed practitioner only in the USA.
TrustCor’s CPS indicates the data centers are located in Phoenix.
Though the management assertion references Phoenix, PAG’s attestation does not.
Beyond [1], [2], and [3], we found little public information specific to audits performed by PAG.
Coincidence #2 WIPO Complaint
This page summarizes a 2018 complaint filed with the WIPO Arbitration and Mediation Center against Trustcor Systems S. De R.L. by Compagnie Générale des Etablissements Michelin, owner of BFGOODRICH.
The complaint cites concerns related to TrustCor registering bfgoodrichpromotions.net, and the risk of a related phishing scheme resulting from the registration and corresponding email servers configured on the disputed domain name.
Ultimately, the Panel found TrustCor’s passive holding of the disputed domain name indicated “bad faith”. Furthermore, the Panel also found that TrustCor’s failure to respond to the Complainant’s cease-and-desist letters was an additional circumstance evidencing the TrustCor’s “bad faith”.
This type of behavior is consistent with that described by Joel Reardon here (see discussion beginning with “Another strange thing is that whois information lists Wylie Swanson as the registrant for a number of domains that closely mimic other encrypted email products [26]).
We’ve separately confirmed the domain registrations described above were once registered as indicated by Joel.
Additional Observations
Separately, we noted the following observations after taking a closer look at Msgsafe.io and studying TrustCor’s certificate issuance.
Msgsafe.io
TrustCor owns msgsafe.io, a privacy-focused webmail platform that appears popular across ransomware attacks (examples [4], [5], and [6]).
Bad actors’ use of TrustCor’s service offering should not be considered a representation of the service, or TrustCor, itself. However, we are curious to understand actions TrustCor has taken against the addresses represented in the attacks described above, and others that may have been reported in the past. While TrustCor’s responses to known instances of abuse are not directly related to its position as a trusted CA, they could be interpreted as a demonstration of TrustCor’s commitment to upholding security and privacy on the web.
Certificate Issuance
We studied TrustCor's TLS server certificate issuance and did not find signs of mis-issuance or clear violations of the Baseline Requirements.
We identified that ~35% of the dnsNames represented in the certificates issued by TrustCor were publicly accessible at the time of evaluation, and only 59% of those served TrustCor-issued Certificates.
Closely studying issuance patterns, most TrustCor-issued certificates were issued to the following domains: ddns.net, hopto.org, sytes.net, zapto.org, myddns.me, servebeer.com, myftp.org, and servehttp.com.
We would have expected a substantially broader set of publicly accessible domains, but this is not intended to express wrongdoing by TrustCor.
If there are any questions regarding any of the items above, we’d be happy to address them.
- Ryan
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/63F407D0-3AD3-40CB-912E-3E4C2ABD2CCC%40trustcor.ca.
Filippo Valsorda
Nov 9, 2022, 9:56:01 AM11/9/22
to dev-secur...@mozilla.org
We identified that ~35% of the dnsNames represented in the certificates issued by TrustCor were publicly accessible at the time of evaluation, and only 59% of those served TrustCor-issued Certificates.
Closely studying issuance patterns, most TrustCor-issued certificates were issued to the following domains: ddns.net, hopto.org, sytes.net, zapto.org, myddns.me, servebeer.com, myftp.org, and servehttp.com.
We would have expected a substantially broader set of publicly accessible domains, but this is not intended to express wrongdoing by TrustCor.
Thank you Kathleen and Ryan for quickly addressing the issues with the trustworthiness of this CA operator.
I also noticed the same issuance patterns, and wanted to note that all those domains belong to the same Dynamic DNS service [1] which offers free Trustcor certificates [2].
I agree that this doesn't indicate any wrongdoing, but I expect that the fact that this CA seems to mostly serve a single service provider will be part of the "self-assessment of risk versus benefit of the TrustCor CA’s root certificates being included in Mozilla’s root store" that Kathleen requested.
Clint Wilson
Nov 11, 2022, 7:26:48 PM11/11/22
to MDSP, Rachel McPherson, Serge Egelman, joel.r...@ucalgary.ca, Ryan Dickson
Hello all,
In order to further compile the observations that may warrant some response from TrustCor, the Apple Root Program would like to add some additional notes. We concur with views expressed below that the corpus of these observations lend themselves to reasonable doubt about this company’s ability to operate as a publicly trusted CA, and at this point believe it similarly reasonable to expect TrustCor to address the concerns raised herein.
Observations:
- The “Primary Market / Customer Base” field for TrustCor in CCADB indicates "TrustCor develops privacy protection services and issues certificates to its customers in support of such services.”
- This seems to indicate that certificate issuance is not the core of their business, but rather augmentative thereto. However, looking at their website http://www.trustcorsystems.com/ (which redirects to https://trustcor.com/), there is little mention, and nothing predominantly represented, of products or services aside from TLS and S/MIME certificate issuance.
- Especially in light of the report which started this thread and other observations shared since, this rather benign-seeming observation then prompts the question: What are the privacy protection services these certificates are being issued in support of?
- As highlighted elsewhere, the address TrustCor has listed on CCADB doesn’t appear to house TrustCor offices and instead points to what appears to be a series of retail outlets, including a UPS Store, as referenced in the related Washington Post article (https://www.washingtonpost.com/technology/2022/11/08/trustcor-internet-addresses-government-connections/).
- Where is the Ontario Headquarters of TrustCor, as referenced by the corpus of audit statements representing TrustCor?
- Looking at Ontario Business Records, it also appears that TrustCor Systems S. DE R.L. (the corporation listed on their audits) "ceased activity in Ontario" on December 31, 2016. There are other registered entities with the TrustCor name, but these other registered businesses appear to be unrelated to TrustCor CA.
Thank you,
-Clint
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADEW5O-QOZuaEpZJV8hwxb_CZb17z%2BB1SARsgbn2wPXqhdVoEg%40mail.gmail.com.
Rachel McPherson
Nov 18, 2022, 2:14:02 PM11/18/22
to MDSP, Clint Wilson, Ryan Dickson, Kathleen Wilson, joel.r...@ucalgary.ca, Serge Egelman
Kathleen, Ryan, Clint and the rest of the community:
I was reminded by some of you this is a big public forum with non-CA-operators and non-browser/platform-developers present, and that participants have a lot of interest in these topics but not always the same level of experience or familiarity with the CA operations and root CA program guidelines or technical knowhow as the intended audience. Therefore let me begin by saying THANK YOU to my fellow CA/B Forum members and members of the larger community for reminding me of that, and separately thank you for those of you that have sent very nice and encouraging, supportive emails (you know who you are). I appreciate working with many of you for many years and your positive messages were very meaningful and heartfelt. Given the publicity of this forum, I will do my best to respect individuals by not constantly using their names or calling out other root program member organizations as examples, even when it would be helpful to do so. Instead I will ask you to consider that aspect in my response. Also, I will use "our company" when speaking of TrustCor (the CA operator) and MsgSafe (the email service). I will use "the researchers" when speaking about Serge Edelman, Joel Reardon, their commercial enterprise AppCensus, or the universities for which they work (University of California, Berkeley and the University of Calgary, respectively).
It is important readers understand we have never been accused of, and there is no evidence to suggest that TrustCor violated conduct, policy, or procedure, or wrongfully issued trusted certificates, or worked with others to do so. We have not done any of those things. It’s also important to understand TrustCor operates a certificate authority (TrustCor CA) which provides CA services protected and insulated by an exclusion agreement, and TrustCor operates a privacy-enhancing communications service (MsgSafe.io) as two distinct business units.
I will do my best to succinctly respond to the questions and concerns from the representatives from the root programs representatives first, and then for the readers wanting additional detail, I will provide more context in the sections below the most pertinent information of my response. I have also attached a memo from Wylie who wanted to be heard as part of this process. For those of you who want to cover (journalism) the topic, thank you in advance for considering the whole message and attachments before you write anything or before you call us, please.
———————————
In Response to Kathleen’s (Mozilla) concerns, providing further clarification as requested:
In Response to "How was an unobfuscated version of the Measurement Systems SDK incorporated into MsgSafe?":
Our company never published a production or supported version of the MsgSafe mobile app containing the Measurement Systems SDK. Relative to the tiny population of Beta product-testers (which were largely our own employees) who chose to test a Beta version of the app containing that SDK, I will add that during the development stages of MsgSafe’s BETA mobile app, our developers sought out the help from 3rd party software services to obtain better app analytics. We are aware that they evaluated other SDKs and tools like Firebase, Bugsnag, etc. but they claimed to not help much in troubleshooting and improving the app functionality across all device manufacturers and OS versions. There was a time during this process where they incorporated additional software developers to help with the issues we were facing. Whether or not the SDK was added for a developer’s own financial gain or otherwise is beyond us and we don’t care to speculate. Again, the MsgSafe BETA mobile app was never released in a production supported version and has been abandoned for years, and we can confirm the mobile-first web UI, which is the only supported mobile interface in-use today and for the last few years, which does not contain any SDK from anyone.
As far as how the MsgSafe mobile app obtained an “unobfuscated version” of the SDK? It is not our place to speculate, but it only makes sense that any company would provide updates to their software over time. The third-party app archive website containing MsgSafe’s APK, as referenced in the researcher’s post, is over 3 years old. It should come as no surprise that the software found there doesn’t match up exactly to the software found in apps they reported about in April 2022. Our developers probably didn’t even notice subtle changes like this because it’s not our practice to reverse engineer other company’s software and violate license agreements.
In Response to "Explanation of the ownership, governance, and relationship between Trustor, Measurement Systems and Packet Forensics International, especially focusing on how the documented actions by other Vostrom Holdings organizations such as Measurement Systems impact TrustCor and its operations.
To what extent does TrustCor today maintain a business relationship or share ownership/ corporate officers with Measurement Systems or Packet Forensics?":
In Response to "If Trustcore today does not maintain a business relationship or share ownership/corporate officers, has it done so in the past? If so, when? When was the relationship disolved?”:
In Response to "What in general explains the shared corporate officers across the companies?”:
In Response to "Do you have separate corporate registration documentation demonstrating that the TrustCor CA is a different organization than the Trustcor entity that shares corporate officers with Measurements Systems. If so, please provide it.”:
In Response to "State the number of SMIME certificates whose private keys were stored in versions of the MsgSafe app which included the identified malware. State TrustCor CA’s plan for those certificates; e.g. timeline for revoking them.”:
In Response to "Self-assessment of risk versus benefit of the TrustCor CA’s root certificates being included in Mozilla’s root store with the websites (TLS) and email (S/MIME) trust bits enabled. Please see https://wiki.mozilla.org/CA/Quantifying_Value for the information to be provided.”:
In Response to "Statement of Auditor’s Qualifications, as explained here: https://wiki.mozilla.org/CA/Audit_Statements#Providing_Auditor_Qualifications”:
In Response to the concerns and questions from the researcher’s post as specifically referenced by Kathleen are included in-line below:
In Response to "There is substantial evidence that Measurement Systems and TrustCor are closely related: Both had their domains registered by Vostrom Holdings. (as illustrated in this post by AppCensus on the basis of whois lookups)”:
TrustCor does not have or maintain any business relationship or share any officers or ownership with Measurement Systems or Packet Forensics, or any other defense company. The documented actions and opinions do not impact TrustCor's CA operations in any way. Additionally, any shareholders have no control over our CA operations (as enforced by our exclusion agreement), and any misbehaviour of organizations or individuals external to us are a result of their decisions and do not affect our operations.
In Response to "If Trustcore today does not maintain a business relationship or share ownership/corporate officers, has it done so in the past? If so, when? When was the relationship disolved?”:
Unknown until recently by any employee officers of TrustCor we and Measurement Systems S de RL had in common a group of investors who represented funds (groups of companies and other funds), not individuals. Even though we shared a common group of investment funds, we have always operated our business independently of any other company and have exclusion provisions in place to protect the CA business from having access-to or being controlled by or influenced from any third-party, investors, equity-holders, or anyone other than TrustCor’s CA Approving Officials and employees. To the best of our knowledge (and our focused investigation) there is not and has never been shared ownership with any defense company or any USA company. This common group of investors with Measurement Systems S de RL. had already dissolved mid 2021, before these recent claims were publicized, meaning as a natural course of business and not as a reaction to any claims or adverse events. In 2021 TrustCor ownership was transferred from the initial investors/founders to the employees of TrustCor. The legal process has been very step-by-step and very slow, especially due to the protracted treatment and recent death of one key founder, Ian Abramowitz. Nonetheless, it is underway and irreversible, and the common investment vehicle was dissolved over a year ago.
In Response to "What in general explains the shared corporate officers across the companies?”:
The initial investors/founders of both holding companies were known to each other and decided to diversify their investments across multiple companies and in multiple territories, which is apparently a common funding practice. They are strictly passive investors, with the exception of Ian Abramowitz.
In Response to "Do you have separate corporate registration documentation demonstrating that the TrustCor CA is a different organization than the Trustcor entity that shares corporate officers with Measurements Systems. If so, please provide it.”:
(from above) The legal process has been very step-by-step and very slow, especially due to the protracted treatment and recent death of one key founder, Ian Abramowitz. Nonetheless, it is underway and irreversible, and the common investment vehicle was dissolved over a year ago. Once it completes we will be pleased to share the public records, but we cannot control how long it takes various attorneys to reflect changes upon death, etc. Obviously Ian’s name is on many records already publicized and searching for his name allows anyone to see his memorial website from June 2022 (but he had been in treatment for some time) and other public records of this type. Since its inception in 2013, TrustCor’s CA business unit has been completely insulated and protected from any shareholders through its exclusion agreement, which separates equity ownership from access-to or control-over the CA business unit.
In Response to "State the number of SMIME certificates whose private keys were stored in versions of the MsgSafe app which included the identified malware. State TrustCor CA’s plan for those certificates; e.g. timeline for revoking them.”:
No private keys were ever stored on the MsgSafe mobile application, including in the unreleased BETA version referenced by the researchers. Therefore, we do not see any reason to revoke any of the S/MIME certificates issued within the timeframe that the MsgSafe Beta mobile app was in circulation. In addition, all of TrustCor’s S/MIME certificates are issued with a validity period equal to 365 days or less. Any S/MIME certificates issued to MsgSafe users during the timeframe of the BETA app would all be expired and invalid a long time ago.
In Response to "Self-assessment of risk versus benefit of the TrustCor CA’s root certificates being included in Mozilla’s root store with the websites (TLS) and email (S/MIME) trust bits enabled. Please see https://wiki.mozilla.org/CA/Quantifying_Value for the information to be provided.”:
We have provided the CA-Quantifying Value Statement as a separate document, attached.
In Response to "Statement of Auditor’s Qualifications, as explained here: https://wiki.mozilla.org/CA/Audit_Statements#Providing_Auditor_Qualifications”:
TrustCor’s WebTrust audit is performed by Princeton Audit Group, Inc. (“PAG”), with the accreditation found here: https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/licensed-webtrust-practitioners-international
PAG’s lead auditor is Vijay Khosla and PAG’s team of auditors carry CISA and CISM certifications and relevant in-house training. Average years of experience, in trust services or similar information systems, for the audit team includes 34 years in IT Audit Audits, 10 years in SOC 1,2,3 reporting, 5 years in SOX, 10 years in WebTrust Audits. Qualifications include: over 10 years in: IT and Infrastructure Audit, SDLC and Risk Assessment; Data Center Audits; Encryption training; Cost Accounting Experience; Physical Security; Network Security; and Cloud Computing.
Credentials include: CPA, CISA, CISM, AICPA, CPA Canada PAG audit team members are bound by law to comply with standards applicable to their respective qualifications and also as required for e.g. AICPA, CISA, CISM and CPA Canada. As of TrustCor’s 2021 audit period, PAG does not rely on any third-party specialists or affiliate audit firms.
In Response to the concerns and questions from the researcher’s post as specifically referenced by Kathleen are included in-line below:
In Response to "There is substantial evidence that Measurement Systems and TrustCor are closely related: Both had their domains registered by Vostrom Holdings. (as illustrated in this post by AppCensus on the basis of whois lookups)”:
Upon further investigation into our domains and with additional information from our legal team, we have found that TrustCor acquired the DecoyMail system many years ago as the basis of our MsgSafe.io product and service. First available in October 2000 (over 22 years ago), the DecoyMail product (and its successor, our MsgSafe.io) is an incredibly sophisticated and sufficiently complex system with many components. A single component of MsgSafe.io allows domain names to be conveniently purchased through the software’s web interface which triggers a backend domain-registration 'register' mechanism that is pointed to an API or registrar account. In the early days of the long transition and upgrading (porting to a different programming language) of the software from the DecoyMail service to the MsgSafe.io service (which took years), these domains were registered while the software was still pointed to the same registrar account of the previous owner which owned many other domains including others unrelated DecoyMail customer domains and also domains of the registrar account owner. Even still, it was not even a corporate/wholesale account, it was a personal account with a variety of domains held by one of the original DecoyMail shareholders. The platform was not officially relaunched for several years when it was announced as MsgSafe.io as shown here: https://trustcor.com/news/12012016.php. Even after relaunching it, several more years passed before all domains were migrated to the production registrar, DNSimple, and we are not even certain they were all migrated — some DecoyMail users did not transition their accounts fully and some lookalike domains were not identified because they were lookalikes or homoglyphs and not critical to the company branding or functionality.
In Response to "They have identical corporate officers: Measurement Systems, Trustcor Systems”:
This statement is inaccurate because the funding/holding companies in question were already dissolved in 2021. We have explained our restructuring (above) and cannot speak with regard to the other company because we do not know them. It is worth noting that the media's coverage does not indicate who is the beneficial owner of Measurement Systems.
The reporting and public records merely indicate that an individual affiliated with a defense company (investor or former employee) may also be an investor in one or both of the funds/holding companies and therefore potentially was at some time an investor in our company through an investment in another company. The researchers' conclusions that the journalists further expound are confusing the facts. For example, if it holds that any "investor" in one company (making them an "affiliate" of that company) is also affiliated as an "investor" in another company, links the two companies together as affiliates, and then even when one of those two companies further invests in a third company (one part removed), basically most businesses and even CAs come into question because of the suggested transitive property. Also conflated by the researchers and media is the point about American corporations bearing similar (not exactly the same) names to those of the funds/holding companies in question. We are not now and never have been owned by any American company with any names similar to those pointed out by the researchers. We have no idea what those companies are or what are their purpose, but they are not affiliated with our company or anyone known to us. Our business was formed in Panama over 9 years ago and any paperwork filed in the last few years, pointing to an American or similar-named company was not executed by us or affiliated with us in any way.
In Response to "TrustCor operates the mail encryption product MsgSafe and a beta version of MsgSafe contained the only known unobfuscated version of the spyware SDK. (Beta APK, inspected by Joel and signed by Google)”:
In Response to "The MsgSafe product relies in part on SMIME certificates issued by TrustCor (MsgSafe Website)”:Our company never published a production or supported version of the MsgSafe mobile app containing the Measurement Systems SDK. Relative to the tiny population of Beta product-testers (which were largely our own employees) who chose to test a Beta version of the app containing that SDK, I will add that during the development stages of MsgSafe’s BETA mobile app, our developers sought out the help from 3rd party software services to obtain better app analytics. We are aware that they evaluated other SDKs and tools like Firebase, Bugsnag, etc. but they claimed to not help much in troubleshooting and improving the app functionality across all device manufacturers and OS versions. There was a time during this process where they incorporated additional software developers to help with the issues we were facing. Whether or not the SDK was added for a developer’s own financial gain or otherwise is beyond us and we don’t care to speculate. Again, the MsgSafe BETA mobile app was never released in a production supported version and has been abandoned for years, and we can confirm the mobile-first web UI, which is the only supported mobile interface in-use today and for the last few years, which does not contain any SDK from anyone.
As far as how the MsgSafe mobile app obtained an “unobfuscated version” of the SDK? It is not our place to speculate, but it only makes sense that any company would provide updates to their software over time. The third-party app archive website containing MsgSafe’s APK, as referenced in the researcher’s post, is over 3 years old. It should come as no surprise that the software found there doesn’t match up exactly to the software found in apps they reported about in April 2022. Our developers probably didn’t even notice subtle changes like this because it’s not our practice to reverse engineer other company’s software and violate license agreements.
MsgSafe.io is both a product and business, operated separately and independently from TrustCor CA, albeit owned by TrustCor. MsgSafe.io integrates with TrustCor’s S/MIME certificate API for issuance of S/MIME certificates, just like any other CA customer of TrustCor would do. In addition, MsgSafe.io also allows customers to bring their own S/MIME certificates (so not all of MsgSafe user’s certificates are generated by TrustCor CA).
———————————
In Response to Ryan’s (Google) concerns, providing further clarification as requested:
In Response to "Coincidence #1 Audit Irregularities”:
TrustCor uses Princeton Audit Group (PAG) as its auditor.
According to CCADB records, PAG does not audit any other publicly-trusted CAs.
According to CCADB records, PAG does not audit any other publicly-trusted CAs.
It is not within our company’s purview to choose which auditors are qualified or accredited to perform the required WebTrust audits. We merely follow the root program and CA/B guidelines and select from the published list. Our founders originally called and spoke with most of the auditors on the published list at the time and have used the same one ever since because as I’m sure you’ve seen with other program members, once you have an auditor it is easier and more cost effective to continue using the same one year after year. The list is published here and as you can see our auditor remains an accredited auditor (PAG was on the list since before our company was founded and still is today). If there is a compelling reason you or any root program manager has to select another auditor, we are certainly open to changing if that is required, and it appears as though the list is now much longer almost ten years after we first had to choose.
https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/licensed-webtrust-practitioners-international
TrustCor’s most recent audit statements ([Standard] and [BR - TLS]) describe CA operations in Toronto, Ontario, Canada.
PAG is listed as a licensed practitioner only in the USA.
TrustCor’s CPS indicates the data centers are located in Phoenix.
Though the management assertion references Phoenix, PAG’s attestation does not.
As you stated, it was included in the management’s assertion and it appears to be a clerical error that PAG’s attestation did not additionally include the location of TrustCor’s data centers specifically, but we did confirm with our auditor that this will be included in PAG's 2022 attestation. In addition, under 5.1.1 Site Location and Construction, of TrustCor’s CPS, we also state that TrustCor CA’s data centers are located in Phoenix, Arizona, USA, which are visited and audited annually.
Beyond [1], [2], and [3], we found little public information specific to audits performed by PAG.
It is not within our company’s purview to choose which auditors are qualified or accredited to perform the required WebTrust audits. We merely follow the root program and CA/B guidelines and select from the published list. Our founders originally called and spoke with most of the auditors on the published list at the time and have used the same one ever since because as I’m sure you’ve seen with other program members, once you have an auditor it is easier and more cost effective to continue using the same one year after year. The list is published here and as you can see our auditor remains an accredited auditor (PAG was on the list since before our company was founded and still is today). If there is a compelling reason you or any root program manager has to select another auditor, we are certainly open to changing if that is required, and it appears as though the list is now much longer almost ten years after we first had to choose.
https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/licensed-webtrust-practitioners-international
In Response to "Coincidence #2 WIPO Complaint”:
This page summarizes a 2018 complaint filed with the WIPO Arbitration and Mediation Center against Trustcor Systems S. De R.L. by Compagnie Générale des Etablissements Michelin, owner of BFGOODRICH.
The complaint cites concerns related to TrustCor registering bfgoodrichpromotions.net, and the risk of a related phishing scheme resulting from the registration and corresponding email servers configured on the disputed domain name.
Ultimately, the Panel found TrustCor’s passive holding of the disputed domain name indicated “bad faith”. Furthermore, the Panel also found that TrustCor’s failure to respond to the Complainant’s cease-and-desist letters was an additional circumstance evidencing the TrustCor’s “bad faith”.
This type of behavior is consistent with that described by Joel Reardon here (see discussion beginning with “Another strange thing is that whois information lists Wylie Swanson as the registrant for a number of domains that closely mimic other encrypted email products [26]).
We’ve separately confirmed the domain registrations described above were once registered as indicated by Joel.
The complaint cites concerns related to TrustCor registering bfgoodrichpromotions.net, and the risk of a related phishing scheme resulting from the registration and corresponding email servers configured on the disputed domain name.
Ultimately, the Panel found TrustCor’s passive holding of the disputed domain name indicated “bad faith”. Furthermore, the Panel also found that TrustCor’s failure to respond to the Complainant’s cease-and-desist letters was an additional circumstance evidencing the TrustCor’s “bad faith”.
This type of behavior is consistent with that described by Joel Reardon here (see discussion beginning with “Another strange thing is that whois information lists Wylie Swanson as the registrant for a number of domains that closely mimic other encrypted email products [26]).
We’ve separately confirmed the domain registrations described above were once registered as indicated by Joel.
The bfgoodrichpromotions.net complaint was not related to TrustCor CA’s products or services but to MsgSafe.io’s privacy-focused email service. Unfortunately, free or low-cost email service providers are often abused by phishing, ransomware, and other abuse because they lend to privacy and anonymity and how easily bad actors can acquire them. For instance, bfgoodrichpromotions.net was registered by user who signed up for MsgSafe.io's service with, and had their email forwarding to, their Gmail account. In 2018, MsgSafe.io’s support staff indeed failed to handle this event timely due to being overwhelmed by the high volume of abuse happening at that time. As a result, MsgSafe.io implemented several abuse-reducing solutions, dramatically decreasing the success of bad actors on the platform and have since added support team members to respond within a timely manner to all support tickets.To quote Ryan, "TrustCor’s service offering should not be considered a representation of the service, or TrustCor, itself."
———————————
TrustCor owns msgsafe.io, a privacy-focused webmail platform that appears popular across ransomware attacks (examples [4], [5], and [6]).
In Response to "Bad actors’ use of TrustCor’s service offering should not be considered a representation of the service, or TrustCor, itself. However, we are curious to understand actions TrustCor has taken against the addresses represented in the attacks described above, and others that may have been reported in the past. While TrustCor’s responses to known instances of abuse are not directly related to its position as a trusted CA, they could be interpreted as a demonstration of TrustCor’s commitment to upholding security and privacy on the web.”:
Certificate Issuance
There is a niche out there for privacy-focused people who want private and anonymous email services. This is why services such as [name suppressed for politeness], MsgSafe.io and others are always in demand. Unfortunately, these privacy-focused services, and frankly all free or low-cost email service providers, are often used by ransomware developers because of how they lend to privacy and anonymity, and how easily they can be obtained. (examples of gmail being the most popular across ransomware attacks [1], [2]).With that being said, we take spam/phishing very seriously and MsgSafe has a zero tolerance policy, as clearly stated in its Terms and Conditions [3], when we are aware of the services being used for malicious intentions. In the examples of the email addresses used in the ransomware attacks references by Ryan, none of these were brought to our attention through our standard support/abuse ticketing system, and if they had we would have shut down the accounts immediately. Since becoming aware of these instances, we can confirm that all 3 of these accounts have been terminated as of 2022-11-15 for being in violation of MsgSafe’s Terms and Conditions.Another "leader move" in innovation for us worth noting along these lines is we have implemented a completely-automated account closure system for the most heinous abuses where we believe a human-in-the-loop is not necessary, such as spam (also a policy violation). You cannot effectively send high volume phishing or spam through MsgSafe using a combination of automated account creation and/or high volume message-sending because of built-in rate limiting, however we took an extra step to check constantly for receive-rate abuses when spammers send mail through another high volume spam sending system such as Gmail, and use a MsgSafe.io email as their reply-to address or in their return-path, and when that rate-limit is reached (indicating they did not spam through us, but still violated our policy since a MsgSafe email address was used as an aspect of sending spam through someone else), our automated system closes their account for policy violation and automatically begins returning a helpful and informative error message next time someone sends to their MsgSafe.io account, letting everyone involved (victims, account holders or friends) their account was closed due to abuse.
Certificate Issuance
We studied TrustCor's TLS server certificate issuance and did not find signs of mis-issuance or clear violations of the Baseline Requirements.
We identified that ~35% of the dnsNames represented in the certificates issued by TrustCor were publicly accessible at the time of evaluation, and only 59% of those served TrustCor-issued Certificates.
Closely studying issuance patterns, most TrustCor-issued certificates were issued to the following domains: ddns.net, hopto.org, sytes.net, zapto.org, myddns.me, servebeer.com, myftp.org, and servehttp.com.
We would have expected a substantially broader set of publicly accessible domains, but this is not intended to express wrongdoing by TrustCor.
We identified that ~35% of the dnsNames represented in the certificates issued by TrustCor were publicly accessible at the time of evaluation, and only 59% of those served TrustCor-issued Certificates.
Closely studying issuance patterns, most TrustCor-issued certificates were issued to the following domains: ddns.net, hopto.org, sytes.net, zapto.org, myddns.me, servebeer.com, myftp.org, and servehttp.com.
We would have expected a substantially broader set of publicly accessible domains, but this is not intended to express wrongdoing by TrustCor.
In Response to "Certificate Issuance" points:
TrustCor is not aware of and works diligently to ensure there are no mis-issuances or violations of the Baseline requirements. A large number of the “dnsNames” represented are inaccessible because at that moment they are not currently online (potentially dynamic dns working correctly), or were accounts, or were proactively shutdown for any number of reasons. Given this the 59% number may be accurate, but the 35% number is not necessarily indicative of anything.We have innovated and lead the market in the adoption of TLS server certificate issuance for one of the longest-running and most respected dynamic DNS services worldwide and the positive impact this move has made cannot be overstated. Dynamic DNS services are a critical aspect of home-based IoT and "private cloud" solutions which have a dramatic and important positive impact on personal privacy and security. Instead of sending all your data to the cloud, dynamic DNS services allow users to self-host their video cameras, data storage and IoT home automation solutions in their home or small business, to enhance their privacy and security. Until our partnerships in this area, obtaining server certificates that operate properly with these private home systems relying upon dynamic DNS was elusive, complex to implement, and therefore the market was completely underserved.
———————————
In Response to Clint’s (Apple) concerns, providing further clarification as requested:
In Response to Clint’s (Apple) concerns, providing further clarification as requested:
Observations:
The “Primary Market / Customer Base” field for TrustCor in CCADB indicates "TrustCor develops privacy protection services and issues certificates to its customers in support of such services.”
This seems to indicate that certificate issuance is not the core of their business, but rather augmentative thereto. However, looking at their website http://www.trustcorsystems.com/ (which redirects to https://trustcor.com/), there is little mention, and nothing predominantly represented, of products or services aside from TLS and S/MIME certificate issuance.
In Response to "Especially in light of the report which started this thread and other observations shared since, this rather benign-seeming observation then prompts the question: What are the privacy protection services these certificates are being issued in support of?”:
TrustCor is the parent company of TrustCor CA and MsgSafe.io. Certificate issuance is core to the business of TrustCor. MsgSafe.io is a privacy protection service. In relation to the certificate services that TrustCor provides MsgSafe.io, MsgSafe.io acts like a customer of TrustCor, leveraging TrustCor’s API to request S/MIME certificates for their customers in support of MsgSafe’s email services. TrustCor, and the associated website, predominantly promotes TrustCor’s CA business and efforts, while the MsgSafe.io business separately markets and promotes itself. MsgSafe.io is an example of privacy protection services.
As highlighted elsewhere, the address TrustCor has listed on CCADB doesn’t appear to house TrustCor offices and instead points to what appears to be a series of retail outlets, including a UPS Store, as referenced in the related Washington Post article (https://www.washingtonpost.com/technology/2022/11/08/trustcor-internet-addresses-government-connections/).
In Response to: "Where is the Ontario Headquarters of TrustCor, as referenced by the corpus of audit statements representing TrustCor? Looking at Ontario Business Records, it also appears that TrustCor Systems S. de R.L. (the corporation listed on their audits) "ceased activity in Ontario" on December 31, 2016. There are other registered entities with the TrustCor name, but these other registered businesses appear to be unrelated to TrustCor CA.”:
TrustCor’s Ontario Headquarters address was previously located at 7270 Woodbine Avenue, Suite 308 Markham ON L3R 4B9 Canada. When Ian’s health began to decline, and given that Ian, Ryan and I were the only Canadian employees, and our technical staff were centrally located to our data centre locations, we decided on a remote-work structure in Canada. While the Canadian filings ended in 2016, we still maintain personnel, a secure storage facility, and we have always maintained a consistent mailing address in Ontario where the public can contact the TrustCor Policy Authority in writing for policy related enquiries and this is the same address printed on TrustCor’s letterhead and within our CPS documents.
To directly address and assuage the public’s concern, we will replace the word “Headquarters” with “Address” in future documentation.In the interest of transparency, we have additional storage, meeting space, and technical operations (supporting full time employees) in Phoenix, AZ, which is an audited location where our equipment and IT process controls are reviewed annually.
—————————————
To address Joel’s (University of Calgary/AppCensus) concerns,
In Response to: "Along with investigative journalists at the Wall Street Journal, we discovered that Vostrom Holdings is doing business as Packet Forensics [6], a company that sells lawful-intercept products [7].”:
We cannot comment on the activity of another company, as any comment would be purely our speculation.
In Response to: "The Measurement Systems company was also registered in Virginia [8] by "Raymond Alan Saulino", which was then made inactive when Google took action against the SDK [9].”:
We cannot comment on the activity of another company, as any comment would be purely our speculation.
In Response to: ""Raymond A Saulino" is also an officer for Packet Forensics International LLC [10], and despite the middle name not being an exact match, they both list the same residential address [11, 12].”:
We cannot comment on the activity of another company or individual, as any comment would be purely our speculation.
In Response to: "Domains were registered by Vostrom: One of the domains stood out: trustcor.co, which redirected at the time to the TrustCor CA's website. The NS records continue to point to nsX.msgsafe.io [14], the same as trustcor.com itself [15]. Msgsafe is a TrustCor encrypted email product [16].”:
Upon further investigation into our domains and with additional information from our legal team, we have found that TrustCor acquired the DecoyMail system many years ago as the basis of our MsgSafe.io product and service. First available in October 2000 (over 22 years ago), the DecoyMail product (and its successor, our MsgSafe.io) is an incredibly sophisticated and sufficiently complex system with many components. A single component of MsgSafe.io allows domain names to be conveniently purchased through the software’s web interface which triggers a backend domain-registration 'register' mechanism that is pointed to an API or registrar account. In the early days of the long transition and upgrading (porting to a different programming language) of the software from the DecoyMail service to the MsgSafe.io service (which took years), these domains were registered while the software was still pointed to the same registrar account of the previous owner which owned many other domains including others unrelated DecoyMail customer domains and also domains of the registrar account owner. Even still, it was not even a corporate/wholesale account, it was a personal account with a variety of domains held by one of the original DecoyMail shareholders. The platform was not officially relaunched for several years when it was announced as MsgSafe.io as shown here: https://trustcor.com/news/12012016.php. Even after relaunching it, several more years passed before all domains were migrated to the production registrar, DNSimple, and we are not even certain they were all migrated — some DecoyMail users did not transition their accounts fully and some lookalike domains were not identified because they were lookalikes or homoglyphs and not critical to the company branding or functionality.
All domains registered through msgsafe (such as trustcor.co and also trustcor.com), and any domain brought to msgsafe using the bring-your-own-domain feature would contain msgsafe.io name server records that point to either nsX.msgsafe.io or nsX.dnsimple.com, which are synonymous, hosted at the same IP address, and are operated by DNSimple.
In Response to: "Like Measurement Systems, Trustcor is also registered in Panama [17]. They were registered a month apart and they share an identical set of corporate officers”:
Unknown until recently by any employee officers of TrustCor we and Measurement Systems S de RL had in common a group of investors who represented funds (groups of companies and other funds), not individuals. Even though we shared a common group of investment funds, we have always operated our business independently of any other company and have exclusion provisions in place to protect the CA business from having access-to or being controlled by or influenced from any third-party, investors, equity-holders, or anyone other than TrustCor’s CA Approving Officials and employees. To the best of our knowledge (and our focused investigation) there is not and has never been shared ownership with any defense company or any USA company. This common group of investors with Measurement Systems S de RL. had already dissolved mid 2021, before these recent claims were publicized, meaning as a natural course of business and not as a reaction to any claims or adverse events. In 2021 TrustCor ownership was transferred from the initial investors/founders to the employees of TrustCor. The legal process has been very step-by-step and very slow, especially due to the protracted treatment and recent death of one key founder, Ian Abramowitz. Nonetheless, it is underway and irreversible, and the common investment vehicle was dissolved over a year ago.
In Response to: "One of these officers is Frigate Bay Holding LLC [18]. Shortly after the WSJ article was printed, a "Raymond Saulino" filed paperwork for Frigate Bay Holdings LLC listed as its manager [19]. Raymond Saulino has also spoken to press publicly on behalf of Packet Forensics.”:
We are not now, and never have been, owned by any American company with any names similar to those pointed out by the researchers. We have no idea what those companies are or what are their purpose, but they are not affiliated with our company or anyone known to us. Our business was formed in Panama over 9 years ago and any paperwork filed this year was not executed by our company. Our lawyer has instructed us not to point out the subtle differences in names, spelling, dates of incorporation, or legal territories in which corporate entities were formed, as litigation is a potential outcome of this publication.
In Response to: "Trustcor also talks about their "geo-jurisdiction advantage" on an entire page [21] where they state that "TrustCor is a Panamanian registered company, with technical operations based in Curaçao---one of the most secure, privacy oriented jurisdictions in the world." Despite that, they have job openings for PKI Engineer and Systems Engineering in Phoenix, AZ [22, 23], the latter stating that the applicant "MUST be located near the Phoenix, AZ area - job is remote with occasional trips to data center facilities". Their own audit reports state that they are Canadian, with their data centres in Phoenix, AZ [24]. I am not particularly troubled by where they have their technical operations, but I think that it is strange to omit that the data centres are in Arizona on the lengthy descriptions of the "geo-jurisdiction advantage". Certificate authorities are about trust.”:
We find that most CAs don’t publicly disclose the locations of their CA data centre location on the home page of their marketing websites. The aspect of our business which operates the encrypted email product and stores secure customer content, MsgSafe, has technical operations based in Curaçao (hence the "geo-jurisdiction advantage”) whereas the CA business unit has data centers located in Arizona. In the interest of trust and transparency, to be clear, TrustCor’s CA business unit does not perform key escrow services and therefore does not store customer private-keys, as stated in our CPS.
In Response to: "I have also tested the Msgsafe encrypted email product in the browser, while saving the resulting traffic using Firefox and Chrome's "save to HAR" file option. I am not convinced there is E2E encryption or that Msgsafe cannot read users’ emails. I see that email contents and attachments are sent plaintext (over TLS) to api.msgsafe.io, even when sending to other Msgsafe users or when using PGP or SMIME to send to non-Msgsafe users. The SMIME cert is sent inbound from the server, and there is no outbound traffic that embodies the public key to be signed. The password is sent plaintext to the server (over TLS) and thus any key derived from that password would also be known by the server. Hanlon’s razor tells me I should not attribute these errors to malice; it could just be a developmental failure [25]. Nevertheless, I think it is reasonable expectation that a root certificate authority can get the crypto right, and so I'm concern regardless of the reason why.”:
MsgSafe.io’s platform can be utilized in a number of ways, including using the e-mail forwarding features and not using the web-based interface at all. It is impossible to speculate what you experienced or tested without comprehensive knowledge of the account configuration, forwarding addresses, user identities and contacts, and their associated GPG and S/MIME certificates.As far as you not believing the product is offering adequate encryption capabilities, let me first say that I do not want to drag the names of any other encryption products or services through the mud. To address your concerns, based on our teams exhausted research into many other providers offering similar services, one basic rule applies; whether the encryption or decryption functions are occurring on the client (often in javascript) or on the server, the server is still storing and handling the key material in the process. Our implementation is one of two commonly used by secure messaging services and chosen for a few reasons. If encryption occurs on the client then the key material is passed from the server to the browser over TLS. If the encryption occurs on the server then the message is transferred from the client to the server over TLS, then encrypted. As the MsgSafe website explains, our team has found that implementing the key material and encryption/decryption processing on the server provides security without the additional processing requirement on the client. One of the benefits of this implementation is that it allows slower/older devices (phones) to utilize our mobile-first web experience (since, as we previously mentioned, we abandoned development of a mobile app, which could have done the encryption/decryption process on the mobile phone), while also supporting desktop users. To be clear, at no point is data passed in the clear while using the service, it is either encrypted with the user key material or encrypted with industry-standard TLS.Many MsgSafe.io users never experience sending or receiving mail using the web browser, meaning you’re only looking at one implementation of the service that is probably the least used.Of course we can accept the possibility of a weakness in MsgSafe.io's user interface, we take such reports very seriously, but we would be surprised to find that to be the case here. If you still have questions or doubts, we ask that you please file a bug report with MsgSafe.io directly via their customer support channels.It is also important to note that MsgSafe.io and TrustCor’s CA do not share development resources or infrastructure and are completely different lines of business.
In Response to: "Another strange thing is that whois information lists Wylie Swanson as the registrant for a number of domains that closely mimic other encrypted email products [26]. This includes hushemail.net, protonmails.com, and tutanoto.com, which shadow competing services, and which redirect users who visit them to msgsafe.io. Wylie Swanson is the co-founder of Trustcor [27]. In my opinion, it looks like typo squatting and I would not expect that a root certificate authority to be engaged in this kind of behaviour.”:
When the domains were registered, it was also common for advertisers to buy Google search keywords of their competitors as part of their SEO marketing. At the time, it was perceived as a low-cost way for a small start-up e-mail provider to direct a very small amount of traffic to MsgSafe.io’s new privacy-focused email services. It was not an attempt to mislead consumers in any way -- users very clearly understood where they had been directed. It is not the company's stance or best practice to register domain names similar to competitors, only happened with a small number of domains, and did not occur again after 2016.
In Response to: "A final coincidence: one of Msgsafe's email domains is decoymail.com, which Msgsafe users can request and which redirects to msgsafe.io [28]. In 2014 it was registered to VOSTROM Holdings, Inc., while in 2015 it was registered to TRUSTCOR SYSTEMS S. de R.L. [29]. DecoyMail was a company created by Rodney Joffe [30], who is the person who also filed the original registration of Packet Forensics [31] and was still an authorized agent for Packet Forensics in a 2019 filing [32] and a Manager for Packet Forensics in a 2021 filing [33]. The email rjo...@centergate.com is linked to the domains rodneyjoffe.com, packetforensics.com, and decoymail.net [34]. Decoymail.net currently redirects to msgsafe.io.”:
It is public information that TrustCor acquired the DecoyMail system many years ago as the basis of our MsgSafe.io product and service. First available in October 2000 (over 22 years ago), the DecoyMail product (and its successor, our MsgSafe.io) is an incredibly sophisticated and sufficiently complex system with many components. A single component of MsgSafe.io allows domain names to be conveniently purchased through the software’s web interface which triggers a backend domain-registration 'register' mechanism that is pointed to an API or registrar account. In the early days of the long transition and upgrading (porting to a different programming language) of the software from the DecoyMail service to the MsgSafe.io service (which took years), these domains were registered while the software was still pointed to the same registrar account of the previous owner which owned many other domains including others unrelated DecoyMail customer domains and also domains of the registrar account owner. Even still, it was not even a corporate/wholesale account, it was a personal account with a variety of domains held by one of the original DecoyMail shareholders. The platform was not officially relaunched for several years when it was announced as MsgSafe.io as shown here: https://trustcor.com/news/12012016.php. Even after relaunching it, several more years passed before all domains were migrated to the production registrar, DNSimple, and we are not even certain they were all migrated — some DecoyMail users did not transition their accounts fully and some lookalike domains were not identified because they were lookalikes or homoglyphs and not critical to the company branding or functionality.
—————————————
To address Serge’s (Berkely/AppCensus) concerns,
In Response to: “Why did MsgSafe appear to bundle an unobfuscated version of this SDK in their app? How was it obtained, if as Rachel says, they have nothing to do with the company that is spreading it? According to her email, they don't have a public app; someone should probably tell that to their social media person…”:
Our company never published a production or supported version of the MsgSafe mobile app containing the Measurement Systems SDK. Relative to the tiny population of Beta product-testers (which were largely our own employees) who chose to test a Beta version of the app containing that SDK, I will add that during the development stages of MsgSafe’s BETA mobile app, our developers sought out the help from 3rd party software services to obtain better app analytics. We are aware that they evaluated other SDKs and tools like Firebase, Bugsnag, etc. but they claimed to not help much in troubleshooting and improving the app functionality across all device manufacturers and OS versions. There was a time during this process where they incorporated additional software developers to help with the issues we were facing. Whether or not the SDK was added for a developer’s own financial gain or otherwise is beyond us and we don’t care to speculate. Again, the MsgSafe BETA mobile app was never released in a production supported version and has been abandoned for years, and we can confirm the mobile-first web UI, which is the only supported mobile interface in-use today and for the last few years, which does not contain any SDK from anyone.
As far as how the MsgSafe mobile app obtained an “unobfuscated version” of the SDK? It is not our place to speculate, but it only makes sense that any company would provide updates to their software over time. The third-party app archive website containing MsgSafe’s APK, as referenced in the researcher’s post, is over 3 years old. It should come as no surprise that the software found there doesn’t match up exactly to the software found in apps they reported about in April 2022. Our developers probably didn’t even notice subtle changes like this because it’s not our practice to reverse engineer other company’s software and violate license agreements.
Watson Ladd
Nov 18, 2022, 4:05:24 PM11/18/22
to Rachel McPherson, MDSP, Clint Wilson, Ryan Dickson, Kathleen Wilson, joel.r...@ucalgary.ca, Serge Egelman
On Fri, Nov 18, 2022 at 2:14 PM Rachel McPherson <rac...@trustcor.ca> wrote:
Kathleen, Ryan, Clint and the rest of the community:
I was reminded by some of you this is a big public forum with non-CA-operators and non-browser/platform-developers present, and that participants have a lot of interest in these topics but not always the same level of experience or familiarity with the CA operations and root CA program guidelines or technical knowhow as the intended audience. Therefore let me begin by saying THANK YOU to my fellow CA/B Forum members and members of the larger community for reminding me of that, and separately thank you for those of you that have sent very nice and encouraging, supportive emails (you know who you are). I appreciate working with many of you for many years and your positive messages were very meaningful and heartfelt. Given the publicity of this forum, I will do my best to respect individuals by not constantly using their names or calling out other root program member organizations as examples, even when it would be helpful to do so. Instead I will ask you to consider that aspect in my response. Also, I will use "our company" when speaking of TrustCor (the CA operator) and MsgSafe (the email service). I will use "the researchers" when speaking about Serge Edelman, Joel Reardon, their commercial enterprise AppCensus, or the universities for which they work (University of California, Berkeley and the University of Calgary, respectively).
It is important readers understand we have never been accused of, and there is no evidence to suggest that TrustCor violated conduct, policy, or procedure, or wrongfully issued trusted certificates, or worked with others to do so. We have not done any of those things. It’s also important to understand TrustCor operates a certificate authority (TrustCor CA) which provides CA services protected and insulated by an exclusion agreement, and TrustCor operates a privacy-enhancing communications service (MsgSafe.io) as two distinct business units.
My I am not accused of missiuance t-shirt is raising questions answered by my t-shirt.
I will do my best to succinctly respond to the questions and concerns from the representatives from the root programs representatives first, and then for the readers wanting additional detail, I will provide more context in the sections below the most pertinent information of my response. I have also attached a memo from Wylie who wanted to be heard as part of this process. For those of you who want to cover (journalism) the topic, thank you in advance for considering the whole message and attachments before you write anything or before you call us, please.———————————
In Response to Kathleen’s (Mozilla) concerns, providing further clarification as requested:
In Response to "How was an unobfuscated version of the Measurement Systems SDK incorporated into MsgSafe?":Our company never published a production or supported version of the MsgSafe mobile app containing the Measurement Systems SDK. Relative to the tiny population of Beta product-testers (which were largely our own employees) who chose to test a Beta version of the app containing that SDK, I will add that during the development stages of MsgSafe’s BETA mobile app, our developers sought out the help from 3rd party software services to obtain better app analytics. We are aware that they evaluated other SDKs and tools like Firebase, Bugsnag, etc. but they claimed to not help much in troubleshooting and improving the app functionality across all device manufacturers and OS versions. There was a time during this process where they incorporated additional software developers to help with the issues we were facing. Whether or not the SDK was added for a developer’s own financial gain or otherwise is beyond us and we don’t care to speculate. Again, the MsgSafe BETA mobile app was never released in a production supported version and has been abandoned for years, and we can confirm the mobile-first web UI, which is the only supported mobile interface in-use today and for the last few years, which does not contain any SDK from anyone.
As far as how the MsgSafe mobile app obtained an “unobfuscated version” of the SDK? It is not our place to speculate, but it only makes sense that any company would provide updates to their software over time. The third-party app archive website containing MsgSafe’s APK, as referenced in the researcher’s post, is over 3 years old. It should come as no surprise that the software found there doesn’t match up exactly to the software found in apps they reported about in April 2022. Our developers probably didn’t even notice subtle changes like this because it’s not our practice to reverse engineer other company’s software and violate license agreements.
In Response to "Explanation of the ownership, governance, and relationship between Trustor, Measurement Systems and Packet Forensics International, especially focusing on how the documented actions by other Vostrom Holdings organizations such as Measurement Systems impact TrustCor and its operations.To what extent does TrustCor today maintain a business relationship or share ownership/ corporate officers with Measurement Systems or Packet Forensics?":TrustCor does not have or maintain any business relationship or share any officers or ownership with Measurement Systems or Packet Forensics, or any other defense company. The documented actions and opinions do not impact TrustCor's CA operations in any way. Additionally, any shareholders have no control over our CA operations (as enforced by our exclusion agreement), and any misbehaviour of organizations or individuals external to us are a result of their decisions and do not affect our operations.
In Response to "If Trustcore today does not maintain a business relationship or share ownership/corporate officers, has it done so in the past? If so, when? When was the relationship disolved?”:Unknown until recently by any employee officers of TrustCor we and Measurement Systems S de RL had in common a group of investors who represented funds (groups of companies and other funds), not individuals. Even though we shared a common group of investment funds, we have always operated our business independently of any other company and have exclusion provisions in place to protect the CA business from having access-to or being controlled by or influenced from any third-party, investors, equity-holders, or anyone other than TrustCor’s CA Approving Officials and employees. To the best of our knowledge (and our focused investigation) there is not and has never been shared ownership with any defense company or any USA company. This common group of investors with Measurement Systems S de RL. had already dissolved mid 2021, before these recent claims were publicized, meaning as a natural course of business and not as a reaction to any claims or adverse events. In 2021 TrustCor ownership was transferred from the initial investors/founders to the employees of TrustCor. The legal process has been very step-by-step and very slow, especially due to the protracted treatment and recent death of one key founder, Ian Abramowitz. Nonetheless, it is underway and irreversible, and the common investment vehicle was dissolved over a year ago.
I do not understand how "having a group of investors in common" is the same as "there is not and has never been shared ownership with any defense company or USA company". Could you clarify the corporate structure and ownership of all major investors as well as shared officers among all entities?
In Response to "What in general explains the shared corporate officers across the companies?”:The initial investors/founders of both holding companies were known to each other and decided to diversify their investments across multiple companies and in multiple territories, which is apparently a common funding practice. They are strictly passive investors, with the exception of Ian Abramowitz.
This answer does not make sense to me. If the investors and founders were engaged in a diversification transaction, and that lead to shared corporate officers, that would not be "passive" as commonly understood, e.g. as per SEC guidance in https://www.sec.gov/corpfin/divisionscorpfinguidancereg13d-interphtm#103.11. Would it be possible to share a comprehensive list of dramatis personae?
In Response to "Do you have separate corporate registration documentation demonstrating that the TrustCor CA is a different organization than the Trustcor entity that shares corporate officers with Measurements Systems. If so, please provide it.”:(from above) The legal process has been very step-by-step and very slow, especially due to the protracted treatment and recent death of one key founder, Ian Abramowitz. Nonetheless, it is underway and irreversible, and the common investment vehicle was dissolved over a year ago. Once it completes we will be pleased to share the public records, but we cannot control how long it takes various attorneys to reflect changes upon death, etc. Obviously Ian’s name is on many records already publicized and searching for his name allows anyone to see his memorial website from June 2022 (but he had been in treatment for some time) and other public records of this type. Since its inception in 2013, TrustCor’s CA business unit has been completely insulated and protected from any shareholders through its exclusion agreement, which separates equity ownership from access-to or control-over the CA business unit.
Is this agreement together with articles of incorporation something you can share? It appears from your answer that these were not separated entities until recently: could you confirm that each step in the change of control was properly reflected in the CCADB?
In Response to "State the number of SMIME certificates whose private keys were stored in versions of the MsgSafe app which included the identified malware. State TrustCor CA’s plan for those certificates; e.g. timeline for revoking them.”:No private keys were ever stored on the MsgSafe mobile application, including in the unreleased BETA version referenced by the researchers. Therefore, we do not see any reason to revoke any of the S/MIME certificates issued within the timeframe that the MsgSafe Beta mobile app was in circulation. In addition, all of TrustCor’s S/MIME certificates are issued with a validity period equal to 365 days or less. Any S/MIME certificates issued to MsgSafe users during the timeframe of the BETA app would all be expired and invalid a long time ago.
In Response to "Self-assessment of risk versus benefit of the TrustCor CA’s root certificates being included in Mozilla’s root store with the websites (TLS) and email (S/MIME) trust bits enabled. Please see https://wiki.mozilla.org/CA/Quantifying_Value for the information to be provided.”:We have provided the CA-Quantifying Value Statement as a separate document, attached.
We can discuss this document in detail: I found it highly superficial and believe that essential elements of the questions weren't answered.
In Response to "Statement of Auditor’s Qualifications, as explained here: https://wiki.mozilla.org/CA/Audit_Statements#Providing_Auditor_Qualifications”:TrustCor’s WebTrust audit is performed by Princeton Audit Group, Inc. (“PAG”), with the accreditation found here: https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/licensed-webtrust-practitioners-internationalPAG’s lead auditor is Vijay Khosla and PAG’s team of auditors carry CISA and CISM certifications and relevant in-house training. Average years of experience, in trust services or similar information systems, for the audit team includes 34 years in IT Audit Audits, 10 years in SOC 1,2,3 reporting, 5 years in SOX, 10 years in WebTrust Audits. Qualifications include: over 10 years in: IT and Infrastructure Audit, SDLC and Risk Assessment; Data Center Audits; Encryption training; Cost Accounting Experience; Physical Security; Network Security; and Cloud Computing.
Credentials include: CPA, CISA, CISM, AICPA, CPA Canada PAG audit team members are bound by law to comply with standards applicable to their respective qualifications and also as required for e.g. AICPA, CISA, CISM and CPA Canada. As of TrustCor’s 2021 audit period, PAG does not rely on any third-party specialists or affiliate audit firms.
PAG seems to have only audited TrustCor among CAs. I alas couldn't find a history of the audits: has TrustCor always used PAG? Does TrustCor have a plan to rotate auditors as is consistent with financial best practices?
In Response to the concerns and questions from the researcher’s post as specifically referenced by Kathleen are included in-line below:
In Response to "There is substantial evidence that Measurement Systems and TrustCor are closely related: Both had their domains registered by Vostrom Holdings. (as illustrated in this post by AppCensus on the basis of whois lookups)”:Upon further investigation into our domains and with additional information from our legal team, we have found that TrustCor acquired the DecoyMail system many years ago as the basis of our MsgSafe.io product and service. First available in October 2000 (over 22 years ago), the DecoyMail product (and its successor, our MsgSafe.io) is an incredibly sophisticated and sufficiently complex system with many components. A single component of MsgSafe.io allows domain names to be conveniently purchased through the software’s web interface which triggers a backend domain-registration 'register' mechanism that is pointed to an API or registrar account. In the early days of the long transition and upgrading (porting to a different programming language) of the software from the DecoyMail service to the MsgSafe.io service (which took years), these domains were registered while the software was still pointed to the same registrar account of the previous owner which owned many other domains including others unrelated DecoyMail customer domains and also domains of the registrar account owner. Even still, it was not even a corporate/wholesale account, it was a personal account with a variety of domains held by one of the original DecoyMail shareholders. The platform was not officially relaunched for several years when it was announced as MsgSafe.io as shown here: https://trustcor.com/news/12012016.php. Even after relaunching it, several more years passed before all domains were migrated to the production registrar, DNSimple, and we are not even certain they were all migrated — some DecoyMail users did not transition their accounts fully and some lookalike domains were not identified because they were lookalikes or homoglyphs and not critical to the company branding or functionality.
Are you asserting that the Measurement Systems and TrustCor domains were both registered via Decoy Mail?
In Response to "They have identical corporate officers: Measurement Systems, Trustcor Systems”:This statement is inaccurate because the funding/holding companies in question were already dissolved in 2021. We have explained our restructuring (above) and cannot speak with regard to the other company because we do not know them. It is worth noting that the media's coverage does not indicate who is the beneficial owner of Measurement Systems.
2021 was last year. I can recall events from last year with some degree of reliability. Certainly it's possible to explain who the owners were of the company last year and the transactions that changed it.
The reporting and public records merely indicate that an individual affiliated with a defense company (investor or former employee) may also be an investor in one or both of the funds/holding companies and therefore potentially was at some time an investor in our company through an investment in another company.
Most companies are capable of presenting an accurate list of their stock holders, and reaching through their holding companies if on good terms. Is it not possible to fully explain the ownership of these related companies?
The researchers' conclusions that the journalists further expound are confusing the facts. For example, if it holds that any "investor" in one company (making them an "affiliate" of that company) is also affiliated as an "investor" in another company, links the two companies together as affiliates, and then even when one of those two companies further invests in a third company (one part removed), basically most businesses and even CAs come into question because of the suggested transitive property. Also conflated by the researchers and media is the point about American corporations bearing similar (not exactly the same) names to those of the funds/holding companies in question. We are not now and never have been owned by any American company with any names similar to those pointed out by the researchers. We have no idea what those companies are or what are their purpose, but they are not affiliated with our company or anyone known to us. Our business was formed in Panama over 9 years ago and any paperwork filed in the last few years, pointing to an American or similar-named company was not executed by us or affiliated with us in any way.
In Response to "TrustCor operates the mail encryption product MsgSafe and a beta version of MsgSafe contained the only known unobfuscated version of the spyware SDK. (Beta APK, inspected by Joel and signed by Google)”:Our company never published a production or supported version of the MsgSafe mobile app containing the Measurement Systems SDK. Relative to the tiny population of Beta product-testers (which were largely our own employees) who chose to test a Beta version of the app containing that SDK, I will add that during the development stages of MsgSafe’s BETA mobile app, our developers sought out the help from 3rd party software services to obtain better app analytics. We are aware that they evaluated other SDKs and tools like Firebase, Bugsnag, etc. but they claimed to not help much in troubleshooting and improving the app functionality across all device manufacturers and OS versions. There was a time during this process where they incorporated additional software developers to help with the issues we were facing. Whether or not the SDK was added for a developer’s own financial gain or otherwise is beyond us and we don’t care to speculate. Again, the MsgSafe BETA mobile app was never released in a production supported version and has been abandoned for years, and we can confirm the mobile-first web UI, which is the only supported mobile interface in-use today and for the last few years, which does not contain any SDK from anyone.
This seems to indicate that
* TrustCor operated MsgSafe
* TrustCor did not apply the same standards to MsgSafe development as it would to its core CA services, or did.
In either way the conclusion would be that TrustCor is unable to exert effective control over the development process or is blithe to reputational risks from associated business activity.
In Response to "The MsgSafe product relies in part on SMIME certificates issued by TrustCor (MsgSafe Website)”:
As far as how the MsgSafe mobile app obtained an “unobfuscated version” of the SDK? It is not our place to speculate, but it only makes sense that any company would provide updates to their software over time. The third-party app archive website containing MsgSafe’s APK, as referenced in the researcher’s post, is over 3 years old. It should come as no surprise that the software found there doesn’t match up exactly to the software found in apps they reported about in April 2022. Our developers probably didn’t even notice subtle changes like this because it’s not our practice to reverse engineer other company’s software and violate license agreements.MsgSafe.io is both a product and business, operated separately and independently from TrustCor CA, albeit owned by TrustCor. MsgSafe.io integrates with TrustCor’s S/MIME certificate API for issuance of S/MIME certificates, just like any other CA customer of TrustCor would do. In addition, MsgSafe.io also allows customers to bring their own S/MIME certificates (so not all of MsgSafe user’s certificates are generated by TrustCor CA).
———————————
In Response to Ryan’s (Google) concerns, providing further clarification as requested:
In Response to "Coincidence #1 Audit Irregularities”:TrustCor uses Princeton Audit Group (PAG) as its auditor.
According to CCADB records, PAG does not audit any other publicly-trusted CAs.It is not within our company’s purview to choose which auditors are qualified or accredited to perform the required WebTrust audits. We merely follow the root program and CA/B guidelines and select from the published list. Our founders originally called and spoke with most of the auditors on the published list at the time and have used the same one ever since because as I’m sure you’ve seen with other program members, once you have an auditor it is easier and more cost effective to continue using the same one year after year. The list is published here and as you can see our auditor remains an accredited auditor (PAG was on the list since before our company was founded and still is today). If there is a compelling reason you or any root program manager has to select another auditor, we are certainly open to changing if that is required, and it appears as though the list is now much longer almost ten years after we first had to choose.
Using the same auditor for 10 years, no matter how honest, introduces risks of excessive chumminess and normalization of deviance. I would consider it a reasonable change to CA/B guidelines to require rotation just as SOX does for audits of public companies. However, it is surprising that TrustCor management did not consider this in selection of auditors.
https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/licensed-webtrust-practitioners-international
TrustCor’s most recent audit statements ([Standard] and [BR - TLS]) describe CA operations in Toronto, Ontario, Canada.
PAG is listed as a licensed practitioner only in the USA.
TrustCor’s CPS indicates the data centers are located in Phoenix.
Though the management assertion references Phoenix, PAG’s attestation does not.As you stated, it was included in the management’s assertion and it appears to be a clerical error that PAG’s attestation did not additionally include the location of TrustCor’s data centers specifically, but we did confirm with our auditor that this will be included in PAG's 2022 attestation. In addition, under 5.1.1 Site Location and Construction, of TrustCor’s CPS, we also state that TrustCor CA’s data centers are located in Phoenix, Arizona, USA, which are visited and audited annually.
Beyond [1], [2], and [3], we found little public information specific to audits performed by PAG.It is not within our company’s purview to choose which auditors are qualified or accredited to perform the required WebTrust audits. We merely follow the root program and CA/B guidelines and select from the published list. Our founders originally called and spoke with most of the auditors on the published list at the time and have used the same one ever since because as I’m sure you’ve seen with other program members, once you have an auditor it is easier and more cost effective to continue using the same one year after year. The list is published here and as you can see our auditor remains an accredited auditor (PAG was on the list since before our company was founded and still is today). If there is a compelling reason you or any root program manager has to select another auditor, we are certainly open to changing if that is required, and it appears as though the list is now much longer almost ten years after we first had to choose.
https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/licensed-webtrust-practitioners-international
In Response to "Coincidence #2 WIPO Complaint”:This page summarizes a 2018 complaint filed with the WIPO Arbitration and Mediation Center against Trustcor Systems S. De R.L. by Compagnie Générale des Etablissements Michelin, owner of BFGOODRICH.
The complaint cites concerns related to TrustCor registering bfgoodrichpromotions.net, and the risk of a related phishing scheme resulting from the registration and corresponding email servers configured on the disputed domain name.
Ultimately, the Panel found TrustCor’s passive holding of the disputed domain name indicated “bad faith”. Furthermore, the Panel also found that TrustCor’s failure to respond to the Complainant’s cease-and-desist letters was an additional circumstance evidencing the TrustCor’s “bad faith”.
This type of behavior is consistent with that described by Joel Reardon here (see discussion beginning with “Another strange thing is that whois information lists Wylie Swanson as the registrant for a number of domains that closely mimic other encrypted email products [26]).
We’ve separately confirmed the domain registrations described above were once registered as indicated by Joel.The bfgoodrichpromotions.net complaint was not related to TrustCor CA’s products or services but to MsgSafe.io’s privacy-focused email service. Unfortunately, free or low-cost email service providers are often abused by phishing, ransomware, and other abuse because they lend to privacy and anonymity and how easily bad actors can acquire them. For instance, bfgoodrichpromotions.net was registered by user who signed up for MsgSafe.io's service with, and had their email forwarding to, their Gmail account. In 2018, MsgSafe.io’s support staff indeed failed to handle this event timely due to being overwhelmed by the high volume of abuse happening at that time. As a result, MsgSafe.io implemented several abuse-reducing solutions, dramatically decreasing the success of bad actors on the platform and have since added support team members to respond within a timely manner to all support tickets.To quote Ryan, "TrustCor’s service offering should not be considered a representation of the service, or TrustCor, itself."
Would you care to address the rest of the sentence of Ryan?
I have questions: could you clarify the possible existence of a US entity employing the persons in Phoenix Arizona, and its relation to the entities in Canada and Panama? In general I believe it's unusual for international businesses to directly employ people across borders, and usually set up a local entity wholly owned by the parent to engage in such activities.
—————————————To address Joel’s (University of Calgary/AppCensus) concerns,In Response to: "Along with investigative journalists at the Wall Street Journal, we discovered that Vostrom Holdings is doing business as Packet Forensics [6], a company that sells lawful-intercept products [7].”:We cannot comment on the activity of another company, as any comment would be purely our speculation.
Could you clarify the relationship between Vostrom Holdings and TrustCor, both now and in the past?
In Response to: "The Measurement Systems company was also registered in Virginia [8] by "Raymond Alan Saulino", which was then made inactive when Google took action against the SDK [9].”:We cannot comment on the activity of another company, as any comment would be purely our speculation.In Response to: ""Raymond A Saulino" is also an officer for Packet Forensics International LLC [10], and despite the middle name not being an exact match, they both list the same residential address [11, 12].”:We cannot comment on the activity of another company or individual, as any comment would be purely our speculation.In Response to: "Domains were registered by Vostrom: One of the domains stood out: trustcor.co, which redirected at the time to the TrustCor CA's website. The NS records continue to point to nsX.msgsafe.io [14], the same as trustcor.com itself [15]. Msgsafe is a TrustCor encrypted email product [16].”:Upon further investigation into our domains and with additional information from our legal team, we have found that TrustCor acquired the DecoyMail system many years ago as the basis of our MsgSafe.io product and service. First available in October 2000 (over 22 years ago), the DecoyMail product (and its successor, our MsgSafe.io) is an incredibly sophisticated and sufficiently complex system with many components. A single component of MsgSafe.io allows domain names to be conveniently purchased through the software’s web interface which triggers a backend domain-registration 'register' mechanism that is pointed to an API or registrar account. In the early days of the long transition and upgrading (porting to a different programming language) of the software from the DecoyMail service to the MsgSafe.io service (which took years), these domains were registered while the software was still pointed to the same registrar account of the previous owner which owned many other domains including others unrelated DecoyMail customer domains and also domains of the registrar account owner. Even still, it was not even a corporate/wholesale account, it was a personal account with a variety of domains held by one of the original DecoyMail shareholders. The platform was not officially relaunched for several years when it was announced as MsgSafe.io as shown here: https://trustcor.com/news/12012016.php. Even after relaunching it, several more years passed before all domains were migrated to the production registrar, DNSimple, and we are not even certain they were all migrated — some DecoyMail users did not transition their accounts fully and some lookalike domains were not identified because they were lookalikes or homoglyphs and not critical to the company branding or functionality.All domains registered through msgsafe (such as trustcor.co and also trustcor.com), and any domain brought to msgsafe using the bring-your-own-domain feature would contain msgsafe.io name server records that point to either nsX.msgsafe.io or nsX.dnsimple.com, which are synonymous, hosted at the same IP address, and are operated by DNSimple.In Response to: "Like Measurement Systems, Trustcor is also registered in Panama [17]. They were registered a month apart and they share an identical set of corporate officers”:Unknown until recently by any employee officers of TrustCor we and Measurement Systems S de RL had in common a group of investors who represented funds (groups of companies and other funds), not individuals. Even though we shared a common group of investment funds, we have always operated our business independently of any other company and have exclusion provisions in place to protect the CA business from having access-to or being controlled by or influenced from any third-party, investors, equity-holders, or anyone other than TrustCor’s CA Approving Officials and employees. To the best of our knowledge (and our focused investigation) there is not and has never been shared ownership with any defense company or any USA company. This common group of investors with Measurement Systems S de RL. had already dissolved mid 2021, before these recent claims were publicized, meaning as a natural course of business and not as a reaction to any claims or adverse events. In 2021 TrustCor ownership was transferred from the initial investors/founders to the employees of TrustCor. The legal process has been very step-by-step and very slow, especially due to the protracted treatment and recent death of one key founder, Ian Abramowitz. Nonetheless, it is underway and irreversible, and the common investment vehicle was dissolved over a year ago.
You say "employee officers". What set of corporate officers is this? Why is it relevant to your ability to provide information on the relationship of these entities that the officers in question, who surely realized that they were doing the job at two different companies, were not employees?
In Response to: "One of these officers is Frigate Bay Holding LLC [18]. Shortly after the WSJ article was printed, a "Raymond Saulino" filed paperwork for Frigate Bay Holdings LLC listed as its manager [19]. Raymond Saulino has also spoken to press publicly on behalf of Packet Forensics.”:We are not now, and never have been, owned by any American company with any names similar to those pointed out by the researchers. We have no idea what those companies are or what are their purpose, but they are not affiliated with our company or anyone known to us. Our business was formed in Panama over 9 years ago and any paperwork filed this year was not executed by our company. Our lawyer has instructed us not to point out the subtle differences in names, spelling, dates of incorporation, or legal territories in which corporate entities were formed, as litigation is a potential outcome of this publication.
I understand being from Canada you might not be familiar with US libel law. I suggest you get a lawyer who is before you brandy around threats like this.
In Response to: "Trustcor also talks about their "geo-jurisdiction advantage" on an entire page [21] where they state that "TrustCor is a Panamanian registered company, with technical operations based in Curaçao---one of the most secure, privacy oriented jurisdictions in the world." Despite that, they have job openings for PKI Engineer and Systems Engineering in Phoenix, AZ [22, 23], the latter stating that the applicant "MUST be located near the Phoenix, AZ area - job is remote with occasional trips to data center facilities". Their own audit reports state that they are Canadian, with their data centres in Phoenix, AZ [24]. I am not particularly troubled by where they have their technical operations, but I think that it is strange to omit that the data centres are in Arizona on the lengthy descriptions of the "geo-jurisdiction advantage". Certificate authorities are about trust.”:We find that most CAs don’t publicly disclose the locations of their CA data centre location on the home page of their marketing websites. The aspect of our business which operates the encrypted email product and stores secure customer content, MsgSafe, has technical operations based in Curaçao (hence the "geo-jurisdiction advantage”) whereas the CA business unit has data centers located in Arizona. In the interest of trust and transparency, to be clear, TrustCor’s CA business unit does not perform key escrow services and therefore does not store customer private-keys, as stated in our CPS.
Let me spell out my understanding based on what's been said so far.
TrustCor CA is a company in Canada, wholly owned and operated by TrustCor, an Panamanian company operating in a money laundering haven with weak rule of law. TrustCor also owns MsgSafe, which it operates in Curacao. But TrustCor CA isn't adverse to locating business operations in the US, a country which along with Canada has a functioning and trusted court system. So why exactly should I trust TrustCor with the safety of every site on the Internet? What's wrong with Canada or Arizona? Why Panama?
Together with the reluctance to disclose funding and owners I can think of a few answers to this question, none of which are particularly encouraging for my trust in TrustCor.
In Response to: "I have also tested the Msgsafe encrypted email product in the browser, while saving the resulting traffic using Firefox and Chrome's "save to HAR" file option. I am not convinced there is E2E encryption or that Msgsafe cannot read users’ emails. I see that email contents and attachments are sent plaintext (over TLS) to api.msgsafe.io, even when sending to other Msgsafe users or when using PGP or SMIME to send to non-Msgsafe users. The SMIME cert is sent inbound from the server, and there is no outbound traffic that embodies the public key to be signed. The password is sent plaintext to the server (over TLS) and thus any key derived from that password would also be known by the server. Hanlon’s razor tells me I should not attribute these errors to malice; it could just be a developmental failure [25]. Nevertheless, I think it is reasonable expectation that a root certificate authority can get the crypto right, and so I'm concern regardless of the reason why.”:MsgSafe.io’s platform can be utilized in a number of ways, including using the e-mail forwarding features and not using the web-based interface at all. It is impossible to speculate what you experienced or tested without comprehensive knowledge of the account configuration, forwarding addresses, user identities and contacts, and their associated GPG and S/MIME certificates.As far as you not believing the product is offering adequate encryption capabilities, let me first say that I do not want to drag the names of any other encryption products or services through the mud. To address your concerns, based on our teams exhausted research into many other providers offering similar services, one basic rule applies; whether the encryption or decryption functions are occurring on the client (often in javascript) or on the server, the server is still storing and handling the key material in the process. Our implementation is one of two commonly used by secure messaging services and chosen for a few reasons. If encryption occurs on the client then the key material is passed from the server to the browser over TLS. If the encryption occurs on the server then the message is transferred from the client to the server over TLS, then encrypted. As the MsgSafe website explains, our team has found that implementing the key material and encryption/decryption processing on the server provides security without the additional processing requirement on the client. One of the benefits of this implementation is that it allows slower/older devices (phones) to utilize our mobile-first web experience (since, as we previously mentioned, we abandoned development of a mobile app, which could have done the encryption/decryption process on the mobile phone), while also supporting desktop users. To be clear, at no point is data passed in the clear while using the service, it is either encrypted with the user key material or encrypted with industry-standard TLS.Many MsgSafe.io users never experience sending or receiving mail using the web browser, meaning you’re only looking at one implementation of the service that is probably the least used.Of course we can accept the possibility of a weakness in MsgSafe.io's user interface, we take such reports very seriously, but we would be surprised to find that to be the case here. If you still have questions or doubts, we ask that you please file a bug report with MsgSafe.io directly via their customer support channels.It is also important to note that MsgSafe.io and TrustCor’s CA do not share development resources or infrastructure and are completely different lines of business.In Response to: "Another strange thing is that whois information lists Wylie Swanson as the registrant for a number of domains that closely mimic other encrypted email products [26]. This includes hushemail.net, protonmails.com, and tutanoto.com, which shadow competing services, and which redirect users who visit them to msgsafe.io. Wylie Swanson is the co-founder of Trustcor [27]. In my opinion, it looks like typo squatting and I would not expect that a root certificate authority to be engaged in this kind of behaviour.”:When the domains were registered, it was also common for advertisers to buy Google search keywords of their competitors as part of their SEO marketing.
This is not really relevant to typosquatting.
At the time, it was perceived as a low-cost way for a small start-up e-mail provider to direct a very small amount of traffic to MsgSafe.io’s new privacy-focused email services.
Perceived by who?
It was not an attempt to mislead consumers in any way -- users very clearly understood where they had been directed. It is not the company's stance or best practice to register domain names similar to competitors, only happened with a small number of domains, and did not occur again after 2016.
The redirect is still up as are the registrations. It is 2022, quite some time after 2016.
In Response to: "A final coincidence: one of Msgsafe's email domains is decoymail.com, which Msgsafe users can request and which redirects to msgsafe.io [28]. In 2014 it was registered to VOSTROM Holdings, Inc., while in 2015 it was registered to TRUSTCOR SYSTEMS S. de R.L. [29]. DecoyMail was a company created by Rodney Joffe [30], who is the person who also filed the original registration of Packet Forensics [31] and was still an authorized agent for Packet Forensics in a 2019 filing [32] and a Manager for Packet Forensics in a 2021 filing [33]. The email rjo...@centergate.com is linked to the domains rodneyjoffe.com, packetforensics.com, and decoymail.net [34]. Decoymail.net currently redirects to msgsafe.io.”:It is public information that TrustCor acquired the DecoyMail system many years ago as the basis of our MsgSafe.io product and service. First available in October 2000 (over 22 years ago), the DecoyMail product (and its successor, our MsgSafe.io) is an incredibly sophisticated and sufficiently complex system with many components. A single component of MsgSafe.io allows domain names to be conveniently purchased through the software’s web interface which triggers a backend domain-registration 'register' mechanism that is pointed to an API or registrar account. In the early days of the long transition and upgrading (porting to a different programming language) of the software from the DecoyMail service to the MsgSafe.io service (which took years), these domains were registered while the software was still pointed to the same registrar account of the previous owner which owned many other domains including others unrelated DecoyMail customer domains and also domains of the registrar account owner. Even still, it was not even a corporate/wholesale account, it was a personal account with a variety of domains held by one of the original DecoyMail shareholders. The platform was not officially relaunched for several years when it was announced as MsgSafe.io as shown here: https://trustcor.com/news/12012016.php. Even after relaunching it, several more years passed before all domains were migrated to the production registrar, DNSimple, and we are not even certain they were all migrated — some DecoyMail users did not transition their accounts fully and some lookalike domains were not identified because they were lookalikes or homoglyphs and not critical to the company branding or functionality.—————————————To address Serge’s (Berkely/AppCensus) concerns,In Response to: “Why did MsgSafe appear to bundle an unobfuscated version of this SDK in their app? How was it obtained, if as Rachel says, they have nothing to do with the company that is spreading it? According to her email, they don't have a public app; someone should probably tell that to their social media person…”:Our company never published a production or supported version of the MsgSafe mobile app containing the Measurement Systems SDK. Relative to the tiny population of Beta product-testers (which were largely our own employees) who chose to test a Beta version of the app containing that SDK, I will add that during the development stages of MsgSafe’s BETA mobile app, our developers sought out the help from 3rd party software services to obtain better app analytics. We are aware that they evaluated other SDKs and tools like Firebase, Bugsnag, etc. but they claimed to not help much in troubleshooting and improving the app functionality across all device manufacturers and OS versions. There was a time during this process where they incorporated additional software developers to help with the issues we were facing. Whether or not the SDK was added for a developer’s own financial gain or otherwise is beyond us and we don’t care to speculate. Again, the MsgSafe BETA mobile app was never released in a production supported version and has been abandoned for years, and we can confirm the mobile-first web UI, which is the only supported mobile interface in-use today and for the last few years, which does not contain any SDK from anyone.
As far as how the MsgSafe mobile app obtained an “unobfuscated version” of the SDK? It is not our place to speculate, but it only makes sense that any company would provide updates to their software over time. The third-party app archive website containing MsgSafe’s APK, as referenced in the researcher’s post, is over 3 years old. It should come as no surprise that the software found there doesn’t match up exactly to the software found in apps they reported about in April 2022. Our developers probably didn’t even notice subtle changes like this because it’s not our practice to reverse engineer other company’s software and violate license agreements.
Finally let me note that the general evasiveness, thinly veiled legal threats, and contemptuous attitude this entire email contains have convinced me that TrustCor does not have the appropriate attitude for a CA. Rather than openly share information to assuage the community and rebuild that most precious and delicate material of human relations, trust, Rachel has chosen to obfuscate, feign ignorance and give partial answers to some very serious questions.
Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim
Prof. Reardon
Nov 18, 2022, 7:59:52 PM11/18/22
to dev-secur...@mozilla.org, watso...@gmail.com, MDSP, cli...@apple.com, ryand...@google.com, kwi...@mozilla.com, Prof. Reardon, ege...@cs.berkeley.edu, rac...@trustcor.ca
Hello:
I want to thank TrustCor for their detailed response and for taking my concerns
seriously, as well as the cordial tone of their response. Please correct me if I
am wrong, but from my understanding there appears to be nothing in what I
presented to this forum that is being disputed as incorrect or imagined.
TrustCor holds that some of what I presented is stale or no longer accurate
information, and some is considered irrelevant information or a coincidence. I
infer from this that TrustCor generally agrees with me that concerns that I
raised were indeed legitimate and worth the attention and scrutiny of this
community. Please correct me if this is not the case.
Thanks,
Joel Reardon
I want to thank TrustCor for their detailed response and for taking my concerns
seriously, as well as the cordial tone of their response. Please correct me if I
am wrong, but from my understanding there appears to be nothing in what I
presented to this forum that is being disputed as incorrect or imagined.
TrustCor holds that some of what I presented is stale or no longer accurate
information, and some is considered irrelevant information or a coincidence. I
infer from this that TrustCor generally agrees with me that concerns that I
raised were indeed legitimate and worth the attention and scrutiny of this
community. Please correct me if this is not the case.
Thanks,
Joel Reardon
Prof. Reardon
Nov 18, 2022, 10:03:44 PM11/18/22
to dev-secur...@mozilla.org, Prof. Reardon, watso...@gmail.com, MDSP, cli...@apple.com, ryand...@google.com, kwi...@mozilla.com, ege...@cs.berkeley.edu, rac...@trustcor.ca
Hello again:
"One of these officers is Frigate Bay Holding LLC [18]. Shortly after
the WSJ article was printed, a "Raymond Saulino" filed paperwork for Frigate Bay
Holdings LLC listed as its manager [19]"
"One of these officers is Frigate Bay Holding LLC [17]. Shortly after
the WSJ article was printed, a "Raymond Saulino" filed paperwork for Frigate Bay
Holdings LLC [18] listed as its manager [19]"
registered a month apart and they share an identical set of corporate officers
the WSJ article was printed, a "Raymond Saulino" filed paperwork for Frigate Bay
publicly on behalf of Packet Forensics in the context of a Wired article about
subverting SSL [20].
I must make a very important correction to the citations and their juxtaposition in the origin posting. In writing:
the WSJ article was printed, a "Raymond Saulino" filed paperwork for Frigate Bay
Holdings LLC listed as its manager [19]"
I had meant to write:
"One of these officers is Frigate Bay Holding LLC [17]. Shortly after
the WSJ article was printed, a "Raymond Saulino" filed paperwork for Frigate Bay
I have attached the original file, the corrected file, and a diff.
Joel Reardon
diff:
@@ -31,9 +31,9 @@ Like Measurement Systems, Trustcor is also registered in Panama [17]. They were
registered a month apart and they share an identical set of corporate officers
(cf. [1]). It is my understanding that these officers only are involved in three
companies, so it does not appear that they register, e.g., many companies in
companies, so it does not appear that they register, e.g., many companies in
-Panama. One of these officers is Frigate Bay Holding LLC [18]. Shortly after
+Panama. One of these officers is Frigate Bay Holding LLC [17]. Shortly after
+Panama. One of these officers is Frigate Bay Holding LLC [17]. Shortly after
the WSJ article was printed, a "Raymond Saulino" filed paperwork for Frigate Bay
-Holdings LLC listed as its manager [19]. Raymond Saulino has also spoken to press
+Holdings LLC [18] listed as its manager [19]. Raymond Saulino has also spoken to press
+Holdings LLC [18] listed as its manager [19]. Raymond Saulino has also spoken to press
publicly on behalf of Packet Forensics in the context of a Wired article about
subverting SSL [20].
Prof. Reardon
Nov 20, 2022, 11:54:21 AM11/20/22
to dev-secur...@mozilla.org, Prof. Reardon, watso...@gmail.com, MDSP, cli...@apple.com, ryand...@google.com, kwi...@mozilla.com, ege...@cs.berkeley.edu, rac...@trustcor.ca
I have listed a few of the public audits I have found here [1], and Mozilla
also has them listed here [2]. What I've found is that in the standard and BR
audits for 2018, 2019, 2020, and 2021, as well as the code signing audits for
2020 and 2021, their auditor consistently describe the CA's "Certification
Authority (CA) operations at Toronto, Ontario, Canada". According to what I've
learned from this thread (please correct me if I am wrong) TrustCor was not a
Canadian company during this time and did not have an office in Canada.
This is ten different audits over four years.
Regarding the SDK, I agree that speculating why it was included is neither
useful nor helpful. It may still be possible to get a better understanding of
how it was included. For example, source code version control history and
commit messages may give some context. According to reporting by the Wall
Street Journal who interviewed app makers who included this SDK that
"Several developers said Measurement Systems required them to sign
nondisclosure agreements." [3] As well, the code is not available for download but
was send to developers who agreed to include it. This was indeed some years ago,
and I agree that the means of delivery, etc., may have changed. Nevertheless
if such emails or other communications are available to you it may help
elucidate the context around how this SDK was obtained.
[1] https://pages.cpsc.ucalgary.ca/~joel.reardon/trustcor/
[2]