concerns about Trustcor

32764 views
Skip to first unread message

Prof. Reardon

unread,
Nov 8, 2022, 10:52:25 AMNov 8
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

Serge Egelman

unread,
Nov 8, 2022, 11:38:07 AMNov 8
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:
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:
Screenshot 2022-11-08 at 8.18.04 AM.png

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

unread,
Nov 8, 2022, 1:03:35 PMNov 8
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:

  • 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.

  1. 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

  2. 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.

  3. 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.

  4. 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

unread,
Nov 8, 2022, 1:58:03 PMNov 8
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>

signature.asc

Ryan Dickson

unread,
Nov 9, 2022, 8:10:41 AMNov 9
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



Filippo Valsorda

unread,
Nov 9, 2022, 9:56:01 AMNov 9
to dev-secur...@mozilla.org
2022-11-09 14:10 GMT+01:00 'Ryan Dickson' via dev-secur...@mozilla.org <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

unread,
Nov 11, 2022, 7:26:48 PMNov 11
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:
  1. 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.”
    1. 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. 
    2. 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?
  2. 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/).
    1. Where is the Ontario Headquarters of TrustCor, as referenced by the corpus of audit statements representing TrustCor?
  3. 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

Rachel McPherson

unread,
Nov 18, 2022, 2:14:02 PMNov 18
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?":

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)”:

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 "The MsgSafe product relies in part on SMIME certificates issued by TrustCor (MsgSafe Website)”:

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.

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."

——————————— 

In Response to Ryan’s (Google) Additional Observations:
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.”:

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.nethopto.orgsytes.netzapto.orgmyddns.meservebeer.commyftp.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:

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.ioMsgSafe.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 SD[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.netprotonmails.com, and tutanoto.comwhich 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.compacketforensics.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.

signature.asc
TC_CA-Quantifying_Value_Statement.pdf
TC_Wylie_Letter_Attach.pdf
A143A9A0-CC51-41E5-9EFC-9B9009AD35ED[1].png

Watson Ladd

unread,
Nov 18, 2022, 4:05:24 PMNov 18
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-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.

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.


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 "The MsgSafe product relies in part on SMIME certificates issued by TrustCor (MsgSafe Website)”:

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 SD[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.netprotonmails.com, and tutanoto.comwhich 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.compacketforensics.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

unread,
Nov 18, 2022, 7:59:52 PMNov 18
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

Prof. Reardon

unread,
Nov 18, 2022, 10:03:44 PMNov 18
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:

I must make a very important correction to the citations and their juxtaposition in the origin posting. In writing:

"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]"

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
Holdings LLC [18] listed as its manager [19]"

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
-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

 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

 publicly on behalf of Packet Forensics in the context of a Wired article about
 subverting SSL [20].
 
posting.txt
posting.fixed.txt
diff.txt

Prof. Reardon

unread,
Nov 20, 2022, 11:54:21 AMNov 20
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

unread,
Nov 20, 2022, 5:56:19 PMNov 20
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="

As 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/

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/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.
Research Director, Usable Security & Privacy
International Computer Science Institute (ICSI)

Research Scientist, Electrical Engineering and Computer Sciences (EECS)
University of California, Berkeley
*/

Rachel McPherson

unread,
Nov 21, 2022, 11:11:37 AMNov 21
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.

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'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,


signature.asc

Kathleen Wilson

unread,
Nov 22, 2022, 5:02:16 PMNov 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

Prof. Reardon

unread,
Nov 22, 2022, 5:57:46 PMNov 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
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

unread,