It's hard to say -- in general most of these start-ups (and even more established companies) simply don't know how difficult it is to do crypto properly. They also don't know that security-through-obscurity is a bad thing. Many honestly believe that rolling their own crypto and keeping everything proprietary has to be better because, after all, if the bad guys don't know how you're doing the crypto it must be more secure. So until I see something pointing in another direction, I'm willing to grant them the benefit of the doubt. But it still falls into the category of not doing due diligence when planning your project, so I'm not going to shed any tears over their troubles, either.

These guys can't even build a good lock.
https://www.ftc.gov/system/files/documents/cases/192_3011_tapplock_complaint.pdf

12. Despite these claims, Respondent’s smart locks were not secure. In June 2018, three separate security researchers identified critical physical and electronic vulnerabilities with Respondent’s smart locks.
13. With respect to physical security, one security researcher demonstrated that he could unlock some of Respondent’s smart locks within a matter of seconds, simply by unscrewing the back panel.

Physically easily to compromise (screwdriver) CHECK, vulnerable to man in the middle attacks CHECK, poorly designed web site CHECK, motor not shielded from magnetic manipulation CHECK, etc.

 

But rolling your own crypto package is such a well known bad thing that is so routinely ignored, perhaps it will take a company going down in flames because of doing so for others to finally start getting the hint.

By roll your own, do you mean that they actually wrote their own ciphers? If so, that sounds crazy implausible to me. What company, especially a start-up, would dedicate precious development resources on a very hard problem that's already been solved? Companies don't write their own relational database engine, unless they have a really good reason to.

 

Companies don't write their own relational database engine, unless they have a really good reason to.

the good reason most probably being to save a buck or two...

 

the good reason most probably being to save a buck or two...

That's my point, if you want to save money, you don't roll your own crypto cipher, you use one of the well-established and already implemented algorithms.

 

By roll your own, do you mean that they actually wrote their own ciphers? If so, that sounds crazy implausible to me. What company, especially a start-up, would dedicate precious development resources on a very hard problem that's already been solved? Companies don't write their own relational database engine, unless they have a really good reason to.

https://forum.allaboutcircuits.com/threads/privacy-lost.131989/post-1494868

The posted article from citizenlab misused roll your own IMO, what they rolled, tripped and fell on was the implementation. As a implementation end result, that's just as bad or worse as it can easily mislead.
It looks like they used a version of AES128 as the base cipher but used the insecure ECB mode to bypass the key distribution problem in video modes.

https://www.schneier.com/blog/archives/2020/04/security_and_pr_1.html

They're also lying about the type of encryption. On 4/3, Citizen Lab reported

Zoom documentation claims that the app uses "AES-256" encryption for meetings where possible. However, we find that in each Zoom meeting, a single AES-128 key is used in ECB mode by all participants to encrypt and decrypt audio and video. The use of ECB mode is not recommended because patterns present in the plaintext are preserved during encryption.
The AES-128 keys, which we verified are sufficient to decrypt Zoom packets intercepted in Internet traffic, appear to be generated by Zoom servers, and in some cases, are delivered to participants in a Zoom meeting through servers in China, even when all meeting participants, and the Zoom subscriber's company, are outside of China.

I'm okay with AES-128, but using ECB (electronic codebook) mode indicates that there is no one at the company who knows anything about cryptography.

 

The posted article from citizenlab misused roll your own IMO, what they rolled, tripped and fell on was the implementation. As a implementation end result, that's just as bad or worse as it can easily mislead.
It looks like they used a version of AES128 as the base cipher but used the insecure ECB mode to bypass the key distribution problem in video modes.

Agreed, that's an entirely different form of incompetence than rolling your own cipher. But now it makes more sense, as it's easy to imagine the developers, under time pressure to meet marketing's "encrypted video" spec, taking such shortcuts.

 

Agreed, that's an entirely different form of incompetence than rolling your own cipher. But now it makes more sense, as it's easy to imagine the developers, under time pressure to meet marketing's "encrypted video" spec, taking such shortcuts.

What a lot of people misunderstand is most secure systems are not broken at the cipher level. It's pretty easy to make unbreakable encryption in the abstract sense (OTP). The problem has been and will continue to be key distribution that are solved with systems like PK crypto. https://en.wikipedia.org/wiki/Public-key_cryptography

