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 <http://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 <http://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 <[email protected]> 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: > <Screenshot 2022-11-08 at 8.18.04 AM.png> > https://twitter.com/msgsafeio/status/951217954158530560 > <https://twitter.com/msgsafeio/status/951217954158530560> > https://twitter.com/msgsafeio/status/933450622271217665 > <https://twitter.com/msgsafeio/status/933450622271217665> > > While that app is no longer in the Play Store, there are third-party app > archives that have made it publicly available. For example: > https://apkpure.com/msgsafe-io-unreleased/io.msgsafe.android/download?from=versions > > <https://apkpure.com/msgsafe-io-unreleased/io.msgsafe.android/download?from=versions> > > 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 > > > > On Tuesday, November 8, 2022 at 7:52:25 AM UTC-8 [email protected] > <http://ucalgary.ca/> wrote: > 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 > <http://trustcor.co/>, which redirected at > the time to the TrustCor CA's website. The NS records continue to point to > nsX.msgsafe.io <http://nsx.msgsafe.io/> [14], the same as trustcor.com > <http://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 <http://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 <http://hushemail.net/>, > protonmails.com <http://protonmails.com/>, and tutanoto.com > <http://tutanoto.com/>, > which shadow competing services, and which redirect users who visit them to > msgsafe.io <http://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 > <http://decoymail.com/>, which > Msgsafe users can request and which redirects to msgsafe.io > <http://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 > [email protected] <applewebdata://109ABCBC-9A39-4E6F-90E2-DA485AA2AFB0> > is linked to the domains rodneyjoffe.com <http://rodneyjoffe.com/>, > packetforensics.com <http://packetforensics.com/>, and decoymail.net > <http://decoymail.net/> [34]. Decoymail.net <http://decoymail.net/> currently > redirects > to msgsafe.io <http://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 <https://archive.ph/AuNOy> (archive of WSJ > article) > [2] https://opencorporates.com/companies/pa/2337L > <https://opencorporates.com/companies/pa/2337L> > [3] https://measurementsys.com/ <https://measurementsys.com/> > [4] https://vostrom.com/about.opp <https://vostrom.com/about.opp> > [5] https://www.whoxy.com/measurementsys.com > <https://www.whoxy.com/measurementsys.com> > [6] > https://cis.scc.virginia.gov/CommonHelper/DocumentStorageLocalFileget?DocumentId=1542553&sourceType=1 > > <https://cis.scc.virginia.gov/CommonHelper/DocumentStorageLocalFileget?DocumentId=1542553&sourceType=1> > [7] https://www.packetforensics.com/products.safe > <https://www.packetforensics.com/products.safe> > [8] > https://cis.scc.virginia.gov/CommonHelper/DocumentStorageLocalFileget?DocumentId=3476851&sourceType=1 > > <https://cis.scc.virginia.gov/CommonHelper/DocumentStorageLocalFileget?DocumentId=3476851&sourceType=1> > [9] > https://cis.scc.virginia.gov/CommonHelper/DocumentStorageLocalFileget?DocumentId=12188858&sourceType=1 > > <https://cis.scc.virginia.gov/CommonHelper/DocumentStorageLocalFileget?DocumentId=12188858&sourceType=1> > [10] https://opencorporates.com/companies/us_nv/E0518742015-4 > <https://opencorporates.com/companies/us_nv/E0518742015-4> > [11] https://opencorporates.com/officers/429641126 > <https://opencorporates.com/officers/429641126> > [12] https://opencorporates.com/officers/168691865 > <https://opencorporates.com/officers/168691865> > [13] https://www.whoxy.com/company/20189182 > <https://www.whoxy.com/company/20189182> > [14] https://www.whoxy.com/trustcor.co <https://www.whoxy.com/trustcor.co> > [15] https://www.whoxy.com/trustcor.com <https://www.whoxy.com/trustcor.com> > [16] https://trustcor.com/news/12012016.php > <https://trustcor.com/news/12012016.php> > [17] https://opencorporates.com/companies/pa/2326L > <https://opencorporates.com/companies/pa/2326L> > [18] https://opencorporates.com/companies/us_wy/2020-000946985 > <https://opencorporates.com/companies/us_wy/2020-000946985> > [19] > https://wyobiz.wyo.gov/Business/FilingDetails.aspx?eFNum=230084239221021253238165142128171020141144245186 > > <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/ > <https://www.wired.com/2010/03/packet-forensics/> > [21] https://trustcor.com/curacao <https://trustcor.com/curacao> > [22] > https://careers.jobscore.com/careers/trustcor/jobs/pki-security-engineer-cGlJUDydTp67nWF6LOxNC0?ref=rss&sid=68 > > <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 > > <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 > > <https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=c4f0e7c6-b310-4f5c-9907-8ecfad68366e> > [25] https://en.wikipedia.org/wiki/Hanlon%27s_razor > <https://en.wikipedia.org/wiki/Hanlon%27s_razor> > [26] https://www.whoxy.com/email/28298508 > <https://www.whoxy.com/email/28298508> > [27] https://trustcor.com/leadership <https://trustcor.com/leadership> > [28] https://decoymail.com <https://decoymail.com/> > [29] https://securitytrails.com/domain/decoymail.com/history/a > <https://securitytrails.com/domain/decoymail.com/history/a> (need to create > account) > [30] https://ecorp.azcc.gov/CommonHelper/GetFilingDocuments?barcode=00396622 > <https://ecorp.azcc.gov/CommonHelper/GetFilingDocuments?barcode=00396622> > [31] https://ecorp.azcc.gov/CommonHelper/GetFilingDocuments?barcode=02780271 > <https://ecorp.azcc.gov/CommonHelper/GetFilingDocuments?barcode=02780271> > [32] > https://ecorp.azcc.gov/CommonHelper/GetFilingDocuments?barcode=19121111449561 > <https://ecorp.azcc.gov/CommonHelper/GetFilingDocuments?barcode=19121111449561> > [33] > https://bizfileonline.sos.ca.gov/api/report/GetImageByNum/190229140180179177132144027172122051178173016008 > > <https://bizfileonline.sos.ca.gov/api/report/GetImageByNum/190229140180179177132144027172122051178173016008> > [34] https://www.whoxy.com/email/23160817 > <https://www.whoxy.com/email/23160817> > > -- > You received this message because you are subscribed to the Google Groups > "[email protected] <mailto:[email protected]>" > group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > 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 > > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/f5ab3236-2a16-42e6-b33d-6e142c1b49cen%40mozilla.org?utm_medium=email&utm_source=footer>. > <Screenshot 2022-11-08 at 8.18.04 AM.png><Screenshot 2022-11-08 at 8.26.43 > AM.png> -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/63F407D0-3AD3-40CB-912E-3E4C2ABD2CCC%40trustcor.ca.
signature.asc
Description: Message signed with OpenPGP
