SoylentNews

upstart [soylentnews.org] writes:

████ # This file was generated bot-o-matically! Edit at your own risk. ████

Wickr Is Dead [404media.co]:

If you open the encrypted messaging app Wickr Me today, you’ll be greeted with a line of red text: “Reconnecting…”

Below that, in white text over a black background, the app says “We’re having issues connecting to the Wickr Me network. If the problem persists, try restarting your app or contacting support.”

Closing and reopening the app will not work. There is no point in contacting support either. That’s because on December 31, 2023, Wickr Me, the free version of Wickr, was shut down entirely.

Wickr Me is no longer available to download on the Apple App Store or the Google Play Store. The app stopped accepting new users more than a year ago. And now, even current users cannot speak to one another.

So ends the story of an app that while never reaching the popularity of other encrypted messaging apps like Signal, nor those that later turned on end-to-end encryption for the masses like WhatsApp, nonetheless played an important role in the adoption of and debate around secure communications.

“Seeing if wickr dead,” I wrote to one contact on January 1. The message did not deliver.

Wickr started in 2012. Nico Sell, founder of Wickr, said in a talk a couple of years later [youtube.com] that “all of us have something to hide, either now or your future self.” Crucially, that came after the Edward Snowden whistleblower revelations of 2013, which saw a massive boom of secure messaging apps and the spread of encryption more generally.

I jumped on Wickr at the time for communicating with the odd source who used it. Wickr had a slick looking UI, even if it was a little cumbersome to use. One of its more unusual features was the ability to alert users when a recipient had taken a screenshot of their chat. Often people I was speaking to would do this and seemingly not realize, or care, that I had been informed. These chats became full of hackers, crooks, and sometimes people threatening me. Sigh, happy memories.

Then steadily, I found a very particular type of source used Wickr. While I spoke to tech employees leaking company secrets on Signal, Wickr was where I ended up chatting more with people connected to the world of drug trafficking. That included some people who sold encrypted phones to organized criminals. To be clear, some of these people also used Signal. But my interest especially piqued when I received a new message on Wickr from a new contact.

As years passed, and authorities started to clamp down on the dark net markets, where people accessed Amazon-like drug marketplaces typically using the Tor network, I noticed more Wickr users selling narcotics through the platform. I remember being added to huge groups chats with waves of users and the host selling cocaine, prescription pills, and much more. One participant at the time described Wickr along the lines of the new dark web. I think that title ultimately went to Telegram, where the broadcast channel style feature is incredibly popular with criminal hackers, fraudsters, and drug dealers.

In other cases, dealers direct-messaged individual users with their offers. I wasn’t the only person that saw this. Beyond voluminous [dailymail.co.uk]media reports [vice.com] and some studies [sciencedirect.com], 404 Media’s own Sam Cole told me that Wickr was her “first weed ordering app.” Her street dealer used it as part of their weed delivery service.

“It was so annoying to use,” Sam told me.

But how was a free app to make money? Part of the answer for Wickr at least ended up being with the U.S. government. In 2021, I reported that Customs and Border Protection (CBP) paid Wickr $700,000 [vice.com] for a number of Wickr licenses. In parallel to its free Wickr Me app, Wickr had developed an enterprise version that allowed governments or businesses to send encrypted messages to one another but still collect and audit messages if necessary. Later that year, I then reported [vice.com] that CBP planned to deploy Wickr across “all components” of the agency as part of a $900,000 contract. I have since obtained more documents about CBP’s purchase of Wickr licenses via the Freedom of Information Act (FOIA). I’ve uploaded them here [documentcloud.org] for posterity.

NBC News reported [nbcnews.com] that the National Archives and Records Administration was concerned about CBP’s use of Wickr “without appropriate policies and procedures governing its use.”

Wickr also has contracts with the Air Force and the Army too. Wickr offers another version of its product called Wickr RAM, which is specifically designed for warfighters. Here are some [documentcloud.org] Air Force documents I obtained too.

Wickr’s movement towards the government sphere manifested in other ways too. I revealed that In-Q-Tel, a nonprofit investment firm started by the Central Intelligence Agency (CIA), paid Wickr $1.6 million [vice.com]. 