Before the mid-1970s, all cipher systems were using symmetric key algorithms, in which the same cryptographic key is used with the underlying algorithm by both the sender and the recipient, who must both keep it secret. Of necessity, the key in every such system had to be exchanged between the communicating parties in some secure way prior to any use of the system – a secure channel. This requirement is never trivial and very rapidly becomes unmanageable as the number of participants increases, or when secure channels aren't available for key exchange, or when, (as is sensible cryptographic practice), keys are frequently changed. In particular, if messages are meant to be secure from other users, a separate key is required for each possible pair of users.

By contrast, in a public key system, the public keys can be disseminated widely and openly, and only the private key needs to be kept secure by its owner.

 

By roll your own, do you mean that they actually wrote their own ciphers? If so, that sounds crazy implausible to me. What company, especially a start-up, would dedicate precious development resources on a very hard problem that's already been solved? Companies don't write their own relational database engine, unless they have a really good reason to.

From your perspective, the notion that the people starting these companies might do something like this seems insane, but that's because you are assuming that they know better. There have been numerous instances where they did just that (came up with their own proprietary algorithms), typically because they don't see it as a very hard problem -- some view it literally as child's play because they remember passing "secret" messages around when they were kids that no one was able to break. Sometimes it's even been seen as a marketing plus to make their products and technology sounds more impressive (though you don't hear that as much as you once did).

But more often then not what they are "rolling" is all or part of the implementation for one reason or another. So the core algorithm may be just fine, but their implementation fails to recognize that attackers almost never go after the encryption algorithm itself any more, but rather the side channels created by weak implementations. Such seemingly simple and innocent things as message padding can open holes into the system. But even if you use good off-the-shelf implementations for the core functions, companies will build their own protocols using those implementations failing to recognize that secure communications has to include the security of those protocols, too. One recurring area in which this pops up is key distribution. For speed and efficiency, particularly in any kind of streaming application, you need to use symmetric algorithms. But the Achilles heal of symmetric crypto is key distribution and doing that well is difficult, particularly if you aren't going to put forth the effort to (properly) use asymmetric crypto to do it. So many of these custom protocols use some "clever" and "ingenious" way to distribute the symmetric keys that are extremely weak.

We have to keep in mind the limited knowledge base that anyone brings to any problem. Unfortunately, it is not uncommon for people developing these products to simply not be aware of anything about crypto beyond their grade school experiences. Even people involved in the field can have blinders. When we were giving a briefing to a bunch of senior engineering and technical GPS folks (including the chief scientist for GPS) we got blank stairs as soon as we mentioned asymmetric cryptography. None of them had ever heard of it. So we took a step back and gave a five minute intro to the concepts and these people really showed that they were in no way stupid, just naive, because they immediately started brainstorming and reinvented (conceptually) about three decades of cool things you could do including authentication and digital signatures and digital certificates and certificate authorities before we could get a word in edgewise to point out that that had all been done already. We were shocked that these folks had never heard of asymmetric crypto, but in reflection it wasn't as odd as it first appeared. In their world they are currently stuck with symmetric encryption to protect the physical channel, so if you have to pay that piper anyway, there's no compelling reason to not use symmetric encryption for everything. But that then begets a self-fulfilling prophecy because now symmetric encryption is used for everything because that's the only thing you know about.

 

https://www.usenix.org/conference/usenixsecurity20/presentation/ender

Abstract:
The security of FPGAs is a crucial topic, as any vulnerability within the hardware can have severe consequences, if they are used in a secure design. Since FPGA designs are encoded in a bitstream, securing the bitstream is of the utmost importance. Adversaries have many motivations to recover and manipulate the bitstream, including design cloning, IP theft, manipulation of the design, or design subversions e.g., through hardware Trojans. Given that FPGAs are often part of cyber-physical systems e.g., in aviation, medical, or industrial devices, this can even lead to physical harm. Consequently, vendors have introduced bitstream encryption, offering authenticity and confidentiality. Even though attacks against bitstream encryption have been proposed in the past, e.g., side-channel analysis and probing, these attacks require sophisticated equipment and considerable technical expertise.
In this paper, we introduce novel low-cost attacks against the Xilinx 7-Series (and Virtex-6) bitstream encryption, resulting in the total loss of authenticity and confidentiality. We exploit a design flaw which piecewise leaks the decrypted bitstream. In the attack, the FPGA is used as a decryption oracle, while only access to a configuration interface is needed. The attack does not require any sophisticated tools and, depending on the target system, can potentially be launched remotely. In addition to the attacks, we discuss several countermeasures.

3.5 Wrap-Up: What Went Wrong?
These two attacks show again that nowadays, cryptographic primitives hold their security assumptions, but their embedding in a real-world protocol is often a pitfall. Two issues lead to the success of our attacks: First, the decrypted data are interpreted by the configuration logic before the HMAC validates them. Generally, a malicious bitstream crafted by the
attacker is checked at the end of the bitstream, which would prevent an altered bitstream content from running on the fabric. Nevertheless, the attack runs only inside the configuration
logic, where the command execution is not secured by the HMAC.
Second, the HMAC key KHMAC is stored inside the encrypted bitstream. Hence, an attacker who can circumvent the encryption mechanism can read KHMAC and thus calculate the
HMAC tag for a modified bitstream. Further, they can change KHMAC, as the security of the key depends solely on the confidentiality of the bitstream. The HMAC key is not secured by
other means. Therefore, an attacker who can circumvent the encryption mechanism can also bypass the HMAC validation.

Looks like another implementation bug.

 

https://www.forbes.com/sites/thomas...oples-private-web-and-phone-use/#6fcfa6981b2a

When he looked around the Web on the device’s default Xiaomi browser, it recorded all the websites he visited, including search engine queries whether with Google or the privacy-focused DuckDuckGo, and every item viewed on a news feed feature of the Xiaomi software. That tracking appeared to be happening even if he used the supposedly private “incognito” mode.

The device was also recording what folders he opened and to which screens he swiped, including the status bar and the settings page. All of the data was being packaged up and sent to remote servers in Singapore and Russia, though the Web domains they hosted were registered in Beijing.

https://www.zdnet.com/article/heres...afe-text-chat-and-video-conferencing-service/

The US National Security Agency (NSA) published last week a security assessment of today's most popular video conferencing, text chatting, and collaboration tools.

https://media.defense.gov/2020/Apr/...OLLABORATION-SERVICES-SECURELY-LONG-FINAL.PDF

 

https://thunderspy.io/

Thunderspy targets devices with a Thunderbolt port. If your computer has such a port, an attacker who gets brief physical access to it can read and copy all your data, even if your drive is encrypted and your computer is locked or set to sleep.

Thunderspy is stealth, meaning that you cannot find any traces of the attack. It does not require your involvement, i.e., there is no phishing link or malicious piece of hardware that the attacker tricks you into using. Thunderspy works even if you follow best security practices by locking or suspending your computer when leaving briefly, and if your system administrator has set up the device with Secure Boot, strong BIOS and operating system account passwords, and enabled full disk encryption. All the attacker needs is 5 minutes alone with the computer, a screwdriver, and some easily portable hardware.

All Thunderbolt-equipped systems shipped between 2011-2020 are vulnerable. Some systems providing Kernel DMA Protection, shipping since 2019, are partially vulnerable. The Thunderspy vulnerabilities cannot be fixed in software, impact future standards such as USB 4 and Thunderbolt 4, and will require a silicon redesign. Users are therefore strongly encouraged to determine whether they are affected using Spycheck, a free and open-source tool we have developed that verifies whether their systems are vulnerable to Thunderspy. If it is found to be vulnerable, Spycheck will guide users to recommendations on how to help protect their system.

https://blogs.intel.com/technology/2020/05/more-information-on-thunderspy/#gs.5s2dl8

 

My wife sent me this in an email. If it has previously been posted I apologize. While it is humor the scary part is how accurate it actually is:

CALLER:
Is this Gordon's Pizza?
GOOGLE:
No sir, it's Google Pizza.
CALLER:
I must have dialed a wrong number. Sorry.
GOOGLE:
No sir, Google bought Gordon's Pizza last month.
CALLER:
OK. I would like to order a pizza.
GOOGLE:
Do you want your usual, sir?
CALLER:
My usual? You know me?
GOOGLE:
According to our caller ID data sheet, the last 12 times you called you ordered an extra-large pizza with three cheeses, sausage, pepperoni, mushrooms and meatballs on a thick crust.
CALLER:
OK! That's what I want ...
GOOGLE:
May I suggest that this time you order a pizza with ricotta, arugula, sun-dried tomatoes and olives on a whole wheat gluten-free thin crust?
CALLER:
What? I detest vegetables!
GOOGLE:
Your cholesterol is not good, sir.
CALLER:
How the hell do you know!
GOOGLE:
Well, we cross-referenced your home phone number with your medical records. We have the result of your blood tests for the last 7 years.
CALLER:
Okay, but I do not want your rotten vegetable pizza! I already take medication for my cholesterol.
GOOGLE:
Excuse me sir, but you have not taken your medication regularly. According to our database, you purchased only a box of 30 cholesterol tablets once, at Drug RX Network, 4 months ago.
CALLER:
I bought more from another drugstore.
GOOGLE:
That doesn't show on your credit card statement.
I paid in cash.
GOOGLE:
But you did not withdraw enough cash according to your bank statement.
CALLER:
I have other sources of cash.
GOOGLE:
That doesn't show on your last tax return unless you bought them using an undeclared income source, which is against the law.
CALLER:
WHAT THE HELL!
GOOGLE:
I'm sorry, sir, we use such information only with the sole intention of helping you.
CALLER:
Enough already! I'm sick to death of Google, Facebook, Twitter, WhatsApp and all the others. I'm going to an island without internet, cable TV, where there is no cell phone service and no one to watch me or spy on me.
GOOGLE: I understand sir, but you need to renew your passport first. It expired 6 weeks ago...


Ron

 

https://www.seattletimes.com/seattl...s-unemployment-system-amid-coronavirus-chaos/

But starting in March, as the coronavirus response shut down the economy, those numbers skyrocketed to a peak of 181,975 initial claims in a single week. By late April, the state had taken in around 860,000 initial claims, paralyzing its website and call center.
At the same time, across the nation, federal and state officials pushed to expedite benefits payments, even if it meant losing some security. Washington and other states dropped the usual waiting period between when a claim is filed and paid, so ESD didn’t always have enough time to verify claims before sending payment.

It was a situation ripe for exploitation. And, according to security experts, actors like Scattered Canary did just that.

Scattered Canary began as a one-man shop running Craigslist scams, but has grown over more than a decade into a criminal syndicate targeting businesses, governments, as well as individuals with a variety of cons, according to Agari, the California cybersecurity company that first discovered and named the organization in early 2019.

 

It was a situation ripe for exploitation.

That says it all. Look at what happened in New Orleans following Katrina. When all is said and done I would venture most states will have been bilked out of millions or tens of millions of dollars.

Ron

 

Privacy Lost?!!
C'mon...people nowadays place photos of their ass instead of their face as social media profile pic.
there is nothing called "privacy" these days.
good for CIA,MI6,NSA,KGB,BBC,... and other spying companies.

 

Privacy Lost?!!
C'mon...people nowadays place photos of their ass instead of their face as social media profile pic.
there is nothing called "privacy" these days.
good for CIA,MI6,NSA,KGB,BBC,... and other spying companies.

Not everyone uses their ass for their avatar and some of the people that don't are still concerned about privacy in general and abuse of information in particular.

 

In the "good ole days" if you wanted to know about someone you had 3 good sources. The telephone operator, who everyone knew spent most of her time listening in after she connected you and knew ALL the gossip. The Postmaster who knew everyone his post office served and what kind of mail they received. The Sheriff who was usually there when the "gossip" got started or cleaning up the mess afterward and spent more time actually serving the people than "enforcing" the laws.

 

https://www.reuters.com/article/us-...ks-breach-amid-encryption-fight-idUSKBN23H2C9

A group of U.S. lawmakers preparing to fight a legislative attack on encrypted communications is trying to establish what happened when encryption was subverted at a Silicon Valley maker of networking gear.

Soon after, reseachers discovered the code in question had changed one part of a security mechanism secretly designed by the National Security Agency and widely believed to contain a back door for spying, known as Dual Elliptic Curve.

Juniper included the NSA technology before its exposure in the wake of Edward Snowden's leaks about the agency's method. Some time later, insiders or outside hackers switched the key here to the back door, giving access to user traffic.

The FBI launched an investigatihere that was never publicly resolved.

The NSA built a backdoor into an encryption protocol. Someone figured it out and used it who was not the NSA. Lather, rinse, repeat...

 

Trust no one.

Ron