Archive

Category Archives for "Security"

Announcing Four NDSS 2018 Workshops on Binary Analysis, IoT, DNS Privacy, and Security

The Internet Society is excited to announce that four workshops will be held in conjunction with the upcoming Network and Distributed System Security (NDSS) Symposium on 18 February 2018 in San Diego, CA. The workshop topics this year are:

A quick overview of each of the workshops is provided below. Submissions are currently being accepted for emerging research in each of these areas. Watch for the final program details in early January!

The first workshop is a new one this year on Binary Analysis Research (BAR). It is exploring the reinvigorated field of binary code analysis in light of the proliferation of interconnected embedded devices. In recent years there has been a rush to develop binary analysis frameworks. This has occurred in a mostly uncoordinated manner with researchers meeting on an ad-hoc basis or working in obscurity and isolation. As a result, there is little sharing or results and solution reuse among tools. The importance of formalized and properly vetted methods and tools for binary code analysis in order to deal with the scale of growth in these interconnected embedded devices cannot be overstated. Continue reading

Rough Guide to IETF 100: Internet Infrastructure Resilience

As we approach IETF 100 in Singapore next week, this post in the Rough Guide to IETF 100 has much progress to report in the world of Internet Infrastructure Resilience. After several years of hard work, the last major deliverable of the Secure Inter-Domain Routing (SIDR) WG is done – RFC 8205, the BGPSec Protocol Specification, was published in September 2017 as standard. BGPsec is an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems (ASes) through which a BGP update message propagates.

There are seven RFCs in the suite of BGPsec specifications:

  • RFC 8205 (was draft-ietf-sidr-bgpsec-protocol) – BGPsec Protocol Specification
  • RFC 8206 (was draft-ietf-sidr-as-migration) – BGPsec Considerations for Autonomous System (AS) Migration
  • RFC 8207 (was draft-ietf-sidr-bgpsec-ops) – BGPsec Operational Considerations
  • RFC 8208 (was draft-ietf-sidr-bgpsec-algs) – BGPsec Algorithms, Key Formats, and Signature Formats
  • RFC 8209 (was draft-ietf-sidr-bgpsec-pki-profiles) – A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests
  • RFC 8210 (was draft-ietf-sidr-rpki-rtr-rfc6810-bis) – The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1
  • RFC 8211 (was draft-ietf-sidr-adverse-actions) – Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)

You can read more Continue reading

Some Yubikeys Affected by Infineon Security Weakness

As Robin Wilton discussed a few days ago in Roca: Encryption Vulnerability and What to do About It, yet another security vulnerability has been discovered. If you have one of the ISOC-branded Yubikey 4s that we have given out at some conferences, they were affected by the recently disclosed Infineon vulnerability. See these two links for details:

This issue impacts only some limited uses of the keys. For details, see
https://www.yubico.com/keycheck/functionality_assessment.

You can get your ISOC-branded Yubikey 4 replaced at no cost to you by going to this page and following the instructions.

If you have questions or concerns, please contact Steve Olshansky, Internet Technology Program Manager, at <[email protected]>.

The post Some Yubikeys Affected by Infineon Security Weakness appeared first on Internet Society.

ROCA: Encryption vulnerability and what to do about it

Researchers recently discovered a dangerous vulnerability – called ROCA – in cryptographic smartcards, security tokens, and other secure hardware chips manufactured by Infineon Technologies. These articles on Ars Technica and The Register give a good background.

Is this a serious problem?

Yes. It’s serious in practice and in principle. Infineon used a flawed key generation routine, which means those keys are easier to crack, and the routine is used in chips embedded in a wide variety of devices. It’s reckoned that the flawed routine has been in use since 2012 and has probably been used to generate tens of millions of keys. Naturally, many of those keys will have been generated precisely because someone had data or resources that they particularly wanted to secure.

It’s serious because a flawed implementation managed to get through all the development and standardisation processes without being spotted, and has been widely deployed on mass-market devices.

What’s the flaw, and why does it cause a problem?