That transformation from scrappy upstart to government contractor was solidified when Amazon Web Services acquired Wickr in June 2021 [vice.com]. I remember being shocked at the time and writing up the news as quickly as I could. What the hell was AWS going to do with an app that was becoming a hotbed for crime, at least in my anecdotal experience?

The answer was to shut it down entirely. After NBC News found in 2022 [nbcnews.com] that Wickr was linked to a string of child abuse cases, AWS announced it would stop accepting new users at the end of that year [wickr.com]. The company said it would then kill Wickr Me entirely on December 31, 2023.

The secure messaging world is very different to the one Wickr launched in more than ten years ago. Today mainstream platforms are turning on end-to-end encryption by default, with Facebook doing just that last month [fb.com]. The need for specialist apps like Wickr may be decreasing with certain groups. Maybe it’s even a good sign that Wickr has been shown the door.

Amazon did not respond to a request for comment.

buy-out-shut-down dept.

What It's Like When The FBI Asks You To Backdoor Your Software [pcmag.com]:

At a recent RSA Security Conference, Nico Sell was on stage announcing that her company—Wickr—was making drastic changes to ensure its users' security. She said that the company would switch from RSA encryption to elliptic curve encryption [wikipedia.org], and that the service wouldn't have a backdoor for anyone.

As she left the stage, before she'd even had a chance to take her microphone off, a man approached her and introduced himself as an agent with the Federal Bureau of Investigation. He then proceeded to "casually" ask if she'd be willing to install a backdoor into Wickr that would allow the FBI to retrieve information.

A Common Practice
This encounter, and the agent's casual demeanor, is apparently business as usual as intelligence and law enforcement agencies seek to gain greater access into protected communication systems. Since her encounter with the agent at RSA, Sell says it's a story she's heard again and again. "It sounds like that's how they do it now," she told SecurityWatch. "Always casual, testing, because most people would say yes."

The FBI's goal is to see into encrypted, secure systems [pcmag.com] like Wickr and others. Under the Communications Assistance for Law Enforcement Act (CALEA [wikipedia.org]) legislation, law enforcement can tap any phone in the US but they can't read encrypted communications. We've also seen how law enforcement have followed the lead of the NSA, and gathered data en-masse from cellphone towers [pcmag.com]. With the NSA reportedly installing backdoors onto hardware sitting in UPS facilities [youtube.com] and allegedly working to undermine cryptographic standards [pcmag.com], it's not surprising that the FBI would be operating along similar lines.

The Difference
It was clear that the FBI agent didn't know who he was dealing with, because Sell did not back down. Instead, she lectured him on topics ranging from the First and Fourth Amendments to the Constitution, to George Washington's creation of a Post Office in the US. "My ancestor was a drummer boy under Washington," Sell explained. "Washington thought it was very important to have freedom of information and private correspondence without government surveillance."

Her lecture concluded, she proceeded to grill the agent. "I asked if he had official paperwork for me, if this was an official request, who his boss was," said Sell. "He backed down very quickly."

Though she didn't budge for the agent, Sell makes it clear that surveillance and security is a complicated issue. "Ten years ago, I'd have said yes," said Sell. "Because if law enforcement asks you to catch bad guys, who wouldn't want to help?"

The difference now, she explained, was her experiences at BlackHat. Among those, Sell pointed to a BlackHat event where Thomas Cross demonstrated [blackhat.com] how to break into lawful intercept machines—or wiretaps. "It was very clear that a backdoor for the good guys is always a backdoor for the bad guys."

How To Be A Good Guy
"I'm not against helping law enforcement, but the most important thing to me is protecting my friends and family the best way I know how," said Sell. She suggested that the NSA and other agencies go back to a model where individuals are targeted, instead of monitoring all communications and sorting it out later. "There are plenty of ways to track people without trampling human rights," she said.

As an example of how to do security right, Sell unsurprisingly pointed to Wickr. She said that her company does not hold the encryption keys to decrypt users' messages, or see their identities. That way, should Wickr be compelled to hand over data from a court order, investigators will only find junk. And in addition to employing who Sell calls the "best crypto people," Sell said that individual messages are bound to their intended device. "Even in 20 years or 100 years, if the NSA miraculously breaks these [encryption] equations, they still wouldn't be able to read these messages."

