concerns about Trustcor
49,480 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] https://bugzilla.mozilla.org/show_bug.cgi?id=1801504
[3] https://archive.ph/AuNOy
Serge Egelman
Nov 20, 2022, 5:56:19 PM11/20/22
to Prof. Reardon, dev-secur...@mozilla.org, watso...@gmail.com, cli...@apple.com, ryand...@google.com, kwi...@mozilla.com, rac...@trustcor.ca
Given that it is not yet explained how the only known unobfuscated version of Measurement Systems' SDK made it into the MsgSafe app, I decided to spend a little bit more time exploring it. (Again, as background, this is an SDK that was found in MsgSafe's public beta of their Android app, which appeared to be available in the Play Store up until earlier this year.)
In the obfuscated version of the SDK, many string constants were encrypted and decrypted at runtime. However, in the version I found in MsgSafe's app, you can simply grep for all strings and skim over the <1000 that are returned. There are exactly two files within the SDK that appear to contain base64-encoded strings (whereas all remaining strings are in natural language):
- Within coelib/c/couluslibrary/plugin/AK.smali:
const-string v0, "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tDQpNSUlGclRDQ0E1VUNBaHJpTUEwR0NTcUdTSWIzRFFFQkN3VUFNSUdiTVFzd0NRWURWUVFHRXdKRFZ6RVRNQkVHDQpBMVVFQ0F3S1EzVnlZY09Ed3FkaGJ6RVRNQkVHQTFVRUJ3d0tWMmxzYkdWdGMzUmhaREVRTUE0R0ExVUVDZ3dIDQpUWE5uVTJGbVpURVRNQkVHQTFVRUN3d0tUM0JsY21GMGFXOXVjekVYTUJVR0ExVUVBd3dPWVc0eExtMXpaM05oDQpabVV1YVc4eElqQWdCZ2txaGtpRzl3MEJDUUVXRTNObFkzVnlhWFI1UUcxelozTmhabVV1YVc4d0hoY05NVGN4DQpNREV5TVRneU9ERXdXaGNOTWpJeE1qSXdNVGd5T0RFd1dqQ0JtekVMTUFrR0ExVUVCaE1DUTFjeEV6QVJCZ05WDQpCQWdNQ2tOMWNtSERnOEtuWVc4eEV6QVJCZ05WQkFjTUNsZHBiR3hsYlhOMFlXUXhFREFPQmdOVkJBb01CMDF6DQpaMU5oWm1VeEV6QVJCZ05WQkFzTUNrOXdaWEpoZEdsdmJuTXhGekFWQmdOVkJBTU1EbUZ1TVM1dGMyZHpZV1psDQpMbWx2TVNJd0lBWUpLb1pJaHZjTkFRa0JGaE56WldOMWNtbDBlVUJ0YzJkellXWmxMbWx2TUlJQ0lqQU5CZ2txDQpoa2lHOXcwQkFRRUZBQU9DQWc4QU1JSUNDZ0tDQWdFQXljcGFxN2R6S3I0UldJZjdMOW00WUlWWlRBTFBqN0VlDQpZMGJmOUJWMmtoa08xVm55RWx4Nm5mM2lDUGhUTVYwSVV2T2JFVnoxYlIvaU1CejRuWWVZSFdWdGxDZm0vZmxIDQpEZmszSmZvVmdwdU0xeFpsdCsrT0xtSmVkdnhCRFE3amo1KzVyeUl0WWt5TnRTYlUvb2w5OCtaanovc0pnVkNoDQpvclY0QnZReXc5TzRVR2Y3ckxOQ1NyUlBZelVpU1FHVFRFUVlqMjJwZ0k4Y0RJTC8ydDVtenpWUFo0WmMvYkkwDQpZeE9UL3pyNkJrQTNWcS9EVE5NQ1VPMTVJZUpMUm9aQTJwZ2tXYjVuOUk5MEZPUDZwSkNMTkZnS3Z2V0pqdlFPDQpBRFAwS2JnMGNncTYvSTJaWFptcnU3Z0lMbDQ4SEZNRlVCS1FSS1pQTGRXRUVEUjVtdkw1Z0tPZ2t6bTFSbGVCDQo0bHdHUkxURkhzUSt6Q1Z2cUpidUlIbVU1bkx2ZVF3YVpYU2l2V2NCNWMwTmhlZkhYbHVnRno3aVBCWXRmaTFrDQpIelI4SWRyc1pPazg1a0dYMGI2RExxWUtOc2duK01hU1JpRnpQeXBKY0tRcjhFSW1CcGxBUFpuV2MwbHdEUXg5DQpvZjA1dEh4OTRLVzNqZlN0R0o3ZUZmb1RTQVllaVdsSmR5OVdiYkdIT1FKQnBmbzgyZzRza3RHbjBiSSt2NzJO"
return-object v0
.end method
.method sm()Ljava/lang/String;
.locals 1
const-string v0, "UmM1NUg4VWdaUFF2aytDYVg1dzByVmQ4SjJKNFlQU0d3ejh6MlpTTEhMRHFFOWZWczlsc0pTajlZMWp3bGhsYg0KRjJHSHA1QlIxQWR5RlJaSjhSVHI2aDlhZU5WN2FMd256MjIvbkc5UjRWSG5XaTFzWU9uK1RjeWZjRXlGZXhTbw0KRWlkbitqK0RGL3NDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FnRUF2YVRNN0YyNEVJbHpSSlc4bktwOA0KdndqWkg0eGtEWnpTTHlWbXhSOG5uQitFS2F1ekI4S0RMVUNjSjRoaDJoRnFrbUR3UHFweGQ4TkcwLzl1V1NNNg0KTDExSjhqUlRMb1o2N2hPYTJhWm9KQTNuM21zTWt4UExYVy94bXdwbnN2RlQ1RkQ3L1M4OW1UM2E0RThrVXRTMA0KYjZYbmMrZFdiOE9MRDhQRm9rZ0FUOVRld1lySkNsSklaenA4QWsvSjRBQXFUc3pjeVUyL1l0TVhCSlQ2UzVIWg0KdmR6bmQwTnlvdEN3TG1zUXZodmNiK3BIZ3JyYjlkdVNudFVaWUlacEtvaFFGSlVMaW1TMmNsLzVtN3FPSXpCUg0KZStBY3haRDYwTVBrSnE0ejdHZU9vWFRQaHFMblBmU3VRR21EdDd4UFFNOHZ5NzZOSG5GTHZyMEFvTng2S1RVbw0KNWp2UmVsL3pJOGxpVE9sd1MwVnF4dVF1eHJBTWc3OHhhOWVJNFhlclZIQjlkblJPQkFTdFRaZFZab0xudmR5Uw0KR1V6bUZDbGZ2WjFOSnA3TDdTM1dETjNMQ0dFcHZWTUhyMlFsMjhwL2tYamdHTy9CcENPTTQ0SHhuQkJXbTlyWg0Kd1kzZjNYcFgvWkZpOUI0eUdMV2pHN3lQV2NvRTJSdVhvaGwxOHhvZDZpaFNtNVNQdXd1MmtjemszVVRQUDEzWA0KOGRJZXAzdklMajdIUUFHcFRxWUJ2N0QxWXUvRHA2WmhQdWNlOFAzRmVmcHdYQjA3aDZlS1BxN3V0TFBuQ2gySg0KZ0ttMjJNc0h5K1JPUG41L0FtWGtZd3B5cDQyVE5XcDZvQ3FLOTBZSnYzTUl6RE9BVnFjZ0JicHVwZUF4Qmt1VQ0KWkJyU2NRU29wOHVLQmY4Q2RFVmR0WG89DQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tDQo="
If you concatenate these two strings together and base64 decode them, you get a certificate:
-----BEGIN CERTIFICATE-----
MIIFrTCCA5UCAhriMA0GCSqGSIb3DQEBCwUAMIGbMQswCQYDVQQGEwJDVzETMBEG
A1UECAwKQ3VyYcODwqdhbzETMBEGA1UEBwwKV2lsbGVtc3RhZDEQMA4GA1UECgwH
TXNnU2FmZTETMBEGA1UECwwKT3BlcmF0aW9uczEXMBUGA1UEAwwOYW4xLm1zZ3Nh
ZmUuaW8xIjAgBgkqhkiG9w0BCQEWE3NlY3VyaXR5QG1zZ3NhZmUuaW8wHhcNMTcx
MDEyMTgyODEwWhcNMjIxMjIwMTgyODEwWjCBmzELMAkGA1UEBhMCQ1cxEzARBgNV
BAgMCkN1cmHDg8KnYW8xEzARBgNVBAcMCldpbGxlbXN0YWQxEDAOBgNVBAoMB01z
Z1NhZmUxEzARBgNVBAsMCk9wZXJhdGlvbnMxFzAVBgNVBAMMDmFuMS5tc2dzYWZl
LmlvMSIwIAYJKoZIhvcNAQkBFhNzZWN1cml0eUBtc2dzYWZlLmlvMIICIjANBgkq
hkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAycpaq7dzKr4RWIf7L9m4YIVZTALPj7Ee
Y0bf9BV2khkO1VnyElx6nf3iCPhTMV0IUvObEVz1bR/iMBz4nYeYHWVtlCfm/flH
Dfk3JfoVgpuM1xZlt++OLmJedvxBDQ7jj5+5ryItYkyNtSbU/ol98+Zjz/sJgVCh
orV4BvQyw9O4UGf7rLNCSrRPYzUiSQGTTEQYj22pgI8cDIL/2t5mzzVPZ4Zc/bI0
YxOT/zr6BkA3Vq/DTNMCUO15IeJLRoZA2pgkWb5n9I90FOP6pJCLNFgKvvWJjvQO
ADP0Kbg0cgq6/I2ZXZmru7gILl48HFMFUBKQRKZPLdWEEDR5mvL5gKOgkzm1RleB
4lwGRLTFHsQ+zCVvqJbuIHmU5nLveQwaZXSivWcB5c0NhefHXlugFz7iPBYtfi1k
HzR8IdrsZOk85kGX0b6DLqYKNsgn+MaSRiFzPypJcKQr8EImBplAPZnWc0lwDQx9
of05tHx94KW3jfStGJ7eFfoTSAYeiWlJdy9WbbGHOQJBpfo82g4sktGn0bI+v72NRc55H8UgZPQvk+CaX5w0rVd8J2J4YPSGwz8z2ZSLHLDqE9fVs9lsJSj9Y1jwlhlb
F2GHp5BR1AdyFRZJ8RTr6h9aeNV7aLwnz22/nG9R4VHnWi1sYOn+TcyfcEyFexSo
Eidn+j+DF/sCAwEAATANBgkqhkiG9w0BAQsFAAOCAgEAvaTM7F24EIlzRJW8nKp8
vwjZH4xkDZzSLyVmxR8nnB+EKauzB8KDLUCcJ4hh2hFqkmDwPqpxd8NG0/9uWSM6
L11J8jRTLoZ67hOa2aZoJA3n3msMkxPLXW/xmwpnsvFT5FD7/S89mT3a4E8kUtS0
b6Xnc+dWb8OLD8PFokgAT9TewYrJClJIZzp8Ak/J4AAqTszcyU2/YtMXBJT6S5HZ
vdznd0NyotCwLmsQvhvcb+pHgrrb9duSntUZYIZpKohQFJULimS2cl/5m7qOIzBR
e+AcxZD60MPkJq4z7GeOoXTPhqLnPfSuQGmDt7xPQM8vy76NHnFLvr0AoNx6KTUo
5jvRel/zI8liTOlwS0VqxuQuxrAMg78xa9eI4XerVHB9dnROBAStTZdVZoLnvdyS
GUzmFClfvZ1NJp7L7S3WDN3LCGEpvVMHr2Ql28p/kXjgGO/BpCOM44HxnBBWm9rZ
wY3f3XpX/ZFi9B4yGLWjG7yPWcoE2RuXohl18xod6ihSm5SPuwu2kczk3UTPP13X
8dIep3vILj7HQAGpTqYBv7D1Yu/Dp6ZhPuce8P3FefpwXB07h6eKPq7utLPnCh2J
gKm22MsHy+ROPn5/AmXkYwpyp42TNWp6oCqK90YJv3MIzDOAVqcgBbpupeAxBkuU
ZBrScQSop8uKBf8CdEVdtXo=
-----END CERTIFICATE-----
This certificate was issued by/to MsgSafe (it appears to be self-signed) and corresponds to an1.msgsafe.io. My presumption is that this is being used for certificate pinning. But it begs the question, why is a MsgSafe certificate hardcoded within Measurement Systems' SDK? This is, after all, compiled code presumably written by Measurement Systems and provided to MsgSafe.
- Within coelib/c/couluslibrary/plugin/En.smali:
const-string v0, "Z3NhZmUuaW8vc3VydmV5Lw=="
return-object v0
.end method
.method m()Ljava/lang/String;
.locals 1
const-string v0, "aHR0cHM6Ly9hbjEubXM="
The URL above is one of only three URLs that we've found hardcoded in this SDK (the other, "nav.telematicsdirect.com" and "nav2.telematicsdirect.com", appear to be used to identify the phone's public-facing IP). Both of the telematicsdirect.com hostnames were present in the obfuscated version of the SDK found in other apps. However, comparing the section of code where MsgSafe's URL was found, the obfuscated version of the SDK had a different URL: https://mobile.measurelib.com/surveyAs before, if you base64 decode these two strings, you get "gsafe.io/survey/" and "https://an1.ms", respectively. Concatenated, it yields the following URL: https://an1.msgsafe.io/survey/
This URL was the API endpoint to which the malware SDK was transmitting sensitive user information! Yet in the version of the SDK found in MsgSafe's app, the only known unobfuscated version of the SDK, it appears to be programmed to instead send data to MsgSafe's own servers! Why are MsgSafe's servers hardcoded to receive data from Measurement Systems' SDK? I'm talking about compiled code that was almost certainly written by Measurement Systems.
Thanks,
serge
--
/*
Serge Egelman, Ph.D.
Serge Egelman, Ph.D.
Research Director, Usable Security & Privacy
International Computer Science Institute (ICSI)
Research Scientist, Electrical Engineering and Computer Sciences (EECS)
University of California, Berkeley
*/
Rachel McPherson
Nov 21, 2022, 11:11:37 AM11/21/22
to MDSP, Clint Wilson, Ryan Dickson, Kathleen Wilson, joel.r...@ucalgary.ca, Serge Egelman
Kathleen, Ryan, Clint and the rest of the community:
Again, we appreciate the opportunity to respond to these concerns.
Readers should take care to read our previous response (first) and all attachments in order to understand the full context of all subsequent replies and our subsequent responses.
As before, 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, and the universities for which they work (University of California, Berkeley and the University of Calgary, respectively).
Again as a blanket statement, 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 discrete business units.
In reading related reporting and blogging off-list, I need to address an elephant in the room. Apparently it may also come as a surprise to some readers that other root program members are in fact international governments, and some are also defense companies, or companies who are wholly-owned by defense companies and/or state-owned enterprises, meaning "businesses" that are completely owned or controlled by governments. Further, some of those governments are not free/democratic and in fact some have histories of tragic human rights violations. We are none of those things and our company does not identify with those values.
I will respond below to the additional questions raised by the researchers.
—————————————
In Response to Joel’s (University of Calgary/AppCensus) supplemental concerns,
In Response to "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." and "… generally agrees with me that concerns that I raised were indeed legitimate and worth the attention and scrutiny of this community.":
Professionally speaking we are obliged to respond that there are aspects of what Joel has stated both in his report and in his supplemental statements with which we disagree, would dispute or are factually inaccurate. We cannot ignore a blanket statement designed to confirm our assent, of which there were several of these. However, now that I’ve made this point in response I won’t expound unnecessarily in this forum in favour of responding constructively to Joel’s supplemental points assuming they are of interest to the greater community.In Response to "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.":
Prior context:
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.
Supplemental response:
Quoted from the WebTrust Illustrative Examination Reports Under SSAE 18 and SSAE 21, Version 2.0 Published 1 February 2022.
"All reports issued should list the state/province, and country of all physical locations of CA facilities that were included in the scope of the engagement. CA facilities may include data centre locations (primary and alternate sites), registration authority locations (for registration authority operations performed by the CA), and all other locations where general IT and business process controls that are relevant to CA operations in scope (including cloud and remote locations)."
Based on the requirements coming directly from WebTrust, we believe we are reporting correctly inside the managements assertions. It still remains true that a good portion of our business process controls, relevant to the CA operations, are conducted by key personnel from Canada. As previously stated, we have always disclosed both our Canadian and United States locations in our CPS document and management assertions.
In Response to "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.":
Prior context:
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.
Supplemental response:
Prior to my original reply, we had already completed an investigation related to this activity. Our software revision control system revealed immediately when the software was introduced and which developer introduced it. As I had previously stated, "… they incorporated additional software developers to help with the issues we were facing." The additional developers were contract developers. Also as I previously stated, "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." Our investigation found the developer in question properly signed our standard "Confidentiality Obligation and Invention Agreement” that requires any developer to obtain a corporate license to any 3rd party software or intellectual property the developer chooses to include. We confirmed through corporate records and email searches that no such agreement was ever obtained by the company or company counsel. Also, none was included inside the software/check-in to revision control. We also confirmed no approval for including this third-party software was ever obtained from Wylie (technically the manager of the developers at that time). Technically that individual developer violated our Confidentiality Obligation and Invention Agreement.
When we discussed this with legal counsel, their opinion that a labor dispute over an agreement violation that took place over 3 years ago would be limited/difficult to pursue, especially since the developer has not worked for the company in 3 years since native app development was abandoned in favor of our decision to focus on our mobile-first web application, which involves completely-different skillsets / personnel. Further, their opinion was that damages might not be readily provable because (as previously stated) the mobile app was never "released" or rather it was only provided for testing in a BETA form (that specifically admonished it was a beta and not supported) and used primarily by our own employees testing it. I realize the existence or proposition of this basically-unused beta software may have been a boon to AppCensus reporting and is of intellectual interest to the researchers, but our company sees no benefit to any legal or other pursuit with regard to benefitting our customers, or any relying parties.
(more to come on this topic below in response to Serge)
—————————————
In Response to Serge’s (Berkely/AppCensus) supplemental concerns,
In Response to "… I decided to spend a little bit more time exploring it … [many lines of technical details] … This certificate was issued by/to MsgSafe (it appears to be self-signed)":
Prior context:
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 "… it appears to be programmed to instead send data to MsgSafe's own servers! Why are MsgSafe's servers hardcoded to receive data from Measurement Systems' SDK?":Supplemental response:
Yes, we agree this certificate you found embedded inside that software / SDK appears to be for "an1.msgsafe.io" and that it was NOT issued by TrustCor CA — it appears to be self-signed by either the developer who added it, or more likely the author of the actual SDK. This is a strong indication TrustCor CA was not involved in the software / SDK. Given a legitimately-signed certificate could have been integrated by MsgSafe.io’s own development team who could easily request it from TrustCor’s CA team, it certainly is evidence that the TrustCor Certificate Authority was not involved in this piece of software or its temporary addition to MsgSafe.io. Further, it indicates this is likely an act of an individual developer, and not even the MsgSafe.io team being duped. We looked at all the URLs you provided in your supplement and can confirm TrustCor CA has not issued any of those certificates at any time, and those URLs are not otherwise known to us.
We had previously performed a forensic investigation of the an1.msgsafe.io hostname you found, along with its IP address history and the host itself, in addition to the certificate search (which again came up blank since it was not issued by TrustCor CA or any legitimate CA so far as we could tell). The hostname you mentioned pointed to a Linux VM that had been provisioned by the same developer we discussed. We were able to recover from backup a copy of this VM and forensically analyze it. The only user was a generic administration account (presumably known by the developer) and the only customization beyond any standard VM configuration was a firewall configuration and the open port 443 that accepted traffic from anywhere. The only listener attached to port tcp/443 was a proxy program which appears to be this: https://github.com/kklis/proxy The only version of the VM we were able to retrieve had no customizations to the configuration file, but it was set up using "systemd" so our conclusion was that the developer was likely redirecting the actual TCP stream somewhere else/offsite, and we confirmed the firewall configuration both on the host itself and the upstream router as far as the egress ACL/filter would have allowed this so long as he was sending it to any of tcp/443, tcp/8080, tcp/8181 or a few others. There is no indication the developer was "hosting" anything at MsgSafe.io beyond a simple redirector designed to send it somewhere else. There was no web server on this system and no certificates, so it was being redirected at the TCP level.This above disagrees with your statement "… MsgSafe's servers hardcoded to receive data ..." where you intimate that our company is receiving the data. A proper characterization would be that a developer had set up a TCP proxy to reflect data somewhere else, but not necessarily to receive it. What you wrote is at best a mischaracterization, or potentially another false claim as it may be forensically proven to be false.
Thank you all,
Kathleen Wilson
Nov 22, 2022, 5:02:16 PM11/22/22
to dev-secur...@mozilla.org, rac...@trustcor.ca
All,
The discussion thus far is appreciated and has been both informative and constructive. My post on November 8 indicated that if our concerns have not been resolved by today (November 22) and further investigation and discussion is still needed, that we would set the “Distrust for TLS After Date” and “Distrust for S/MIME After Date” to November 29, 2022, for the 3 TrustCor root certificates. However, we’d like to allow more time for any additional dialogue or external developments to transpire prior to sharing our intended course of action. We will continue our assessment and share out necessary next steps on Wednesday, November 30.
Thanks,
Kathleen
The discussion thus far is appreciated and has been both informative and constructive. My post on November 8 indicated that if our concerns have not been resolved by today (November 22) and further investigation and discussion is still needed, that we would set the “Distrust for TLS After Date” and “Distrust for S/MIME After Date” to November 29, 2022, for the 3 TrustCor root certificates. However, we’d like to allow more time for any additional dialogue or external developments to transpire prior to sharing our intended course of action. We will continue our assessment and share out necessary next steps on Wednesday, November 30.
Thanks,
Kathleen
Prof. Reardon
Nov 22, 2022, 5:57:46 PM11/22/22
to dev-secur...@mozilla.org, kwi...@mozilla.com, rac...@trustcor.ca
Hello:
Thanks again for your answers to my questions and echoing Kathleen I also
appreciate the discussion.
I just wanted to maybe summarize a bit of what I've learned from this so far so we
can make sure I haven't misunderstood anything and let TrustCor correct
anything I'm mistaken about both for me and the community. Thus this list that
follows should be interpreted as "is it correct to say that ... ?", not
claims that I am asserting.
(i) The Panama open corporate records were accurate in 2020 and earlier, but at
some point in 2021 have changed. The partners were CHIVALRIC HOLDING COMPANY,
LLC and FRIGATE BAY HOLDING, LLC. These are registered in Panama.
(ii) These companies are also partners for Measurement Systems S. De R. L.
(iii) The CHIVALRIC HOLDING COMPANY, LLC has no relation to the Chivalric Holding
Company LLC registered in New Mexico formed Sept 2020 dissolved June 2022 with
officer Vito Piacente, unless the relation is due to an attack against TrustCor.
(iv) The FRIGATE BAY HOLDING, LLC has no relation to Frigate Bay Holdings LLC
(the latter having an "s" in holdings and no comma) registered in Wyoming formed
Sept 2020 dissolved June 2022 with officer Vito Piacente and manager Raymond
Saulino, again unless the relation is due to an attack against TrustCor.
(v) Software produced by Measurement Systems was inserted by a rogue developer
into the Msgsafe app and that developer operated outside their authorization;
this inclusion was not sanctioned.
(vi) The Msgsafe website is implemented where the key material and
PGP/SMIME encryption/decryption processing is performed on Msgsafe servers, with
industry standard TLS used to secure the connection from the browser to Msgsafe
servers.
(vii) Typosquatting was done intentionally for similar email products, encrypted
and otherwise, in 2016. But this was not done maliciously and no users were
intentionally mislead about where they ended up.
(viii) TrustCor is not a Canadian company, in that the TrustCor CA does not have
any company in Canada, filings in Canada, etc.
Again, these are how I'm interpreting TrustCor's response and I could very well
be wrong, so please let me know.
I have a few more follow up questions:
(q1) The TrustCor website as I visit it now from my office at the University of
Calgary states that: "TrustCor is a Panamanian registered company, with technical
operations in one of the most secure, privacy oriented jurisdictions in the
world. Traditional safe havens do not even come close to the protection offered
by Curaçao's strict privacy laws." It does not actually say that technical
operations are in Curacao, but that is how I had interpreted it. Assuming
(q2) This website:
https://www.dnb.com/business-directory/company-profiles.measurement_systems_s_de_rl.fe1d33ee8c1ff9a19bcc9c5b877cb483.html
refers to Measurement Systems S de RL having as key principal Ryan Abramowitz. I
haven't used dnb.com before, I have absolutely no idea where they source their
data or if their data is any good. There is also no certainty that the Ryan
Abramowitz is the same as the Ryan Abramowitz who is the co-founder's son. But
it returns back to this theme of coincidences. So I guess as clarifications: did
TrustCor's founder Ian Abramowitz or his son Ryan Abramowitz ever act as a
representative for Measurement Systems or for its partners, namely CHIVALRIC
HOLDING COMPANY, LLC and FRIGATE BAY HOLDING, LLC? (the Panama ones, not the
copycat US ones)
(q3) Is there any risk that the rogue developer could have compromised TrustCor
in any other way other than running unauthorized TCP relays and getting
unauthorized code committed? How and when were these actions detected and are
they referenced in any audit?
(q4) In what countries is TrustCor a legal entity?
Thanks again,
Joel Reardon, University of Calgary
Thanks again for your answers to my questions and echoing Kathleen I also
appreciate the discussion.
I just wanted to maybe summarize a bit of what I've learned from this so far so we
can make sure I haven't misunderstood anything and let TrustCor correct
anything I'm mistaken about both for me and the community. Thus this list that
follows should be interpreted as "is it correct to say that ... ?", not
claims that I am asserting.
(i) The Panama open corporate records were accurate in 2020 and earlier, but at
some point in 2021 have changed. The partners were CHIVALRIC HOLDING COMPANY,
LLC and FRIGATE BAY HOLDING, LLC. These are registered in Panama.
(ii) These companies are also partners for Measurement Systems S. De R. L.
(iii) The CHIVALRIC HOLDING COMPANY, LLC has no relation to the Chivalric Holding
Company LLC registered in New Mexico formed Sept 2020 dissolved June 2022 with
officer Vito Piacente, unless the relation is due to an attack against TrustCor.
(iv) The FRIGATE BAY HOLDING, LLC has no relation to Frigate Bay Holdings LLC
(the latter having an "s" in holdings and no comma) registered in Wyoming formed
Sept 2020 dissolved June 2022 with officer Vito Piacente and manager Raymond
Saulino, again unless the relation is due to an attack against TrustCor.
(v) Software produced by Measurement Systems was inserted by a rogue developer
into the Msgsafe app and that developer operated outside their authorization;
this inclusion was not sanctioned.
(vi) The Msgsafe website is implemented where the key material and
PGP/SMIME encryption/decryption processing is performed on Msgsafe servers, with
industry standard TLS used to secure the connection from the browser to Msgsafe
servers.
(vii) Typosquatting was done intentionally for similar email products, encrypted
and otherwise, in 2016. But this was not done maliciously and no users were
intentionally mislead about where they ended up.
(viii) TrustCor is not a Canadian company, in that the TrustCor CA does not have
any company in Canada, filings in Canada, etc.
Again, these are how I'm interpreting TrustCor's response and I could very well
be wrong, so please let me know.
I have a few more follow up questions:
(q1) The TrustCor website as I visit it now from my office at the University of
Calgary states that: "TrustCor is a Panamanian registered company, with technical
operations in one of the most secure, privacy oriented jurisdictions in the
world. Traditional safe havens do not even come close to the protection offered
by Curaçao's strict privacy laws." It does not actually say that technical
operations are in Curacao, but that is how I had interpreted it. Assuming
the privacy oriented jurisdiction being referenced by the paragraph is Arizona,
why is Curacao part of that paragraph? Note this is TrustCor's website, not Msgsafe.
(q2) This website:
https://www.dnb.com/business-directory/company-profiles.measurement_systems_s_de_rl.fe1d33ee8c1ff9a19bcc9c5b877cb483.html
refers to Measurement Systems S de RL having as key principal Ryan Abramowitz. I
haven't used dnb.com before, I have absolutely no idea where they source their
data or if their data is any good. There is also no certainty that the Ryan
Abramowitz is the same as the Ryan Abramowitz who is the co-founder's son. But
it returns back to this theme of coincidences. So I guess as clarifications: did
TrustCor's founder Ian Abramowitz or his son Ryan Abramowitz ever act as a
representative for Measurement Systems or for its partners, namely CHIVALRIC
HOLDING COMPANY, LLC and FRIGATE BAY HOLDING, LLC? (the Panama ones, not the
copycat US ones)
(q3) Is there any risk that the rogue developer could have compromised TrustCor
in any other way other than running unauthorized TCP relays and getting
unauthorized code committed? How and when were these actions detected and are
they referenced in any audit?
(q4) In what countries is TrustCor a legal entity?
Thanks again,
Joel Reardon, University of Calgary
Rachel McPherson
Nov 26, 2022, 9:14:36 PM11/26/22
to MDSP, Kathleen Wilson, Ryan Dickson, Clint Wilson
Kathleen, Ryan, Clint and the rest of the community:
Again, we appreciate the opportunity to respond to the community's concerns.
Readers should take care to read our several previous responses (first) and all attachments in order to understand the full context of all subsequent replies and our subsequent responses. Then, please refer-back to our November 8, 2022 post entitled "False Claims and Media," for the full story.
Readers should take care to read our several previous responses (first) and all attachments in order to understand the full context of all subsequent replies and our subsequent responses. Then, please refer-back to our November 8, 2022 post entitled "False Claims and Media," for the full story.
As before, 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.io (the email service). I will use "the researchers" when speaking about Serge Edelman, Joel Reardon, their commercial enterprise AppCensus, and 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 two separately-managed businesses: a certificate authority (TrustCor CA) as a business unit which provides CA services protected and insulated by an exclusion provision (that allows it to operate untouchably from other management and equity ownership at the the board-level), and TrustCor separately operates a privacy-enhancing communications service (MsgSafe.io) as two discrete business units.
To put it plainly and directly, TrustCor (including MsgSafe.io) has never cooperated with information requests from the US Government or any government for that matter. Likewise, we have not assisted or enabled any company or 3rd party to surveil, monitor or in any way gather information on our customers for the purposes of providing it to anyone else in any form, nor do we sell or broker customer data. Whether you’re a customer that has never paid us anything and you enjoy a free service level, or if you’re a customer who pays us for our most premium tier of service, your data is safe from prying eyes from the outside, and it always has been. With the help of our email products and services, we have enough premium paying customers to afford to make our downmarket services low-cost or free temporarily, and encourage people to spend money and upgrade for more features. Our email service operates at a statistically low level of abuse because we do things automatically to reduce the opportunity for abuse, such as limiting outbound email per account and automatically closing accounts when successive bounce notifications are received, and we process other complaints manually as efficiently as we can.
TrustCor has never allowed a certificate and/or key material to be generated outside of our audited and published standard processes, common amongst the entire industry. We live in a world with:
- certificate transparency logs;
- face to face audits once or more per year with 3rd party auditors visiting our locations and having direct access to internal records, offices and equipment;
- network security audits by separate, recognized industry experts;
- industry-approved, fixed set of options for auditors controlled by WebTrust/AICPA;
- the CA/B Forum and CCADB;
- and hyper-social accountability.
To assert there has been any violation or bypass of these safety measures would be silly, or at least completely impractical, and would render the standards a waste of everyone's time and money—which would set a new precedent. What's more, we've never even been accused of any false issuance or mishandling of material. Between the additional security afforded by our board-level exclusion provision designed to protect our CA business unit, and our nearly decade-long track record of having no change in control (only the payment of debt to prior shareholders), we operate a valuable, growing enterprise that serves global public interest and provides unique value to the community.
In reading related reporting and blogging off-list, I need to address an elephant in the room. Apparently it may also come as a surprise to some readers and the researchers themselves that other root program members are in fact international governments, and some are also defense companies, or companies who are wholly-owned by defense companies and/or state-owned enterprises, meaning "businesses" that are completely owned or controlled by governments. Further, some of those governments are not free/democratic and in fact some have tragic modern histories of basic human rights violations. We are none of those things and our company does not identify with those values. Given this point above, why of all potential targets are these researchers interested in TrustCor? They could go after countries with human rights violations that have placed a CA in the program. They could go after countries that suppress free speech that have placed a CA in the program. They could go after companies that are smaller CA/issuers than us, or much larger ones. They could go after CAs that are actually state-owned enterprises (owned by governments). But they aren’t. So why? Why choose to spend their time on this and on us in particular? We’ve been asking ourselves this since it began. We’ve only come up with 2 possible answers. (1) They saw that single domain name in an old registrar account and simply fell into recursive confirmation bias to assume everything stemmed from that... or (2) They make money in their for-profit enterprise if they can find any American nexus, so they can involve the American government and the FTC and create pressure with American journalists. Well, this mystery solves itself. They do get paid by FTC in their own web of companies. They do tip American journalists using their university affiliation and then plugging their company in the articles. And their American customers apparently don’t reward them to go after foreign companies. So this represented a great opportunity for them if they could prove the American companies they saw had anything to do with us — unfortunately for them, they don’t. We are not an American company or a company owned by Americans. If they’d known beforehand, they’d have probably paid no attention just like they’re not paying attention to other program members who literally are governments or state-owned/defense companies. I think this is all about self-aggrandizing: getting themselves and their company known, and about making money. These guys are in business, and they’re bullies. They wear the hat and shirt of university researchers from different multinational universities and yet they’re involved in the same startup company/business and other related businesses that benefit financially from the exposure and follow-on work, and they’re misusing this platform and betraying the purpose of this mailing list. It’s also worth noting: the researchers followed no semblance of responsible disclosure processes which are well established in the industry. They never attempted to work with our product team or management to express their concern, or suggest improvements, or discuss potential vulnerabilities. Instead they opted for maximum public impact and attempted to pressure this industry body with journalism following their sensational false narrative. They were even able to get an American journalist to publish a story without proper fact checking, and without speaking to any representative of our company even though two of us responded to the journalist immediately. Our CTO provided proof of this in writing in his letter with screenshots.
Some might argue this discourse is all healthy to shine more light onto this small community trying to make the Internet better and safer. However, the accusations and false claims against us have debilitating impact on our ability to service our customers, and instead have mainly served the self-interest of the accusers who are trying to drive traffic and intrigue into their startup company, despite their overt university affiliations.
And what exactly is the researchers' narrative? We’ve been accused of a "shady" corporate structure, but what they presented wasn’t an accurate reflection of our corporate structure even a year ago (which by the way was not significantly different than other corporate structures in any company). We’ve been accused of including some other company’s "bad" 3rd party software in an app, but that app never made it out of beta, and was already abandoned over 3 years ago, never having been released in production as a supported endpoint. Now they continue to recursively shake trees to try and associate shareholders-of-shareholders (2 or more parts removed) from the company and prior (already-dissolved) holding companies to try to establish any link with any other company, even though our exclusion provision would render that useless and immaterial and thus it would have no impact on CA operations. Likewise, because they don’t have experience in the CA ecosystem, they’ve already gone many steps beyond the scrutiny placed on any other member of these root CA programs because 2-degrees-removed shareholder enumeration is certainly not a feasible requirement to levy on any company, and is especially pointless when the equity holder interest cannot threaten CA operations (due to exclusion provisions).
Similar to our response of the previous comments made by Joel, we are obliged to respond that there are aspects of what Joel has stated both in his report and in his supplemental statements with which we disagree, would dispute or are factually inaccurate. We cannot ignore blanket statements designed to confirm our assent, of which there were several of these again.
I will respond below to the summarization points and additional questions raised by the researchers, many of which have already been addressed by our previous replies.
—————————————
In Response to Joel’s (University of Calgary/AppCensus) summarization and restatement (simplification) of previous responses,
Allow me to first address the summarized points, but please first note that we have addressed most (if not all) of these in-context in earlier replies. I believe in good faith you’re trying to simplify these topics, but it’s not easy or at least it’s not straightforward to do that. Many of these summarized points are factually inaccurate and contain misused legal terminology, which makes this extremely difficult for readers because the statements are misleading, especially when stated out of context as they are. I am not an attorney, and likewise you are not an attorney (unless you also have a JD, you have not shared that). That makes this dangerous because corporate law is not simple just like computer science is not simple. When you add the complexities of multinational jurisdictions, differences in language of the same legal terms having a different meaning across legal territories, and applying terminology and constructs that vary between those territories, there’s lots of room for misinterpretation and error that neither of us intend to cause. To give you a tangible example of how slippery a slope this is and how it can be easily misinterpreted: the open corporates guys are trying to normalize data from many different legal territories and for example, they list corporate "officers" and "members" in the same list. Obviously a "company" cannot be an "officer" inside another company (perhaps it can elect legal representatives to serve on a board of directors, but that’s different), just as an officer doesn’t necessarily mean someone is an owner or managing member of a company. Therefore that list is totally ambiguous. It’s not their fault, they’re getting data in different languages that’s translated and "normalized" for them so by the time they "get it" the data is already probably "imperfect," so to speak. Also, as you have already shown, filings can be created by attorneys or "others" listing controlling members or officers using "other people’s names" for a variety of reasons which can be helpful or perhaps malicious. This is precisely why management assertions and auditing standards are so important. Legal territories are not the same for everyone, so at least the auditing standards can be made the same for everyone (as they have been). The public has to rely on management assertions being 3rd-party-validated by approved auditors. That’s how the system has worked as long as any of us can remember, and it’s a pretty good system. Could it get better? Maybe, but remember you have to solve the problem for the whole world in this, not just North America.
In response to: "(i) The Panama open corporate records were accurate in 2020 and earlier, but at some point in 2021 have changed. The partners were CHIVALRIC HOLDING COMPANY, LLC and FRIGATE BAY HOLDING, LLC. These are registered in Panama."
I don’t think you are trying to conflate these things, but your incorrect use of legal terminology related to corporate structuring can cause a lot of misunderstanding that I don’t think you intend. We have already explained the "investor" and "investment vehicle" designation and status (for TRUSTCOR SYSTEMS S. DE R.L.) of the holding companies you mentioned. We’ve shared detail that is far beyond what other root program members provide, even under the new documentation requirements imposed by the program(s). You’re not just in the weeds and going far beyond our already-generous level of detail, but now you’re in the weeds using legally inaccurate terminology such as "partners" and others when we have already provided that level of detail in context.
In response to: "(ii) These companies are also partners for Measurement Systems S. De R. L."
Once again, I don’t think you are trying to conflate these things, but your incorrect use of legal terminology related to corporate structuring can cause a lot of misunderstanding that I don’t think you intend. e.g., what constitutes a "partnership" or what constitutes "investment" or what constitutes "management" or "membership" in a going concern. Even as I look past that and in good faith try my best to provide additional detail responsive to what I think is your interest, we cannot comment on the activity of another company, as any comment would be purely our speculation.In the spirit once again of trying to provide more detail in good faith to be as responsive as possible, one point worth remembering pertinent to this point is that both the holding companies you’re referring to (and that we referred-to in multiple earlier responses) were already dissolved during 2021, prior to any of the researchers inquiries, and as a normal progression of TrustCor’s business. While again I can’t speculate, my point is simply that making statements about those companies would not only be speculation, but it would be speculation in a direction that is known to be false, meaning your premise and statement is a false claim. You may not intend for it to be, but it is. If a company is already dissolved, it would not be possible for it to be a "partner" (again wrong legal term, but trying to be helpful to you) in any other businesses. You used "are" in present tense, yet as of more than a year ago that would not be accurate for any company in the same way as it was not accurate for us. I don’t know the disposition of that other company or its interactions with its shareholders in the past or present, but what we do know for certain is that the holding companies you mentioned were already dissolved. Therefore, we know that as of more than a year ago, those holding companies (once dissolved) were not "involved in" that other company either.It’s not my place to speak for anyone other than TrustCor, but you might also be wrong about that other company—maybe not because you didn’t try to get it right, but because you had outdated information and probably didn’t speak to them to make sure you had the latest or most accurate information. Also if they’re not subject to audits like we are then maybe you couldn’t or wouldn’t believe them anyway, but again there’s no point in speculating.
In response to: "(iii) The CHIVALRIC HOLDING COMPANY, LLC has no relation to the Chivalric Holding Company LLC registered in New Mexico formed Sept 2020 dissolved June 2022 with officer Vito Piacente, unless the relation is due to an attack against TrustCor."
We cannot comment on the activity of another company, as any comment would be purely our speculation. I have been warned by our counsel to avoid finger pointing as far as what constitutes an attack versus a mistake versus whatever are someone’s intentions for opening any business in any name at any time. All I can say is that it isn’t us, and that it would not make any sense for it to be us, and I don’t know anything about it. In fact, had you not brought some of these things into the public spotlight, they may have gone unnoticed by us completely because anybody can open a business in any name basically anywhere, anytime. That may violate trademarks, but that would mean the guy who owns the marks would have to know it happened and assert themselves. Who knows, there may even be a "Joel and Rachel Corp" in Haiti for all I know, and nobody needs my or your permission to register it, open or close it. Apparently in some regions / states in the USA you don’t even need to prove who you are to open a company in any name, or provide an ID. So I guess technically even if it was registered by a person, that person may not even be the person whose name it is registered under. I assume you can’t open a bank account (at least I hope you can’t!) without an ID and without being the person you say you are, but apparently those rules do not apply to people registering companies. Clearly you and I are both way out of our element. We leave this to attorneys.
In response to: "(iv) The FRIGATE BAY HOLDING, LLC has no relation to Frigate Bay Holdings LLC (the latter having an "s" in holdings and no comma) registered in Wyoming formed Sept 2020 dissolved June 2022 with officer Vito Piacente and manager Raymond Saulino, again unless the relation is due to an attack against TrustCor."
We cannot comment on the activity of another company, as any comment would be purely our speculation. However, I responded more informatively in my previous response directly above this and would apply the exact same response here.
In response to: "(v) Software produced by Measurement Systems was inserted by a rogue developer into the Msgsafe app and that developer operated outside their authorization; this inclusion was not sanctioned."
Prior context:
Our company never published a production or supported version of the MsgSafe.io 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.io’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.io 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.
Prior to my original reply, we had already completed an investigation related to this activity. Our software revision control system revealed immediately when the software was introduced and which developer introduced it. As I had previously stated, "… they incorporated additional software developers to help with the issues we were facing." The additional developers were contract developers. Also as I previously stated, "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." Our investigation found the developer in question properly signed our standard "Confidentiality Obligation and Invention Agreement” that requires any developer to obtain a corporate license to any 3rd party software or intellectual property the developer chooses to include. We confirmed through corporate records and email searches that no such agreement was ever obtained by the company or company counsel. Also, none was included inside the software/check-in to revision control. We also confirmed no approval for including this third-party software was ever obtained from Wylie (technically the manager of the developers at that time). Technically that individual developer violated our Confidentiality Obligation and Invention Agreement.
When we discussed this with legal counsel, their opinion that a labor dispute over an agreement violation that took place over 3 years ago would be limited/difficult to pursue, especially since the developer has not worked for the company in 3 years since native app development was abandoned in favour of our decision to focus on our mobile-first web application, which involves completely-different skillsets / personnel. Further, their opinion was that damages might not be readily provable because (as previously stated) the mobile app was never "released" or rather it was only provided for testing in a BETA form (that specifically admonished it was a beta and not supported) and used primarily by our own employees testing it. I realize the existence or proposition of this basically-unused beta software may have been a boon to AppCensus reporting and is of intellectual interest to the researchers, but our company sees no benefit to any legal or other pursuit with regard to benefitting our customers, or any relying parties.Supplemental response:Once again, this event has nothing to do with the TrustCor CA business unit or CA operations or shared personnel between the TrustCor CA and the MsgSafe.io development team. The BETA application in question was developed by a group of developers with access only to MsgSafe.io’s environment and NOT TrustCor CA’s environment. Software development for the MsgSafe.io BETA application was performed within the MsgSafe.io network and never touched TrustCor CA systems, networks or data centers.Specifically addressing Joe's language "... that developer operated outside their authorization; this inclusion was not sanctioned.":Because of the separation between TrustCor CA and MsgSafe.io those developers never had access to the same physical equipment, the same network, or the same data center. Also, neither MsgSafe.io nor TrustCor CA systems were ever compromised by the developer. We previously explained how we believe the SDK made its way into our BETA app and our findings regarding the system used to proxy traffic, both of which were setup by the developer while working on the application we ultimately decided to abandon 3+ years ago during our own natural course of business, years before any of this came to light. Depending on the definition you’re using for "authorization" this can be viewed differently. Better stated, the developer in question took it upon themselves to integrate that code without the company's knowledge and without seeking their boss’s permission in advance, which violates our "Confidentiality Obligation and Invention Agreement.”
In response to: "(vi) The Msgsafe website is implemented where the key material and PGP/SMIME encryption/decryption processing is performed on Msgsafe servers, with industry standard TLS used to secure the connection from the browser to Msgsafe servers."
Your statement is incomplete and also not accurate without additional context, and the answer is more complicated than an "always" and "never" situation because it is highly dependent on a user’s individual configuration and the options users choose to implement, which may be different than any default software behaviours. We have previously addressed this in our comprehensive response on 11/18. Oversimplifying our response is a disservice to the community. I also suggest you research how other popular web-based email encryption solutions operate so you might better understand why MsgSafe.io offers unique features that allow users to secure their messages as or more effectively than others solutions.Previous context:
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 team's 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.io 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 channel.
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.
Supplemental response:As already mentioned, MsgSafe.io’s platform can be configured by the customer in a number of ways, including using the e-mail forwarding service. When users enable this option (which is statistically common) they are prompted to upload a "public" key that MsgSafe.io will use to encrypt messages to them. This allows (for example) an iOS customer to use his or her platform’s built-in S/MIME implementation in their mail client to decrypt incoming mail and to encrypt messages to their contacts. In this situation, for example, MsgSafe.io never has the user’s private key. This private key is never in our possession, and users can implement this with S/MIME or with GPG, and never give MsgSafe.io their private key.These key management challenges the researchers mention are not related to company behaviours, they’re technical challenges related to giving someone the ability to walk up to any computer in the world, enter a web address and securely exchange emails, bringing nothing with them. The only way that’s accomplished today is for at least some of the private keys to be stored on the server. Whether the decryption is happening in javascript or in python or in any language, on the client or on the server, if the user came with "nothing" from a public computer, then the keys are necessarily on the server. The real difference is what other features a security platform like MsgSafe.io offers to improve the overall experience and/or to secure messages otherwise. The challenges, in and among themselves, are common and well understood across the industry. Again, I suggest you research how other popular web-based email encryption solutions operate so you might better understand why MsgSafe.io offers unique features that allow users to secure their messages as or more effectively than other solutions. 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. This will allow that team to work with you and improve the product.
In response to: "(vii) Typosquatting was done intentionally for similar email products, encrypted and otherwise, in 2016. But this was not done maliciously and no users were intentionally mislead about where they ended up."
We have previously addressed this in our comprehensive response on 11/18.Previous context:When the domains were registered, it was 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.Supplemental response:In situations like phishing or others where users are intentionally misled, typo squatting is certainly a problem. However, in this situation, there was not even a custom landing page or a reverse-proxy type situation where the URL or name was retained—literally users were sent to the standard MsgSafe.io web site immediately, changing the URL to the MsgSafe.io URL, and making them aware they had reached the MsgSafe.io service. If they preferred another service they could certainly change web pages they were visiting. We cannot conceive of any situation in which a user might feel misled. While we have chosen not to use this form of advertising or traffic generation in 6 years, we acknowledge it is still used today by many others and we don’t condemn a use case like this when implemented the way it was.
In response to: "(viii) TrustCor is not a Canadian company, in that the TrustCor CA does not have any company in Canada, filings in Canada, etc."
Again, I believe you are using legal terminology and conflating business complexities that are not as straightforward as you make them out to be.Previous context:TrustCor’s Ontario (Canada) 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.
Quoted from the WebTrust Illustrative Examination Reports Under SSAE 18 and SSAE 21, Version 2.0 Published 1 February 2022."All reports issued should list the state/province, and country of all physical locations of CA facilities that were included in the scope of the engagement. CA facilities may include data centre locations (primary and alternate sites), registration authority locations (for registration authority operations performed by the CA), and all other locations where general IT and business process controls that are relevant to CA operations in scope (including cloud and remote locations)."
Based on the requirements coming directly from WebTrust, we believe we are reporting correctly inside the management's assertions. It still remains true that a good portion of our business process controls, relevant to the CA operations, are conducted by key personnel from Canada. As previously stated, we have always disclosed both our Canadian and United States locations in our CPS document and management assertions.Supplemental response:Sir, it is like asking if one of your favorite brands is a Canadian company. They may have a division in Canada. They may have filings in Canada. They may not. They may have those things and then stop at some point. They may start up again at some point, often decided by tax and number of employees and benefits details. Are you speaking historically as in the "genesis" of a business, or asking about its current management and filings? Again, you’re not an attorney and neither am I, but we are adhering to policies the best way our lawyers, accountants and auditors can determine, and we’re reporting on them that way too in our management assertions. There’s no lack of transparency here, and we’ve answered this with supporting detail ad infinitum.
—————————————
In Response to Joel’s (University of Calgary/AppCensus) supplemental concerns,
In Response to Joel’s (University of Calgary/AppCensus) supplemental concerns,
In response to "(q1) … Assuming the privacy oriented jurisdiction being referenced by the paragraph is Arizona, why is Curacao part of that paragraph? Note this is TrustCor's website, not Msgsafe.":
The researchers seem to keep ignoring the fact that TrustCor itself operates both the TrustCor CA business and the MsgSafe.io business as effectively standalone business operating units, both of which it owns. This has been stated time and time again.
Prior context:
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.io 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.
Supplemental response:
TrustCor is a for-profit business that offers products and services. A product of TrustCor is MsgSafe.io, and TrustCor's CA business unit is a line of services. TrustCor is in the business of promoting its products and services, and as previously stated in an earlier response, the "geo-jurisdiction advantage" is referring to TrustCor's product being MsgSafe.io. TrustCor's MsgSafe.io product is completely isolated from TrustCor CA services—we have a separately provisioned data center, computer equipment, databases, network, and in some cases also local staff specifically for MsgSafe.io so that none of the MsgSafe.io environment (data center, network, servers, etc.) is ever sharing the same resources as the TrustCor CA business unit. We take pride in our CA business and ensure that it is always up to the highest standards and compliant with the NetSec Requirements. Additionally, our decision to host our MsgSafe.io product in a location with a geo-jurisdiction advantage was so the email product would not be subject to requiring to comply with orders to obtain information from MsgSafe.io users.
If this is about making the page on TrustCor's website more clear to the public (though, we think that it is currently pretty clear) that the geo-jurisdiction advantage text is in reference to its MsgSafe.io product, we can make that happen. We appreciate your constructive criticism here and are always striving to improve our business in any way possible. If you have specific suggestions for this text please provide them to us for consideration.
In response to "(q2) … did TrustCor's founder Ian Abramowitz or his son Ryan Abramowitz ever act as a representative for Measurement Systems or for its partners, namely CHIVALRIC HOLDING COMPANY, LLC and FRIGATE BAY HOLDING, LLC? (the Panama ones, not the copycat US ones)
Prior context:
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.
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 "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: "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.
Supplemental response:
We’ve already replied and addressed our ownership (with the points, in context, above) and have also explained that our owners have no control or influence over our operations, per our signed exclusion agreement: "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." The researcher's attempt to take points out of context does not provide the public with any new information and we have already explained our ownership vs. operational control. We are limited to truth and fact that we know or control, and have been cautioned over and over again not to speculate as to the disposition or ownership of entities we do not control (Measurement Systems S. De R.L., CHIVALRIC HOLDING COMPANY, LLC, or. FRIGATE BAY HOLDING, LLC).
As we previously stated "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 support of that fact I will share that we have internal TrustCor business records from 2013 where Ian Abramowitz signed on behalf of (as a legal representative of) both holding companies, but we do not know or care to speculate if Ian was involved in the formation of those companies or was merely an authorized legal representative at any given time. Anything the holding companies invested in other than us is unknown to us and would be purely speculation.
In response to "(q3) Is there any risk that the rogue developer could have compromised TrustCor in any other way other than running unauthorized TCP relays and getting unauthorized code committed?":
Prior context:
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.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: “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.
In Response to "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.":
Prior context: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.Supplemental response:Prior to my original reply, we had already completed an investigation related to this activity. Our software revision control system revealed immediately when the software was introduced and which developer introduced it. As I had previously stated, "… they incorporated additional software developers to help with the issues we were facing." The additional developers were contract developers. Also as I previously stated, "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." Our investigation found the developer in question properly signed our standard "Confidentiality Obligation and Invention Agreement” that requires any developer to obtain a corporate license to any 3rd party software or intellectual property the developer chooses to include. We confirmed through corporate records and email searches that no such agreement was ever obtained by the company or company counsel. Also, none was included inside the software/check-in to revision control. We also confirmed no approval for including this third-party software was ever obtained from Wylie (technically the manager of the developers at that time). Technically that individual developer violated our Confidentiality Obligation and Invention Agreement.When we discussed this with legal counsel, their opinion that a labor dispute over an agreement violation that took place over 3 years ago would be limited/difficult to pursue, especially since the developer has not worked for the company in 3 years since native app development was abandoned in favor of our decision to focus on our mobile-first web application, which involves completely-different skillsets / personnel. Further, their opinion was that damages might not be readily provable because (as previously stated) the mobile app was never "released" or rather it was only provided for testing in a BETA form (that specifically admonished it was a beta and not supported) and used primarily by our own employees testing it. I realize the existence or proposition of this basically-unused beta software may have been a boon to AppCensus reporting and is of intellectual interest to the researchers, but our company sees no benefit to any legal or other pursuit with regard to benefitting our customers, or any relying parties.
In Response to "… I decided to spend a little bit more time exploring it … [many lines of technical details] … This certificate was issued by/to MsgSafe (it appears to be self-signed)":
Prior context: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.Supplemental response:Yes, we agree this certificate you found embedded inside that software / SDK appears to be for "an1.msgsafe.io" and that it was NOT issued by TrustCor CA — it appears to be self-signed by either the developer who added it, or more likely the author of the actual SDK. This is a strong indication TrustCor CA was not involved in the software / SDK. Given a legitimately-signed certificate could have been integrated by MsgSafe.io’s own development team who could easily request it from TrustCor’s CA team, it certainly is evidence that the TrustCor Certificate Authority was not involved in this piece of software or its temporary addition to MsgSafe.io. Further, it indicates this is likely an act of an individual developer, and not even the MsgSafe.io team being duped. We looked at all the URLs you provided in your supplement and can confirm TrustCor CA has not issued any of those certificates at any time, and those URLs are not otherwise known to us.
In Response to "… it appears to be programmed to instead send data to MsgSafe's own servers! Why are MsgSafe's servers hardcoded to receive data from Measurement Systems' SDK?":
We had previously performed a forensic investigation of the an1.msgsafe.io hostname you found, along with its IP address history and the host itself, in addition to the certificate search (which again came up blank since it was not issued by TrustCor CA or any legitimate CA so far as we could tell). The hostname you mentioned pointed to a Linux VM that had been provisioned by the same developer we discussed. We were able to recover from backup a copy of this VM and forensically analyze it. The only user was a generic administration account (presumably known by the developer) and the only customization beyond any standard VM configuration was a firewall configuration and the open port 443 that accepted traffic from anywhere. The only listener attached to port tcp/443 was a proxy program which appears to be this: https://github.com/kklis/proxy The only version of the VM we were able to retrieve had no customizations to the configuration file, but it was set up using "systemd" so our conclusion was that the developer was likely redirecting the actual TCP stream somewhere else/offsite, and we confirmed the firewall configuration both on the host itself and the upstream router as far as the egress ACL/filter would have allowed this so long as he was sending it to any of tcp/443, tcp/8080, tcp/8181 or a few others. There is no indication the developer was "hosting" anything at MsgSafe.io beyond a simple redirector designed to send it somewhere else. There was no web server on this system and no certificates, so it was being redirected at the TCP level.
This above disagrees with your statement "… MsgSafe.io s servers hardcoded to receive data ..." where you intimate that our company is receiving the data. A proper characterization would be that a developer had set up a TCP proxy to reflect data somewhere else, but not necessarily to receive it. What you wrote is at best a mischaracterization, or potentially another false claim as it may be forensically proven to be false.
Supplemental response:
First, to correct your inaccurate assertion, neither MsgSafe.io nor TrustCor CA systems were ever compromised by the developer. The developer rightfully had access to the MsgSafe.io systems (and never had access to the TrustCor CA network and systems which are in fact operated separately).
The developer had access only to MsgSafe.io’s environment and NOT TrustCor CA’s environment. Software development for the MsgSafe.io BETA application was performed within the MsgSafe.io network and systems, and never touched TrustCor CA systems, networks or data centers. Because of the strict separation between TrustCor CA and MsgSafe.io, the developer never had access to the same equipment, the same network, or the same data center. We previously explained how we believe the SDK made its way into our BETA app and our findings regarding the system used to proxy traffic, both of which were setup by the developer while working on the application we ultimately decided to abandon for unrelated reasons several years before any of these questions arose.
In response to "How and when were these actions detected and are they referenced in any audit?"
We intentionally created completely separate environments for the product and services we offer (this being further evidence that it was a great idea); the developer did not have access to the TrustCor CA environment. The purpose of the forensic examination was to understand if anyone left the MsgSafe.io environment and entered the TrustCor CA environment, which resulted in no finding of that behaviour. Had we discovered anything that affected the TrustCor CA business unit then we would have reported it, of course.
In response to "(q4) In what countries is TrustCor a legal entity?":
TRUSTCOR SYSTEMS S. DE R.L. is a legal entity in Panama. While we appreciate your comprehensive line of questioning, the intricacies and complexities of creating and operating multi-national corporations/entities that comply with both laws and regulations put in place by the governing bodies is something that requires multiple people and a lot of time to explain, and an advanced knowledge of multinational legal workings. For example: there are companies that only contract with payroll firms and employ people in particular countries or regions, there are companies that act as holding companies that bear the company name, but merely exist to aggregate regional employment entities. Likewise there are entities that simply hold assets or sign leases. This is far too complicated and far out of scope for public dialogue and frankly some of it is confidential as those records have people attached to them and personal information, and making record of them could create future tax liabilities or otherwise, while simultaneously not being useful to the community whatsoever.
Our attorneys have advised us that explaining these things in a public setting will only create legal issues for us later, which we are hoping to avoid. If this response sounds frustrated to you, it is because we have already established that regardless of the ownership (even if it’s the devil himself/herslef), it is irrelevant because our exclusion provision separates our ownership from our operations (as should all CA’s in our opinion). While the complexities of implementing global businesses might be interesting academically, we do not believe it is germane to this group because there are no requirements to recursively enumerate ownership or to identify controlling parties if they are (in our case) separate from our owners.
I hope the community continues to find this helpful and constructive.
Kurt Seifried
Nov 26, 2022, 11:46:05 PM11/26/22
to Rachel McPherson, MDSP, Kathleen Wilson, Ryan Dickson, Clint Wilson
I'm not sure how to say this but:
I'm not seeing any real answers. I'm reminded of the TV show "Cops" and the classic "who's car is this?" followed by some extremely long and convoluted story about how their cousin lent the car to their best friend who is a dog groomer and they're just picking up medicines for a sick grandmother, TL;DR: the car was invariably stolen.
The answer around the Canadian company bits is convoluted, there's mention of employees and work from home (which has literally nothing to do with legal corporate structures), and no mention of ownership/corporate directors/share types and ownership, so how about this:
Please list any and all Canadian corporate structures registered by, used by or owned by Trustcor.
This doesn't have to be complicated, hell, I own a numbered corporation and have been doing this since 1998 in Alberta (which doesn't have exactly the same laws as Ontario, but close enough).
This stuff is all public record ultimately that costs a few bucks (e.g. https://www.ontario.ca/page/cost-time-required-to-register-change-search-for-business-name-corporation-not-for-profitx) but it would be nice if Trustcor provided some information rather than making the community hunt for it and pay for it. You should say it would help build trust.
The fact that we can't get a simple and clear answer (some random text about brands and legal advice about tax situations, aka "that's how business works") is telling.
--
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/855A4BF1-F736-4AEE-94EE-5D97E5286302%40trustcor.ca.
Kurt Seifried (He/Him)
ku...@seifried.org
ku...@seifried.org
Watson Ladd
Nov 27, 2022, 11:11:10 AM11/27/22
to Rachel McPherson, MDSP, Kathleen Wilson, Ryan Dickson, Clint Wilson
Dear Rachel,
It has never been the case that compliance with a narrow set of rules creates trust in a human endeavor. The decision to trust a CA is an ongoing one, and the behavior of its representatives is evaluated in that light, as representative of the attitude taken by the organization to its responsibilities. Your aggressive bloviation and evasion contrasts quite negatively to the openness with which other CAs have addressed issues before, and is most certainly affecting the trust that I would consider reasonable to place in TrustCor.
In particular it is not clear to me what the entities and people being discussed who have ownership of TrustCore CA are, what all the jurisdictions where operations or entities were formed are, how these structures change over time, and what transactions were supposed to effect these changes. All we hear is a few pieces and disputing that we need to care about the rest. You talk about an operational insulation agreement, but haven't provided any details or indicated where details might be found. This incompleteness makes it difficult for me to assess your assertions about the entities involved. Nitpicking the tense and grammar of questions reminds me of nothing so much as a former President.
Ultimately as we've seen with WoSign, etc the CA business is much like banking. When you need to say "we've got good credit", your credit is actually worthless already. And given that TrustCor seems to have only one customer, there really isn't much of a reason not to expel them.
Sincerely,
Watson Ladd
Filippo Valsorda
Nov 27, 2022, 1:56:58 PM11/27/22
to dev-secur...@mozilla.org
Hi all,
I agree with Watson. The original concerns, except the potential links to a spyware operation, didn't feel like grounds for distrust to me. However, the way this CA approached the claims leaves me with no trust in their operations. Every communication was combative, condescending, not forthcoming, vaguely threatening, and showing contempt for the forum and the process. Multiple times they point fingers at other operators, rather than take the opportunity to note potential improvement areas. They tell us what we are supposed to care about, instead of proactively striving for transparency.
Overall, I can't tell if the core concern—the link to a spyware operation—is assuaged or drowned and misdirected, but I do leave with the impression that TrustCor can only be relied upon to operate at the minimum common denominator of the baseline requirements. My understanding is that the baseline requirements are just that, a rock bottom that no CA may drop below, and not a bar that is sufficient to clear to deserve trust. Instead, TrustCor seems to believe meeting the baseline is all that is required of them, and disputes any other concerns by remarking they meed the baseline.
Fundamentally, a baseline CA is not particularly valuable, especially if it serves a single relatively low-volume customer, and it would seem to me it exposes the Mozilla and WebPKI community to more risk than it's worth.
Best,
Filippo
--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/CACsn0ck3ZjQbakCTCL59GhrT%2BhwgHTEr3gv3LeVu2SSGxgYGGA%40mail.gmail.com.
Cynthia Revström
Nov 27, 2022, 8:09:06 PM11/27/22
to Filippo Valsorda, dev-secur...@mozilla.org
Hi,
I agree with Watson and Filippo. The inability to answer a question so
basic as "in which jurisdictions are you a legal entity?" is not
exactly great for building trust.
Additionally Rachel is making it unnecessarily time consuming and
confusing to follow what is going on by repeating themselves,
mentioning irrelevant things, and not answering the questions but
rather explaining why we seemingly don't deserve to know basically
anything about TrustCor.
The correct course of action here would have been to give clear
answers to the questions raised, which would probably be quite easy to
do if everything was in order I would think.
Most other CAs are able to answer questions about their operations
without going into speculating about the motives of the people who
initially questioned them.
I feel the same way as Filippo about the initial concerns, I don't
know if they are actual issues or not.
However the replies from TrustCor made me lose any trust I might have
had for them and in my opinion it would probably be for the best if
Mozilla distrusted TrustCor, especially given the very limited
customer base.
-Cynthia
> To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/59ce57f4-c47e-479d-b31d-c3467ae14c03%40app.fastmail.com.
I agree with Watson and Filippo. The inability to answer a question so
basic as "in which jurisdictions are you a legal entity?" is not
exactly great for building trust.
Additionally Rachel is making it unnecessarily time consuming and
confusing to follow what is going on by repeating themselves,
mentioning irrelevant things, and not answering the questions but
rather explaining why we seemingly don't deserve to know basically
anything about TrustCor.
The correct course of action here would have been to give clear
answers to the questions raised, which would probably be quite easy to
do if everything was in order I would think.
Most other CAs are able to answer questions about their operations
without going into speculating about the motives of the people who
initially questioned them.
I feel the same way as Filippo about the initial concerns, I don't
know if they are actual issues or not.
However the replies from TrustCor made me lose any trust I might have
had for them and in my opinion it would probably be for the best if
Mozilla distrusted TrustCor, especially given the very limited
customer base.
-Cynthia
Rachel McPherson
Nov 27, 2022, 11:05:12 PM11/27/22
to MDSP, Kathleen Wilson, Ryan Dickson, Clint Wilson
Dear Kurt, Watson, Filippo & Cynthia,
Thank you all for chiming in. I’m not sure how exactly you’re involved in the CA community, do you represent a CA? A browser perhaps? Or any of the governing bodies? (I.e. CA/B forum member, WebTrust, ETSI, etc.). Or are you concerned citizen consumers? Your feedback is valuable no matter the answer, but I think the answer also matters to this public forum.
Since this is a public forum, and anyone in the public can post here, regardless of playing an active role in the CA community, it might be easy to lose sight of what this conversation is all about and why we are actually here. Every bit of additional information we are providing here, for the public, is done in spirit of transparency. But we certainly have limits on what’s acceptable or beyond acceptable to answer based on what information belongs in the public domain versus what doesn't.
Please understand we’re trying to keep it simple. We received a lot of messages off-list since this began. In the last 24 hours we received a number of messages with advice on how to respond to all your messages. We are simultaneously receiving advice to "shorten and simplify" and also simultaneously receiving advice to "re-paste the context from the previous answer and add to it" and so we seem to be caught in the middle of both, which is clearly upsetting everyone. From the beginning we have tried to be forthright and transparent with this community and to use prior issues/answers from prior events to make sure we were providing an equal or greater amount of information—we are. Unfortunately for us, this community is pretty busy and seems to not want to read the full answers or understand the full context behind the answers, so we are doing our best. We are trying to please everyone and we all know how that turns out. For the sake of simplification I’m going to try to answer these popular items more simply below without pasting anything from before, but everything before is going to be underneath it.
While we have already answered these topics in context, it's coming across that our answers seem long and boring based on the "TL;DR note" from your message, so again in the spirit of transparency, let me try to simplify responses to your topics:
The topic of Canada keeps being brought up and it seems that subsequent posters are feeding off each other's responses versus caring to know why it was initially brought up. The reason why Canada was brought up in the first place was because we have Canada listed on our audit documentation. Now that you know the "why", here is the answer:
We continue to answer this question and somehow it’s either getting missed or skimmed-over by the researchers. So here’s an additional attempt to make it as clear as possible: We are required by WebTrust (our auditing body) to list in our audit reports the state/province, and country of all locations of Certificate Authority facilities ("CA Facilities") that were included in the scope of the audit. WebTrust defines "CA facilities" as:
"data centre locations (primary and alternate sites), registration authority locations (for registration authority operations performed by the CA), and all other locations where general IT and business process controls that are relevant to CA operations in scope (including cloud and remote locations)"
I hope that helps…
This means we need to list every single location relevant to the Certificate Authority part of our business, whether we have people sitting somewhere, or whether we have paperwork registered there, or even if it’s just equipment/storage. This is why we list both Canada and the US - our operational staff, validation team, off-site/secure back-up storage are all performed out of Canada, whereas our technical operations (pertaining only to the Certificate Authority-portion of our business) is conducted out of the US. These are our requirements—we don’t make them up, it’s what is being asked of us. Since that’s how our business is broken up, that is what we are required to include.
As what was already pointed out, our tax presence in Canada ended in 2016. If we simply told you "we don’t have a company currently in Canada" then the question would be "Then why did you used to, what happened, did you get bought/sold or something else" so instead we gave the full context that we had a physical office in Canada before, and we had a legal entity in Canada until 2016. However, we continue to have key staff there who work (remotely/virtually) for the company, so that is one reason why we must continue to list it on the paperwork even if there’s no legal entity they work for in Canada unless they have their own personal tax entity/company which some do. How we got stuck and fixated on Canadian incorporation documents is beyond me (and beyond necessary disclosures).
If you wish to know how we are able to employ individuals in multiple countries - take our US employees working out of Arizona as an example, who are paid through a mechanism called 1099, in which case they (or a legal tax entity they themselves set up) can invoice the main TrustCor company and be paid that way. We have a similar setup in Canada. As we have grown from county to country to country, we’ve had to find mechanisms like this that allow us to employ just a couple of people in each place, which turns out to be harder than one might imagine.
We have never had a "change in control" in the company. Since it was founded in 2013, we’ve had only a couple of investors in our Panamanian legal entity (which is our primary legal entity) and our debit to those investors was satisfied in mid-2021 when we became employee-owned (and I’m the largest shareholder). More than a year after that we still have no changes, however since our original founder passed away we do have some paperwork cleanup still to do. Additionally, we have staff in Canada, as I mentioned, and we also have staff in the US and Curaçao. Curaçao is the only operating location for our MsgSafe.io services.
I’m also being asked for information off-list. To confirm that here, regarding the app that never made it out of beta into production: Yes, a 3rd party developer, who we contracted and paid as a consultant, (along with several others) to develop the app for us appears to have included other 3rd party software we didn’t know about. Including 3rd party software without us knowing violated our developer’s agreement. Again, this app was never released into production, and we abandoned native app development over 3 years ago. Until it was announced this year by the researchers, we had no idea this had happened and that person has not worked for us in more than 3 years.
And to make sure this is clear as well: TrustCor and MsgSafe.io work completely independent of each other, and always have. TrustCor and MsgSafe.io have completely separate data centre locations, equipment, servers and developers working on each aspect of these businesses so there is no chance, or ever the opportunity, for that same MsgSafe.io developer to touch anything related to the Certificate Authority.
Thank you. What follows is merely my last reply for people who want the extra context, but there’s nothing new below — the "short and direct" answers are all above.
Kurt Seifried
Nov 27, 2022, 11:31:29 PM11/27/22
to Rachel McPherson, MDSP, Kathleen Wilson, Ryan Dickson, Clint Wilson
On Sun, Nov 27, 2022 at 9:05 PM Rachel McPherson <rac...@trustcor.ca> wrote:
Dear Kurt, Watson, Filippo & Cynthia,
Hi!
Thank you all for chiming in. I’m not sure how exactly you’re involved in the CA community, do you represent a CA? A browser perhaps? Or any of the governing
I think all of us are easily found via Google.
bodies? (I.e. CA/B forum member, WebTrust, ETSI, etc.). Or are you concerned citizen consumers? Your feedback is valuable no matter the answer, but I think the answer also matters to this public forum.
"the answer" to what exactly?
Since this is a public forum, and anyone in the public can post here, regardless of playing an active role in the CA community, it might be easy to lose sight of what this conversation is all about and why we are actually here. Every bit of additional information we are providing here, for the public, is done in spirit of transparency. But we certainly have limits on what’s acceptable or beyond acceptable to answer based on what information belongs in the public domain versus what doesn't.
Uhm. Then why can't you clearly answer the questions?
--
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/B7FB7B88-291F-4746-B0B1-AFCFE91C4C8C%40trustcor.ca.
Matt Palmer
Nov 28, 2022, 1:26:23 AM11/28/22
to MDSP
On Mon, Nov 28, 2022 at 04:05:01AM +0000, Rachel McPherson wrote:
> Thank you all for chiming in. I’m not sure how exactly you’re involved in
> the CA community, do you represent a CA? A browser perhaps? Or any of
> the governing bodies? (I.e. CA/B forum member, WebTrust, ETSI, etc.).
> Or are you concerned citizen consumers? Your feedback is valuable no
> matter the answer, but I think the answer also matters to this public
> forum.
Those who wish to declare their affiliations do so in
> Thank you all for chiming in. I’m not sure how exactly you’re involved in
> the CA community, do you represent a CA? A browser perhaps? Or any of
> the governing bodies? (I.e. CA/B forum member, WebTrust, ETSI, etc.).
> Or are you concerned citizen consumers? Your feedback is valuable no
> matter the answer, but I think the answer also matters to this public
> forum.
https://wiki.mozilla.org/CA/Policy_Participants. The fact that it is
optional to declare affiliations suggests that, in fact, an individual's
"status" in the CA community is not particularly relevant to the discussions
here. If someone raises a good point, then the module owner and peers will
likely consider it regardless of the nature of that person's involvement in
"the CA community".
This attempt to appeal to authority is unlikely to engender greater trust
in the organisation you represent.
- Matt
Serge Egelman
Nov 28, 2022, 1:52:32 PM11/28/22
to MDSP
Based on our findings and Rachel's emails, here is my understanding of things (please correct me if any of this is wrong):
- At the point of its founding (though not currently), TrustCor shared the same corporate ownership with Measurement Systems, a shell corporation created to distribute mobile spyware under the guise of ad-free app monetization. Measurement Systems is connected to Packet Forensics (a dba of Vostrom). TrustCor appears to use the same Phoenix datacenter as Vostrom:
- A rogue developer, hired by TrustCor as a contractor to build the MsgSafe mobile app, embedded Measurement Systems' spyware SDK. This rogue developer had access to the only unobfuscated version of the SDK that we have seen in the wild.
- This version of the SDK was customized to send sensitive user data to a MsgSafe hostname. This same rogue developer set up a proxy to receive data sent by the SDK and then forward it on somewhere else. This involved compromising one or more machines owned by TrustCor. This compromise went undetected by TrustCor/MsgSafe for 3+ years.
- MsgSafe offered this app (with the malware SDK) to the public via the Google Play store as part of a public beta, where it was free for anyone to download up until earlier this year. MsgSafe publicized its mobile app on social media. As of this writing, MsgSafe's website still links to the Google Play store (though the app was removed earlier this year):
- Despite advertising "end-to-end encrypted email" (see above screenshot, taken today), MsgSafe does not actually provide end-to-end encryption (E2EE), as the term is commonly understood. Instead, encryption/decryption is performed by MsgSafe's servers, giving them the ability to read email contents. (As background, the FTC went after Zoom for deceptively claiming it offered E2EE, when it didn't.)
- Besides its MsgSage business, TrustCor primarily issues certificates for No-IP customers via some sort of partnership arrangement. While it's been assumed (I think, unless I'm misreading?) that No-IP is TrustCor's primary customer, no evidence has been offered that they're actually a customer. That is, does No-IP pay TrustCor to give away their certificates for free? Or does TrustCor pay No-IP? I'm not sure this has been answered.
- In 2010, Packet Forensics was marketing its ability to subvert TLS. It was assumed they were forging certificates, but beyond that, the specifics have been cause for speculation.
Based on that understanding (and again, please let me know if any of that is incorrect), I personally believe it's possible that Rachel may be a victim here, if she really is the primary TrustCor shareholder (e.g., maybe the company was given to employees, after it was no longer useful). If TrustCor's private keys were compromised at its founding or before (e.g., so that Packet Forensics could sell TLS-interception boxes), the company itself would have little continued value, so long as it passed its audits (and remained trusted by browsers and operating systems). It's therefore possible that Rachel had no awareness of this, and as a result is in the denial phase of realizing that she's the victim of a scam. This is not a statement of fact, I'm just offering it as a possibility.
Finally, I want to clarify that beyond initially discovering Measurement Systems' spyware SDK and blogging about the technical details, AppCensus has had no role in any of this. We specifically asked that AppCensus not be mentioned in the WaPo article because AppCensus has had no involvement with the subsequent research. If TrustCor wishes to send specious legal demands, they should direct them to our university GCs.
Thanks,
serge
--
You received this message because you are subscribed to a topic in the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this topic, visit https://groups.google.com/a/mozilla.org/d/topic/dev-security-policy/oxX69KFvsm4/unsubscribe.
To unsubscribe from this group and all its topics, 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/Y4RUhGzua2K5FZtw%40hezmatt.org.
Rachel McPherson
Nov 29, 2022, 1:09:26 PM11/29/22
to MDSP, Kathleen Wilson, Ryan Dickson, Clint Wilson
I hate to say this Serge, and please correct me if Im wrong, but it honestly seems as though your focus is ever-changing based on any information you're given, where you see an opportunity to adapt it to form a consensus that best serves your narrative, due to your bias against us. I can't help to think this based on your last post, especially since you've now taken the approach of coming at me personally, further validation to anyone reading this forum that everything you've claimed in this dog and pony show stems from personal speculation and nothing more. I believe going forward, its only right for you to preface your messages with "in my opinion" because that's all that's here.
I will continue to support this exercise of good faith and transparency, by responding in-line to your post below, even though I no longer agree with your methods and tactics, because I believe its only fair that we set the record straight, even though you continue to make out-of-context statements.
At the point of its founding (though not currently), TrustCor shared the same corporate ownership with Measurement Systems,
This is not correct. A "shareholder" (of a "shareholder" or of a "holding company who is a shareholder") is not the same as an "owner". Please refer back to my many previous posts on this subject.
a shell corporation created to distribute mobile spyware under the guise of ad-free app monetization. Measurement Systems is connected to Packet Forensics (a dba of Vostrom).
Is this a fact that those two companies are connected to one another? I don't think it’s fair or necessary to make claims about other companies on this forum. Especially since the only actual association I can find is the one made by you and your partner. If that's what you're referring to, it’s important to let the public know that these are only your assumptions and not based on facts. Then, you leave room for yourself using terms like "connected to" since you know you can’t factually define any relationship. I guess I’m connected to you also, by that reasoning.
TrustCor appears to use the same Phoenix datacenter as Vostrom:
This only shows what networks are connected to who and if you look closely you’ll see dozens or hundreds of connected networks for both these companies through adjacencies and multiple Internet exchanges. We’re connected to lots of people through exchanges and it’s no surprise other companies are too.
If this is true that one of our data centers happens to be in the same campus as one of another company’s data centers, then it should come as no surprise, and hardly a coincidence, that TrustCor uses a large and popular SOC-2 compliant datacenter operator. In fact, we know of many other CAs that use that same datacenter as well. Which by the way is only one of our datacenter locations.
A rogue developer, hired by TrustCor as a contractor to build the MsgSafe mobile app, embedded Measurement Systems' spyware SDK. This rogue developer had access to the only unobfuscated version of the SDK that we have seen in the wild.
We have explained all of this in detail in our previous posts but you seem to only pull out the content that benefits your narrative. It’s important to note that the developer was hired by MsgSafe and never had access to any of the infrastructure used for TrustCor's Certificate Authority. But I encourage readers to look at the more detailed explanation of this to see just how far off this is from something noteworthy.Finding out that someone on your staff went against company policies and practices and developer's agreements is very upsetting. We'd like to hope that this wasn't done maliciously by that ex-developer, but I don't think we will ever know for sure. Instead, all we can do is verify that no further damage was done - which it wasn't and put additional measures in place to make sure this type of behaviour does not happen again - which we have.
This version of the SDK was customized to send sensitive user data to a MsgSafe hostname. This same rogue developer set up a proxy to receive data sent by the SDK and then forward it on somewhere else. This involved compromising one or more machines owned by TrustCor. This compromise went undetected by TrustCor/MsgSafe for 3+ years.
This is not correct. Once again, TrustCor and MsgSafe.io perform their business functions completely independent of each other. The only machines and network that this developer had access to were solely used by MsgSafe.io and strictly for the development of the beta (testing) app. To mistake either of these things the way you wrote them above makes it seem that you’ve either not read/understood our previous replies, or you’re intentionally misleading people reading this.
Since we've made it clear that TrustCor and MsgSafe.io have no shared resources, I'm not sure how this is even still relevant to the Certificate Authority side of our business? In addition, this was not "ongoing" for over 3 years like you speculated, this happened over 3 years ago.
MsgSafe offered this app (with the malware SDK) to the public via the Google Play store as part of a public beta, where it was free for anyone to download up until earlier this year. MsgSafe publicized its mobile app on social media. As of this writing, MsgSafe's website still links to the Google Play store (though the app was removed earlier this year):
This is not correct. The MsgSafe.io beta app was actually a testing beta, which could not be accessed by anyone via the Google Play store. The only way the app was accessible was to our employees or via a unique social media link MsgSafe.io sent out over 3 years ago, and that link only worked for a limited time. Using that unique social media link, we can tell that less than 1/10th of 1% of MsgSafe.io's users would have had the opportunity to download to test the app, and the actual number that installed it was much lower. Also, your statement about the MsgSafe.io website still linking to the Google play store is completely false. Did you even check this before making this post? In the screen-shot you shared, the icon labeled "Download on Google Play" does not direct you to the Google play store, it directs you to https://www.msgsafe.io/android which actually takes you to a 404 page on the MsgSafe.io website - it never leaves the MsgSafe.io website. Had you hovered over this link you would have seen this. Of course we're not proud of an outdated website and this should be updated, but that doesn’t make your false claim true.
Despite advertising "end-to-end encrypted email" (see above screenshot, taken today), MsgSafe does not actually provide end-to-end encryption (E2EE), as the term is commonly understood. Instead, encryption/decryption is performed by MsgSafe's servers, giving them the ability to read email contents. (As background, the FTC went after Zoom for deceptively claiming it offered E2EE, when it didn't.)
As we have stated before, there are many possible ways to use the MsgSafe.io platform, one of which is for a user to upload their own public keys and encrypt using both S/MIME and GPG, or only GPG, or only S/MIME. Since there is a way to use the MsgSafe.io product that allows for end-to-end encrypted email, there is no false claim or deception here. Also, if you read the text under the E2EE heading you’ll see it accurately describes a definition of what you’re complaining about, again making it not a false claim. You may not agree with the definition or like it, but we say exactly what it does. We also let the user configure strong default settings. And even if the user doesn’t configure stronger settings, the settings are still as capable as other popular email encryption solutions regardless of what they’re called, and MsgSafe.io's competitors use similar language on their websites.
Besides its MsgSage business, TrustCor primarily issues certificates for No-IP customers via some sort of partnership arrangement. While it's been assumed (I think, unless I'm misreading?) that No-IP is TrustCor's primary customer, no evidence has been offered that they're actually a customer. That is, does No-IP pay TrustCor to give away their certificates for free? Or does TrustCor pay No-IP? I'm not sure this has been answered.
We have answered every question the public has asked. I’ll assume this is your odd way of adding a new question about what is our relationship with our customers. I can tell you that all our resellers are on pre-paid plans whereby they pre-pay to obtain a bulk volume of credit (the more they buy the less they pay each) for which they can then use and charge (within reasonable limits) whatever they like and use whatever business mechanisms they like. Some customers, for example, choose to bundle short-timeframe (less than a year) certificates with some levels of their products, and also sell full-timeframe (about a year) certificates for premium $. That’s between them and their customers and how they choose to market whereas our relationship with them (in order for them to qualify as a reseller) is already been satisfied when they place bulk volume pre-paid orders.
In 2010, Packet Forensics was marketing its ability to subvert TLS. It was assumed they were forging certificates, but beyond that, the specifics have been cause for speculation.
How is this at all relevant to us? We don't have any relationship to that company, nor am I willing to comment on any speculations you have against any company.
Based on that understanding (and again, please let me know if any of that is incorrect), I personally believe it's possiblethat Rachel may be a victim here, if she really is the primary TrustCor shareholder (e.g., maybe the company was given to employees, after it was no longer useful). If TrustCor's private keys were compromised at its founding or before (e.g., so that Packet Forensics could sell TLS-interception boxes), the company itself would have little continued value, so long as it passed its audits (and remained trusted by browsers and operating systems). It's therefore possible that Rachel had no awareness of this, and as a result is in the denial phase of realizing that she's the victim of a scam. This is not a statement of fact, I'm just offering it as a possibility.
To now theorize and publicly suggest that "I am in a denial phase of realizing that I am a victim of a scam" is disrespectful and outlandish. I think you're taking this too far by making claims against me personally and I don't think its a good representation of your professionalism. You've forced us to be in a position to defend our company, but putting me in a position to have to defend myself personally is crossing the line. Would you have made the same assumption if I were a man?For the record, I have been with TrustCor since its inception and have personally bared witness to the initialization and installation of the hardware baring TrustCor's roots and private keys and can absolutely vouch for the safe handling of TrustCor's keys and credentials at all times.
Making up storylines without any merit, just because there might be a far-fetched possibility is just wrong.
TrustCor has always committed to follow industry trends and provide a level of security, in most cases greater than the baseline requirements to make the community feel comfortable with our operations. I realize that the information we have provided in great detail in our previous posts, may be a turnoff to most because its difficult to read, but we have done everything within reason and provided as much information as we can to help dissipate and explain any of these concerns. I'm sorry that our responses don't help to support your claims against us, but abandoning facts and adopting bias is not right. Maybe you’re human and you just overreached on anything that could be connected. Maybe that’s healthy for a security specialist. But like you said, "This is not a statement of fact, I'm just offering it as a possibility."
- Rachel
Filippo Valsorda
Nov 29, 2022, 7:46:18 PM11/29/22
to dev-secur...@mozilla.org
Hi,
I tend to agree at this point that discussing the merits of the claims might be superfluous, because the conduct of the CA's representative is a more urgent issue, but I figured that it would be easy enough to verify how the Msgsafe product works.
- I visited the MsgSafe home page, which at the time of this email claims "MsgSafe.io cannot read your email".
- I signed up for a free account, specifying a recovery email address. I selected a strong password.
- During the setup process, I was shown a pair of hex strings of 40 characters each (implying a 160-bit value, the length of a SHA-1 hash) described as S/MIME and GPG fingerprints. I was not prompted to download, upload, or generate any key or secret.
- A webmail loaded in the browser. I could not find any encryption-related setting having a cursory look through the menus. I might have missed it. I continued with the default setup. (There was an option to forward emails to a different address, optionally encrypted. As I understand it, this involves plaintext arriving on MsgSafe's servers, and then encryption for the forwarding leg.)
- I sent an email from my regular mailbox to my new MsgSafe address. It appeared in the mailbox.
- I logged out and closed the browser window, and then opened a fresh "incognito" browser window, which shares no local state with the previous session.
- I opened the MsgSafe home page, selected Login, then Need Help?, then Reset Password, and typed my username.
- I received an email at my recovery address. I clicked the link, typed the username again, and a new password.
- I was returned to the login page. I logged in with my username and new password.
- My inbox loaded, showing the email I had sent before resetting the password.
A few screenshots collected in the process at https://imgur.com/a/RzsFxoL.
The fact that I could reset my password and access the email archive by only proving control over my recovery address, without providing any secret value, necessarily means that MsgSafe can decrypt and read my email archive, which contradicts the home page claim. (This is sometimes referred to as the mud puddle test.)
Secure email is a hard product to provide, for many reasons, and products fall on a spectrum in terms of what security properties they provide. We could debate where the line is for what can be honestly described as end-to-end encrypted. As far as I can tell, MsgSafe falls close to a regular mailbox on that spectrum.
Regards,
Filippo
P.S. The signup flow offered me the option to choose what domain I wanted for my address. Amongst the options were @yahooweb.co, @outlookpro.net, and @reddithub.com. The full list is at https://gist.github.com/FiloSottile/cc5c706a78a06a88081cc1e9620ce6fd.
--
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/C9BAD50B-A066-4749-9734-E7299AEDEBE5%40trustcor.ca.Attachments:
- signature.asc
Peter Gutmann
Nov 29, 2022, 8:55:13 PM11/29/22
to Filippo Valsorda, dev-secur...@mozilla.org
Filippo Valsorda <fil...@ml.filippo.io> writes:
>This is sometimes referred to as the mud puddle test.
Interesting, I hadn't heard that term before. For anyone else interested,
it's from Matthew Green in this post:
https://blog.cryptographyengineering.com/2012/04/05/icloud-who-holds-key/
There’s a much simpler approach that I call the ‘mud puddle test’:
1. First, drop your device(s) in a mud puddle.
2. Next, slip in said puddle and crack yourself on the head. When you regain
consciousness you’ll be perfectly fine, but won’t for the life of you be
able to recall your device passwords or keys.
3. Now try to get your cloud data back.
Did you succeed? If so, you’re screwed.
Peter.
Dimitris Zacharopoulos
Nov 30, 2022, 1:22:41 PM11/30/22
to dev-secur...@mozilla.org
--
FWIW, I worked several times with Trustcor's representatives within the Server Certificate WG of the CA/Browser Forum, and more closely at the Network Security Subcommittee (now a separate Working Group). One particular Trustcor representative was very actively working with the rest of the subcommittee on improving the network security requirements and raise the bar for all CAs, providing good guidance, strong requirements, all based on good security principles that they had already implemented internally. It is very hard for me to believe that a CA that applies good security principles/practices in one area (TLS Certificates) would not follow the same good security principles/practices in another (S/MIME).
Also, judging from the 4 closed security incidents handled by Trustcor until now (https://wiki.mozilla.org/CA/Closed_Incidents), this CA seems to have been responsive and handled security incidents meeting the expectations of this community.
I understand that it is an industry expectation for public CAs to have to face various challenges, including areas that are not directly related to Certificate issuance or Certificate management. It is also very difficult and stressful to handle multiple arguments in many areas including legal proceedings like company formations, headquarter transfers, data correlation, and all at the same time. I am sympathetic to any CA representative who has been in such position where the future of a business (and its employees) is being threatened. The burden is difficult to grasp. I take that into consideration when reading some of Trustcor's most recent spirited posts that may be taking the Mozilla Forum Etiquette to its limits.
I believe a good summary of the specific accusations and the factual evidence, along with the CA responses against these specific accusations (leaving out any personal attacks) would be helpful, because some of the messages in this thread were IMHO unnecessarily long and hard to follow.
Thank you,
Dimitris.
Matthew Hardeman
Nov 30, 2022, 1:59:06 PM11/30/22
to Dimitris Zacharopoulos, dev-secur...@mozilla.org
On Wed, Nov 30, 2022 at 12:22 PM Dimitris Zacharopoulos <ji...@it.auth.gr> wrote:
FWIW, I worked several times with Trustcor's representatives within the Server Certificate WG of the CA/Browser Forum, and more closely at the Network Security Subcommittee (now a separate Working Group). One particular Trustcor representative was very actively working with the rest of the subcommittee on improving the network security requirements and raise the bar for all CAs, providing good guidance, strong requirements, all based on good security principles that they had already implemented internally. It is very hard for me to believe that a CA that applies good security principles/practices in one area (TLS Certificates) would not follow the same good security principles/practices in another (S/MIME).
Also, judging from the 4 closed security incidents handled by Trustcor until now (https://wiki.mozilla.org/CA/Closed_Incidents), this CA seems to have been responsive and handled security incidents meeting the expectations of this community.
I'm merely an interested relying party of the WebPKI ecosystem. While there has been much brought to light that potentially paints some of those who are or were involved with Trustcor in a negative light, Dimitris' comments are interesting in providing further context to the organization's participation in the ecosystem.
Something that yet again concerns me in this discussion is an issue that I touched on previously in the discussions related to Dark Matter: that unless the program is requiring transparency as to corporate governance and management/operations authority, and establishing a basis for trust and accountability at the level of those individuals empowered by participation in the program, I believe we will continue to see these subjective trust decisions again and again. Ref: https://groups.google.com/g/mozilla.dev.security.policy/c/nnLVNfqgz7g/m/CY95HQA3AQAJ
As Kathleen acknowledged (at https://groups.google.com/g/mozilla.dev.security.policy/c/nnLVNfqgz7g/m/LPCGngLxBwAJ), the decision in the Dark Matter inclusion discussion did represent a shift in decisioning in a program, with a view to a more subjective take on CA inclusion.
I once again humbly submit that I believe the executive and operational management teams of the CAs in the programs should be required to submit to the root program personal attestations as to their position and authority along with a commitment to inform the program promptly if anything has altered or replaced their authority. I believe there should be an explicit understanding that failures by such person(s) would be held against such person(s) individually and would bar their involvement at other trusted CAs for an indefinite period.
I yet again advocate for a measurable standard for holding CAs accountable at the executive management / operations level with costs taxed upon those persons who have made commitments to the program and failed to honor them.
It seems likely to me that one or more presently included CA could be reasonably described as owned by Blackrock or Vanguard. Much of the world is, with those institutions' funds exercising control on behalf of the retiree funds they've been entrusted with. Those entities also own/control some less savory things. Yet we don't hold those common ownership concerns against program participants. And yet, I think we'd all want to know if the former manager of WoTrust were now an admin at any trusted CA?
Kathleen Wilson
Nov 30, 2022, 5:01:21 PM11/30/22
to dev-secur...@mozilla.org
All,
I appreciate the thoughtful and constructive input that has been provided in this discussion.
Based on the findings that were shared in this discussion thread and the responses from Trustcor’s Vice President of CA Operations, we believe that the following statements directly pertain to TrustCor’s position as a CA in Mozilla’s Root Program and have not been disputed:
Measurement Systems is a company that has engaged in the distribution of an SDK containing malware to Android users. [1]
TrustCor operated a mail encryption product called MsgSafe which is operationally tied to its CA unit. Specifically
The same individual was responsible for the day to day operation of both TrustCor’s CA business and MsgSafe. They are listed on TrustCor’s website as the VP of TrustCor’s CA operations and the Director of Operations for MsgSafe. [2]
MsgSafe relies upon TrustCor’s role as an SMIME CA for its operation. [3]
MsgSafe is highlighted prominently in TrustCor’s own benefit statement of its inclusion in Mozilla’s Root Program. [4]
An early, unobfuscated version of the malware SDK produced by Measurement Systems was included in TrustCor’s MsgSafe beta Android application. [5]
Measurement Systems and TrustCor have in the past had shared corporate officers, operational control and technical integrations:
Measurement Systems and TrustCor shared corporate officers until 2021 (or later). [6]
Ian Abramowitz, was active in the operation of TrustCor as CFO and an officer of the companies which owned both TrustCor and Measurement Systems. [7]
A developer hired by Trustcor had unobfuscated access to the source code of Measurement System’s malware SDK and write access to the source code of the MsgSafe application and hosting environment. [8]
There is no evidence of TrustCor mis-issuing TLS or SMIME certificates.
There are suggestions of additional links between the companies whose factual basis has neither been fully substantiated nor refuted. For example, Ryan Abramowitz was previously the CEO of both TrustCor and Measurement Systems. Ryan’s LinkedIn profile previously listed: “Co-Founder / Digital Strategist TrustCor Systems · Jun 2013 - Dec 2016. And D&B (a reputable business records company) shows Ryan as CEO of Measurement Systems.
Certificate Authorities have highly trusted roles in the internet ecosystem and it is unacceptable for a CA to be closely tied, through ownership and operation, to a company engaged in the distribution of malware. Trustcor’s responses via their Vice President of CA operations further substantiates the factual basis for Mozilla’s concerns.
In line with our policies, Mozilla weighs the risks and benefits to end-user security when deciding whether a CA should be a member of our Root Program. Ordinarily, Mozilla would not directly evaluate the benefit of the CA owner’s other products when considering whether a CA should be a member of our Root Program. However, Trustcor’s quantifying value statement rests heavily on the value of MsgSafe which has suffered from a number of problematic behaviors [9] that undermine the value proposition of MsgSafe, and therefore undermine the purported benefits for the TrustCor CA to be a member of our Root Program.
Our assessment is that the concerns about TrustCor have been substantiated and the risks of TrustCor’s continued membership in Mozilla’s Root Program outweighs the benefits to end users.
In line with our earlier communication, we intend to take the following actions:
Set “Distrust for TLS After Date” and “Distrust for S/MIME After Date” to November 30, 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.
Remove those root certificates from Mozilla’s root store after the existing end-entity TLS certificates have expired.
If evidence is found that the CA has mis-used certificates or the CA backdates certificates to bypass the distrust-after settings, then we will remove the root certificates from Mozilla’s root store in an expedited timeline, without waiting for the end-entity TLS certificates to expire.
Mozilla will not accept cross-signing of the existing TrustCor root certificates by other root CA Operators in Mozilla’s root store. If TrustCor chooses to become a subordinate CA of another root CA Operator in Mozilla’s root store, then all domain and email address ownership verification and certificate issuance must be performed on the systems operated by the root CA Operator. I.e. The domain and email address ownership verification and certificate issuance must not be performed on systems operated by the TrustCor CA.
Mozilla would like to thank the researchers who brought this to our and the community’s attention, as well as the contributions from other members of the community.
Thanks,
Kathleen
References:
[1] As reported in the Wall Street Journal, April 2022: https://archive.ph/AuNOy.
[2] Rachel McPherson is listed as the Vice President of Operations, having “access-to and control-over the CA and CA Business Operations” in a company document submitted privately by Rachel to Mozilla. Press releases on TrustCor’s website list Rachel McPherson as MsgSafe.io’s Director of Operations, e.g. https://web.archive.org/web/20221108224150/https://trustcor.com/news/02052016.php.
[3] Rachel McPherson’s response to this thread on the 18th November 2022 states “MsgSafe.io
integrates with TrustCor’s S/MIME certificate API for issuance of S/MIME certificates”. Further, TrustCor’s quantifying value statement highlights that “While that might be achievable through partnership, as has been the case historically with S/MIME, business challenges and economics hinder widespread adoption which makes our continued root program membership absolutely critical.”
[4] TrustCor’s quantifying value statement, under the heading “What Kind of Benefits can Your CA provide to Mozilla?”.
[5] Technical analysis (1, 2) produced by Serge Egelman. The inclusion of the malware was acknowledged in Rachel McPherson’s initial response and follow up responses as well as providing further details on how it came to be included.
[6] The identical corporate officers were acknowledged in Rachel McPherson’s initial response and confirmed in a company document submitted privately by Rachel to Mozilla.
[7] Ian Abramowitz is described as the CFO of TrustCor on their website and Rachel McPherson’s initial response notes “They are strictly passive investors, with the exception of Ian Abramowitz”. In a company document submitted privately by Rachel to Mozilla, Ian Abramowitz signs an agreement with TrustCor on behalf of both CHIVALRIC HOLDING COMPANY LLC and FRIGATE BAY HOLDINGS LLC.
[8] See [5] and Rachel McPherson’s response on 21st November 2022, referencing findings from their software revision control system and their forensic investigation of the an1.msgsafe.io hostname and saved VM image.
[9] Including, but not limited to: 1) the malware SDK produced by Measurement Systems was included in MsgSafe’s beta Android application. [5] 2) For a period of time, user data was transmitted from MsgSafe’s beta Android application to a server operated by Trustcor, before being forwarded on to a third party. [10] 3) MsgSafe’s web application transmits user messages to MsgSafe’s servers in plaintext, even though MsgSafe is advertised as offering end to end encryption. [11]
[10] Rachel McPherson’s response on 21st November 2022, referencing TrustCor’s forensic investigation of the an1.msgsafe.io hostname and saved VM image.
[11] End to end encryption is widely understood to mean that only the sender and receiver of a communication should be able to read or modify the messages, excluding access by third parties which operate servers or other intermediary network services. MsgSafe’s website highlights the provision of end to end encryption, including the statement “MsgSafe.io cannot read your email.”. Technical investigations by members of the community (1, 2) confirm that in fact the webmail client transmits purportedly encrypted messages in plaintext to the server and that the server is able to recover the plaintext of those messages without the user’s password. Rachel McPherson’s initial response describes this behavior as intentional, noting: “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”.
Rachel McPherson
Nov 30, 2022, 8:24:26 PM11/30/22
to dev-secur...@mozilla.org
All,
While we are incredibly disappointed with this decision, we are not going to waste anyone's time with a response to the removal right now.
From a practical standpoint, Microsoft seems to have set the distrust date for TrustCor's roots to November 1, 2022 instead of November 30, 2022, which impacts over 1,200 customers who reasonably acquired a TLS certificate from TrustCor between November 1 and November 30. While immaterial to us in this group of readers and vendors, the distinction is important to these customers.
Microsoft gave us no advance notice of this decision and we have reached out to Microsoft directly ourselves, but in this public forum if any Microsoft employees can make this change to reasonably mirror Mozilla's decision, it would make a difference to these people.
Thank you,
Rachel
--
You received this message because you are subscribed to a topic in the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this topic, visit https://groups.google.com/a/mozilla.org/d/topic/dev-security-policy/oxX69KFvsm4/unsubscribe.
To unsubscribe from this group and all its topics, 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/62669320-d923-4339-b557-9e2bfe0f9f52n%40mozilla.org.
Kurt Seifried
Nov 30, 2022, 9:16:07 PM11/30/22
to Rachel McPherson, dev-secur...@mozilla.org
On Wed, Nov 30, 2022 at 6:24 PM Rachel McPherson <rac...@trustcor.ca> wrote:
All,While we are incredibly disappointed with this decision, we are not going to waste anyone's time with a response to the removal right now.From a practical standpoint, Microsoft seems to have set the distrust date for TrustCor's roots to November 1, 2022 instead of November 30, 2022, which impacts over 1,200 customers who reasonably acquired a TLS certificate from TrustCor between November 1 and November 30. While immaterial to us in this group of readers and vendors, the distinction is important to these customers.Microsoft gave us no advance notice of this decision and we have reached out to Microsoft directly ourselves, but in this public forum if any Microsoft employees can make this change to reasonably mirror Mozilla's decision, it would make a difference to these people.
I'm curious, what thought process leads you to believe that Microsoft is answerable to you? Can you please explain your reasoning here?
Thank you,Rachel
Dustin Hollenback
Nov 30, 2022, 9:23:28 PM11/30/22
to Kurt Seifried, Rachel McPherson, dev-secur...@mozilla.org
Hello,
I do not represent the Microsoft Trusted Root Program, but did pass along the message to the appropriate team.
Regards,
Dustin
From: 'Kurt Seifried' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Sent: Wednesday, November 30, 2022 4:15:26 PM
To: Rachel McPherson <rac...@trustcor.ca>
Cc: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: [EXTERNAL] Re: concerns about Trustcor
Sent: Wednesday, November 30, 2022 4:15:26 PM
To: Rachel McPherson <rac...@trustcor.ca>
Cc: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: [EXTERNAL] Re: concerns about Trustcor
--
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/CABqVa38co%3DED5OETW9dvAn4N8HDWG6znQ%3D%3D6_BAxnA7%3DygTkUA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CABqVa38co%3DED5OETW9dvAn4N8HDWG6znQ%3D%3D6_BAxnA7%3DygTkUA%40mail.gmail.com.
Chris Clements
Dec 15, 2022, 8:10:42 AM12/15/22
to dev-secur...@mozilla.org, Kurt Seifried, Rachel McPherson, Dustin Hollenback
All,
We want to thank everyone involved, collectively, for participating in this public discussion. Considering multiple perspectives is valuable, and we always want to ensure we have a correct understanding of the details.
We want to emphasize Google includes or removes CA certificates within the Chrome Root Store as it deems appropriate for user safety. The selection and ongoing inclusion of CA certificates is done to enhance the security of Chrome and promote interoperability.
We considered this event to be an incident, as the originating activity identified potential impact to the CA’s integrity, trustworthiness, or compatibility. In evaluating incidents, Chrome uses the information in the public disclosure as the basis for evaluation. We always expect CA owners to be detailed, candid, timely, and transparent in describing their architecture, implementation, operations, and external dependencies as necessary for the Chrome Root Program and the public to evaluate the nature of the incident and the CA owner’s response.
The public discussion that ensued raised valid and direct questions, applicable to publicly-trusted root CA certificates. However, the discussion did not demonstrate why continued trust is justified given the concerns raised and the risk to user safety. 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.
Due to a loss of confidence in its ability to uphold these fundamental principles and to protect and safeguard Chrome’s users, certificates issued by TrustCor Systems will no longer be recognized as trusted by:
Chrome versions 111 (landing in Beta approximately February 9, 2023 and Stable approximately March 7, 2023) and greater; and
Older versions of Chrome capable of receiving Component Updates after Chrome 111’s Stable release date.
With these changes incorporated, users attempting to access a website that directly or transitively chains to one of the affected certificates below will find that it is not considered secure.
Affected Certificates (SHA-256 fingerprint):
d40e9c86cd8fe468c1776959f49ea774fa548684b6c406f3909261f4dce2575c
0753e940378c1bd5e3836e395daea5cb839e5046f1bd0eae1951cf10fec7c965
5a885db19c01d912c5759388938cafbbdf031ab2d48e91ee15589b42971d039c
These changes will be implemented via our existing mechanisms to respond to CA incidents via:
An integrated certificate blocklist, and
Removal of certificates included in the Chrome Root Store.
Beginning approximately February 9, 2023, website operators can preview these changes in Chrome 111 Beta. Website operators will also be able to preview the change sooner, using our Dev and Canary channels, while the majority of users will not encounter issues until the release of Chrome 111 to the Stable channel, approximately March 7, 2023. We may take further action, or accelerate the timeline described above, as additional information becomes available to us.
These changes will be integrated into the Chromium open-source project as part of a default build. Questions about the expected behavior in specific Chromium-based browsers should be directed to their maintainers.
These changes will be incorporated as part of the regular Chrome release process to ensure sufficient time for testing and replacing affected certificates by website operators. Information about timetables and milestones is available at https://chromiumdash.appspot.com/schedule.
Thank you
- Chris, on behalf of the Chrome Root Program
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/PH0PR00MB1134FCD34D4F0A43E8322A05F9149%40PH0PR00MB1134.namprd00.prod.outlook.com.
Kurt Seifried
Dec 20, 2022, 12:13:35 AM12/20/22
to Rachel McPherson, dev-secur...@mozilla.org
On Wed, Nov 30, 2022 at 6:24 PM Rachel McPherson <rac...@trustcor.ca> wrote:
All,While we are incredibly disappointed with this decision, we are not going to waste anyone's time with a response to the removal right now.
Will there be a response? I don't think it's a waste of time, understanding exactly what has happened and doing a post-mortem is critical, especially if, as you say, this was not done correctly.
There are also still numerous questions and concerns about the certification/ability of your auditor, especially in light of them being removed from a list of auditors.
Thank you,Rachel
Serge Egelman
Dec 23, 2022, 11:05:22 AM12/23/22
to Kurt Seifried, Rachel McPherson, dev-secur...@mozilla.org
Relatedly, Rachel, you repeatedly wrote that you have knowledge that other root CAs are controlled by state actors. For example, from 11/21:
In reading related reporting and blogging off-list, I need to address an elephant in the room. Apparently it may also come as a surprise to some readers that other root program members are in fact international governments, and some are also defense companies, or companies who are wholly-owned by defense companies and/or state-owned enterprises, meaning "businesses" that are completely owned or controlled by governments. Further, some of those governments are not free/democratic and in fact some have histories of tragic human rights violations.
Given that this likely is a surprise to many on this list (which you acknowledge), in the interest of transparency, I think it would be helpful to identify the CAs to which you were referring, so that there can be an open and frank discussion. Similarly, you wrote that after your team's "exhausted research," you concluded that many other email encryption products advertised as being "end-to-end" encrypted in fact aren't:
To address your concerns, based on our team's 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.
While less relevant to this particular list, I suspect many would still be interested in knowing which products are claiming to offer end-to-end encryption despite storing key material on servers (a design decision that many on this list would consider at odds with "end-to-end" encryption). In the interest of fostering trust and transparency, knowing which products are doing this is likely of interest to folks on this list (and more broadly).
Thanks and happy holidays,
serge
--
You received this message because you are subscribed to a topic in the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this topic, visit https://groups.google.com/a/mozilla.org/d/topic/dev-security-policy/oxX69KFvsm4/unsubscribe.
To unsubscribe from this group and all its topics, 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/CABqVa3_Nqk-8PPaTAtRQBEYLVwZ31%2BSULByyMeBOyhYbGFcvcA%40mail.gmail.com.
Rachel McPherson
Dec 23, 2022, 2:49:18 PM12/23/22
to Serge Egelman, Kurt Seifried, dev-secur...@mozilla.org
Serge,
You guys found an (easily-explained) domain name, and then basically assumed the rest, and used opinion, circumstantial evidence, conjecture, and fear-mongering to push readers of a mailing list to ignore the fact that we’ve never done anything wrong (mis-issuance, reading people’s emails, intentionally distributing malware, we’ve done none of those things). Answering factually and legally carefully also fell on deaf ears and the event was sensationalized because "scandal" has a larger audience than "security," and it always has. And now all it takes is "making up" a scandal which has the same effect.
For those reasons, and because I stated this such clearly and repeatedly in my public responses to you, we are not going to drag other companies' names through the mud and expose them to the same biased, unfair and business-damaging scrutiny you desire to keep your name in the media and draw attention to your company. Again, you want to defer to "university research" but in reality you posted all this stuff on your company blog and announced the link to the company blog entry everywhere. Anyway I’m not going to get into your personal saga, my point is simply that we didn’t get a fair experience and we won’t bring others into that unfair experience because we don’t believe it’s in the public interest.
Another factor I’ll offer is that even if a company (unlike us) is really owned by a defense contractor or government, it doesn’t mean they’re bad or that they’d misbehave. You’ve probably flown inside an aircraft or driven a car with systems developed by primarily-government-funded companies and enjoyed the safety and reliability they offer. So I’m saying that doesn’t make them bad, and especially in those cases, dragging them through the mud here would not serve the public interest. Also, maybe neither of us are any good at deciding what’s in the public interest, because this same group that you think cares about these things is the group that allowed the Chinese government to place certificates in the root store long after the "great firewall" was public and long after ample publication about their history of transgressions involving freedom of expression and human rights violations. And this stayed in place until there were obvious public violations by that Government. So I guess it’s a confusing topic and people don’t really care about the things you or I believe may be important. Or at least people’s priorities are different.
If you fellows are good at research, you’ll be able to figure all that out yourselves. I mean, the fact that you haven’t already done that and instead focused on just one company whose domain name you found doing something unrelated is silly and just further reinforces the point that you randomly came across a domain in other research and then mis-used that to motivate incorrect action upon us. The point is, many of these other cases are apparent and far more simple/straightforward, not to mention they’re actually "accurate" compared to your biased assessment of our company. But I encourage you NOT to do that research because (like us), they’ve not done anything wrong either so far as the public is concerned, otherwise they’d have been removed long ago, I imagine. This group was quick to remove us without reasonable evidence and with no history of wrongdoing, so I imagine they’d be even more quick to remove any company that showed any "real" evidence of actual wrongdoing.
In summary, if you want to go hunt these companies down, it’s easy if you’re studious, and it certainly doesn’t take any funded university research or company resources, it just takes the ability to use a search engine and look at various backgrounds and public documents. For all the reasons we already stated we’re not under any circumstances going to provide a list of our beliefs and opinions to cause inappropriate public scrutiny or to create bias against these organizations — that’s your business promotion strategy, not ours.
Happy holidays,
Rachel
Reply all
Reply to author
Forward
0 new messages