The flaw affects keys generated for the RSA and OpenPGP algorithms, both of which are public key crypto systems. Public key cryptography is based on pairs of keys, one of which is made public and the other kept private:

Devaluing Data Exposures

I had a great time this week recording the first episode of a new series with my co-worker Rich Stroffolino. The Gestalt IT Rundown is hopefully the start of some fun news stories with a hint of snark and humor thrown in.

One of the things I discussed in this episode was my belief that no data is truly secure any more. Thanks to recent attacks like WannaCry and Bad Rabbit and the rise of other state-sponsored hacking and malware attacks, I’m totally behind the idea that soon everyone will know everything about me and there’s nothing that anyone can do about it.

Just Pick Up The Phone

Personal data is important. Some pieces of personal data are sacrificed for the greater good. Anyone who is in IT or works in an area where they deal with spam emails and robocalls has probably paused for a moment before putting contact information down on a form. I have an old Hotmail address I use to catch spam if I’m relative certain that something looks shady. I give out my home phone number freely because I never answer it. These pieces of personal data have been sacrificed in order to provide me Continue reading

VMware NSX/Kubernetes and F5 – A Cloud Native App Integration

Introduction

When Bob Dylan wrote back in the 60’s “times they are a-changin” it’s very possible he knew how true that would be today.  Last week, we saw a few things announced in the container technology space during the DockerCon event in Copenhagen – but one thing that I believe came as a surprise to many was Docker’s announcement to begin including Kubernetes in Docker Enterprise edition sometime in early 2018.  This doesn’t concede or mark the death of Docker’s own scheduling and orchestration platform, Docker Swarm, but it does underscore what we’ve heard from many of our customers for quite some time now – almost every IT organization that is using/evaluating containers has jumped on the Kubernetes bandwagon.  In fact, many of you are probably already familiar with the integration supported today with NSX-T 2.0 and Kubernetes from the post that Yves did earlier in the year…

In the past few years, we’ve heard a lot about this idea of digital transformation and what it means for today’s enterprise.  Typically, a part of this transformation is something called infrastructure modernization, and this happens because most IT environments today have some hurdles that need to Continue reading

WPA2 and Infineon

The recent bug in WPA2 has a worst case outcome that is the same as using a wifi without a password: People can sniff, maybe inject… it’s not great but you connect to open wifi at Starbucks anyway, and you’re fine with that because you visit sites with HTTPS and SSH. Eventually your client will get a fix too, so the whole thing is pretty “meh”.

But there’s a reason I call it “WPA2 bug” and I call the recent issue with Infineon key generation “the Infineon disaster”. It’s much bigger. It seems like the whole of Estonia needs to re-issue ID cards, and several years worth of PC-, smartcard-, Yubikey, and other production have been generating bad keys. And these keys will stick around.

From now until forever when you generate, use, or accept RSA keys you have to check for these weak keys. I assume OpenSSH will if it hasn’t already.

But then what? It’s not like servers can just reject these keys, or it’ll lock people out. And it’s not clear that an adversary even has your public key for SSH. And you can’t crack the key if you don’t have the public half. Maybe a Continue reading

Some notes about the Kaspersky affair

I thought I'd write up some notes about Kaspersky, the Russian anti-virus vendor that many believe has ties to Russian intelligence.

There's two angles to this story. One is whether the accusations are true. The second is the poor way the press has handled the story, with mainstream outlets like the New York Times more intent on pushing government propaganda than informing us what's going on.


The press

Before we address Kaspersky, we need to talk about how the press covers this.

The mainstream media's stories have been pure government propaganda, like this one from the New York Times. It garbles the facts of what happened, and relies primarily on anonymous government sources that cannot be held accountable. It's so messed up that we can't easily challenge it because we aren't even sure exactly what it's claiming.

The Society of Professional Journalists have a name for this abuse of anonymous sources, the "Washington Game". Journalists can identify this as bad journalism, but the big newspapers like The New York Times continues to do it anyway, because how dare anybody criticize them?

For all that I hate the anti-American bias of The Intercept, at least they've had stories Continue reading