It's clear that for Sell, this is about more than good security. "I'm doing the right thing here, and it's the right thing for them, too," she said. "I'm not afraid of them."

Image via Flickr user Marco Monetti [flickr.com]

Like What You're Reading?

Sign up for SecurityWatch newsletter for our top privacy and security stories delivered right to your inbox.

EmailSign Up

This newsletter may contain advertising, deals, or affiliate links. Subscribing to a newsletter indicates your consent to our Terms of Use [ziffdavis.com] and Privacy Policy [ziffdavis.com]. You may unsubscribe from the newsletters at any time.

Thanks for signing up!

Your subscription has been confirmed. Keep an eye on your inbox!

Sign up for other newsletters [pcmag.com]

Secret Documents Show Which Message Apps Are the Most FBI-Proof [reason.com]:

|

|

|

|

|

GitHub - WickrInc/wickr-crypto-c: An implementation of the Wickr Secure Messaging Protocol in C [github.com]:

wickr-crypto-c About

wickr-crypto-c is an implementation of the Wickr Secure Messaging Protocol in C, which provides a platform for secure communications across all Wickr products.

A white paper describing details of the protocol and its security model can be found here [wickr.com]. A markdown version of the white paper can also be found in the wiki.

Please Note

This crypto lib is released for public review for educational, academic, and code audit purposes only (*this is not an open source license, more on license here [github.com]). We strongly believe in the value of the open source movement and are looking forward to collaborating with the community on this and other future projects, including under the GNU license.

Issue Reporting

Please keep the issue tracker of this repo limited to code level bugs found in the implementation of the protocol as described in the white paper. Pull requests are always welcome!

Any questions regarding the protocol itself (i.e: crypto design ideas, suggestions, high-level conceptual critique) can be be directed at github@wickr.com [mailto].

For all other security issues, please contact Wickr’s bug bounty program here [wickr.com].

Goals

Starting with this crypto lib, Wickr is opening its source code to its customers, partners, and the larger community—here is why:

• Transparency: It is important for us to share with Wickr Professional customers how the Wickr crypto is designed in a way that is easy to review

• Security: While Wickr is not a new tool for peer-to-peer encrypted ephemeral messaging, this protocol represents a new generation crypto in Wickr products. We are confident that the GitHub community will have ideas and constructive suggestions on how we can further evolve our protocol to make it stronger against emerging attacks (and, of course, fix a bug or two)

• Team: The core crypto team has long been a strong internal advocate for opening the source code, and they have finally prevailed ☺. Joking aside, we believe it is a good time in Wickr’s development as a company to share the core crypto with the public in addition to the regular external security audits that all Wickr products undergo

Features

A faithful implementation of the Wickr protocol enables confidentiality of message content in transit and in storage. It powers the following capabilities:

• End-to-End Encryption – Message encryption keys are available only within Wickr clients and are not disclosed to network attackers or Wickr server operators;
• Perfect Forward Secrecy – Old message content is not compromised if the long-term key of a user or device is compromised. Backward secrecy is also provided against passive adversaries.

Crypto Engine [github.com]

A struct that represents a set of cryptographic functions that the library can utilize. The goal of its design is expose security primitives in an organized and generic way. This allows for the protocol implementation to not be bound to a single dependency such as OpenSSL. It is also designed to be easy to use, and to provide a high level interface that enforces best practices.

OpenSSL Crypto Suite

The current default implementation of crypto engine is based primarily off the EVP interface from OpenSSL 1.1.0

Supported Algorithms

• AES 256 GCM
• AES 256 CTR
• SHA256
• SHA384
• SHA512
• ECDH (NIST P521 Curve)
• ECDSA (NIST P521 Curve)
• HKDF
• HMAC
• SCRYPT
• BCRYPT

Protocol [github.com]

Low level implementation of the encoding and decoding of encrypted message packets

Context [github.com]

High level interface for managing an endpoint that can send and receive encrypted message packets. This is the way the front end client apps integrate with the crypto library.

Features

• Randomly generated endpoint with new keys
• Secure import/export of key material encrypted with a random recovery key
• Secure import/export of recovery keys with scrypt
• Generation of signed messaging key pairs
• Message packet encoding / decoding

Stream Cipher [github.com]

A state machine to help with the encryption of continuous streams of data. This is used for encoding / decoding data within a live voice / video stream between users on a 1:1 or conference call. It is seeded with a key that was negotiated prior by the messaging protocol. Each stream of data within a particular call has its own stream_cipher object to hold it's state.

Features

• Understanding of position within a sequence of protected data, to assist with key rotation done via symmetric ratcheting
• Generation of IV's using a sequence number and a private random seed to prevent collisions
• Support for authenticating additional information during serialization using AES-GCM + AAD
• Rotation of key material and key rotation seed at a predetermined interval (defaults to 512 packets)

Steps to build and test

The library is built with CMake on all platforms. Currently iOS, Android, Windows, macOS, and Linux are supported. See platform specific instructions and CMake options below for more information

macOS macOS Requirements

• CMake 3.1 or higher
• xcode 9.0
• xcode command line tools
• OpenSSL = 1.0.2 development package from homebrew (optional)

macOS CMake Configuration

The macOS build can be configured follows:

mkdir build cd build cmake -DBUILD_OPENSSL=true -DCMAKE_INSTALL_PREFIX=USER_INSTALL_LOCATION ../

If a development version of OpenSSL = 1.0.2 is on the system, the BUILD_OPENSSL option can be eliminated in favor of OPENSSL_ROOT_DIR

Windows Windows Requirements

• CMake 3.1 or higher
• You will need to have an installation of NASM (http://www.nasm.us/doc/nasmdoc1.html [www.nasm.us])
• Microsoft Visual Studio version 2015 is the current CMake Generator that is officially supported, although other windows CMake generators may also work

Windows CMake Configuration

The windows build can be configured using the MSVC generator as follows

mkdir build cd build cmake -DBUILD_OPENSSL=true -DCMAKE_INSTALL_PREFIX=USER_INSTALL_LOCATION -G "Visual Studio 14 2015" ..Building, Installing, and Testing (Windows)

The windows build can't be generated with the standard make command documented below. Instead it relies on the Visual Studio commands directly as follows:

msbuild WickrCryptoC.sln /p:Configuration=Release

To run tests call the following from the build directory

ctest

To install the library to the configured install prefix

msbuild INSTALL.vcxproj /p:Configuration=ReleaseLinux Linux Requirements

• CMake 3.1 or higher
• Clang
• OpenSSL = 1.0.2 (Optional)

Linux CMake Configuration

The linux build can be configured using the standard CMake flow with a few options

mkdir build cd build cmake -DBUILD_OPENSSL=true \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=USER_INSTALL_LOCATION ../

If a development version of OpenSSL = 1.0.2 is on the system, the BUILD_OPENSSL option can be eliminated

Android

Currently, the CMake project has been tested on armeabi-v7a, armeabi and x86 ABIs. Running tests for Android is currently not directly supported by CMake, although the test target can be compiled and uploaded to a device via ADB manually

Android Requirements

• CMake 3.9 or higher
• Android NDK (r14b is recomended)

Android CMake Configuration

The default Android API level is 18 as defined in the Toolchain-Android.cmake file in the root directory. Modifying this is currently not recomended

To configure CMake for building the Android NDK target you can do the following:

mkdir build cd build cmake -DCMAKE_TOOLCHAIN_FILE=../Toolchain-Android.cmake \ -DCMAKE_ANDROID_NDK=USER_NDK_LOCATION \ -DBUILD_OPENSSL=true \ -DCMAKE_ANDROID_ARCH_ABI=OUTPUT_ARCH_AB \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=USER_INSTALL_LOCATION ../iOS

A provided toolchain can support simulator and device builds for iOS 9.0 as fat libraries. x86 + x86_64 fat libraries are generated for the simulator and armv7, armv7s, and arm64 fat libraries are created for the device

iOS Requirements

• CMake 3.1 or higher
• XCode 8.0 or higher
• XCode command line tools

iOS CMake Configuration

To configure CMake for building the iOS SDK target you can do the following:

cmake -DCMAKE_TOOLCHAIN_FILE=../Toolchain-iOS.cmake \ -DBUILD_OPENSSL=true \ -DCMAKE_BUILD_TYPE=Release \ -DIOS_PLATFORM=OS|SIMULATOR \ -DIOS_DEPLOYMENT_TARGET=9.0 \ -DCMAKE_INSTALL_PREFIX=USER_INSTALL_LOCATION ../CMake Options CMake OptionDescriptionTargetBUILD_OPENSSLTells CMake to build OpenSSL 1.1.0 as part of the build processAllOPENSSL_AUTO_BUILDTells CMake to build OpenSSL if it fails to automatically find it in the target system. Overridden by BUILD_OPENSSL. TRUE by default on macOS, iOS, Android and Windows, FALSE by default on other systemsAllOPENSSL_ROOT_DIRTells CMake to look for prebuilt OpenSSL development files at a specified locationAllFIPSTells CMake to build OpenSSL in FIPS mode. This will force BUILD_OPENSSL to trueAllCMAKE_BUILD_TYPERelease or Debug buildAllCMAKE_INSTALL_PREFIXThe location to install headers and built libraries when make install is calledAllCMAKE_TOOLCHAIN_FILETells CMake to target the Android NDK cross compile toolchainAndroid / iOSCMAKE_ANDROID_ARCH_ABIThe ABI to target for this build. Supported values are armeabi, armeabi-v7a, x86AndroidCMAKE_ANDROID_NDKThe location of the root directory of an NDK installationAndroidIOS_PLATFORMSet to OS for armv7,armv7s,arm64 builds or SIMULATOR for x86,x86_64 buildsiOSIOS_DEPLOYMENT_TARGETThe minimum target for the iOS build (9.0+ Recomended)iOSBUILD_TESTSTells CMake to buid tests (off by default)AllBuilding, Installing, and Testing

Note: For windows builds see the windows section

To build the library

make

To install the library to the configured install prefix

make install

To run the bundled test target (macOS, Windows, Linux). Requires -DBUILD_TESTS=ON when configuring build.

make testLegal License

Copyright © 2012-2017 Wickr Inc. All rights reserved.

This code is being released for EDUCATIONAL, ACADEMIC, AND CODE REVIEW PURPOSES ONLY. COMMERCIAL USE OF THE CODE IS EXPRESSLY PROHIBITED. For additional details, please see the LICENSE.

THE CODE IS MADE AVAILABLE "AS-IS" AND WITHOUT ANY EXPRESS OR IMPLIED GUARANTEES AS TO FITNESS, MERCHANTABILITY, NON-INFRINGEMENT OR OTHERWISE. IT IS NOT BEING PROVIDED IN TRADE BUT ON A VOLUNTARY BASIS ON BEHALF OF THE AUTHOR’S PART FOR THE BENEFIT OF THE LICENSEE AND IS NOT MADE AVAILABLE FOR CONSUMER USE OR ANY OTHER USE OUTSIDE THE TERMS OF THIS LICENSE. ANYONE ACCESSING THE CODE SHOULD HAVE THE REQUISITE EXPERTISE TO SECURE THEIR SYSTEM AND DEVICES AND TO ACCESS AND USE THE CODE FOR REVIEW PURPOSES ONLY. LICENSEE BEARS THE RISK OF ACCESSING AND USING THE CODE. IN PARTICULAR, AUTHOR BEARS NO LIABILITY FOR ANY INTERFERENCE WITH OR ADVERSE EFFECT THAT MAY OCCUR AS A RESULT OF THE LICENSEE ACCESSING AND/OR USING THE CODE ON LICENSEE’S SYSTEM.

Cryptography Notice

This distribution includes cryptographic software. The country in which you currently reside may have restrictions on the import, possession, use, and/or re-export to another country, of encryption software. BEFORE using any encryption software, please check your country's laws, regulations and policies concerning the import, possession, use, and re-export of encryption software, to see if this is permitted. See http://www.wassenaar.org/ [wassenaar.org] for more information.

The U.S. Government Department of Commerce, Bureau of Industry and Security (BIS), has classified this software as Export Commodity Control Number (ECCN) 5D002.C.1, which includes information security software using or performing cryptographic functions with asymmetric algorithms. The form and manner of this distribution makes it eligible for export under the License Exception ENC Technology Software Unrestricted (TSU) exception (see the BIS Export Administration Regulations, Section 740.13) for both object code and source code.

Original Submission