Posts by Rajesh Kanungo

Who ate all the PII? Not the blockchain, thankfully

Unless you are in the US

Here your personal data belongs to everyone else but not to you.

It's the real Heart Bleed: Medtronic locks out vulnerable pacemaker programmer kit

Re: Humanity is doomed

Lack of empathy, narcissistic personalities, money.

Apple forgot to lock Intel Management Engine in laptops, so get patching

Open source processors may be a step

Every cpu security system has been blown wide open. Sometimes it seems that while one part of a cpu team is working hard to secure something, the other part is working hard to undermine the security.

Having managed many sdlc programs, I spent more time going on detective missions where I’d eventually find out a team slipped in a web server, a diagnostic tool, a debug process, etc. without informing us or even documenting it.

And once a device was out in the field there were almost no recalls and the support staff were hooked on to the easy diagnostics (see, no passwords required).

One famous chip vendor’s software team turned off static code analysis because it was giving out too many criticals.

One server code based I scanned had 98,000 criticals. Yup.

In both cases the decision was made to hide everything from my team. Fortunately the CEO stepped in ...

Decoding the Chinese Super Micro super spy-chip super-scandal: What do we know – and who is telling the truth?

Entirely plausible

Completely plausible. The best proof would be an actual Supermicro board with the spy chip. My only question is, why do it and get a bad rap? My bet is that China has multiple approaches and this got caught. Moreover, China may have realized that the US was aware of the spy chip. So the US went public with it.

Re: My take?

Actually, Bloomberg would have been sued by Apple, AWS, Supermicro by now. Bloomberg had multiple sources confirming the insertions.

Re: It's simpler

Agreed. Also, adding extra circuitry in the larger processor is probably easier to catch during root-cause analysis than something you never knew existed.

Re: From Amazon's denial

The first case was from the acquisition. So yes, Amazon probably knew about it happening on US soil.

Re: Chinese agents slip spy chips into Super Micro servers

The Intel ME bugs may not have been known or there could have been the fear of the bugs being fixed. Moreover, any attacks would take known paths so they could be blocked.

Re: 'None of the actors can be taken at face value

The boards are not 'normal'. Just ask the board manufacturer to add the spy tips. In China it is not that difficult. The supply chain has been infected all the way to the component level.

America cooks up its flavor of GDPR – and Google's over the moon

Preemptive strike against real privacy

This work is to prevent real privacy from being discussed. The companies will want to further dilute everything and then some.

And obviously no fines.

Watt the heck is this? A 32-core 3.3GHz Arm server CPU shipping? Yes, says Ampere

Re: Has no one learned the Calxeda lesson?

First sensible response. Maybe there (4) Where is the innovation? (Business, power, performance, management, etc.) should be mentioned more clearly. Not clear if having a totally different architecture works for businesses as it competes with an already x86 humming server ecosystem.

Maybe the authors or inventors haven't been able to articulate the win or they are keeping that under wraps.

Why is it better?

Some of the issues I see are:

Negatives:

1. Software: The Servers including virtualization tools are all standardized around x86 (Intel, AMD). In fact, there is a lot more invested in software than in the HW.

2. Architecture: If the competition is based purely on architecture, the server team will look for highly dedicated (NVIDIA type), or the generalized architecture. A general purpose ARM CPU doesn't buy you anything special. Why not stick to AMD or Intel?

3. Silicon: TSMC may have an advantage in Silicon over Intel but Intel has been pumping out these processors for a long time and beating them on Silicon is an iffy strategy at best. If AMD is having a hard time competing then how can you expect a whole different architecture to win?

Positives:

1. Watts: Clearly ARM has an advantage when it comes to lower watt CPU but at the higher end, I don't see it being a deal breaker unless the difference is huge. Nothing seems to indicate otherwise.

2. Bottom up: Remember how DEC stole the market from IBM, Sun from DEC, and then Intel from SUN? My believe is that when the majority of the CPU's are ARM systems, which they already are, that they will slowly move into the mainframe.

However, this will take time.

3. Customization: ARM Cpu's can be customized at a faster rate than intel CPU's. ARM CPU's with full blown AI engines, DSP's etc. are very common.

4. Multiple vendors for CPU choices: Unlike Intel or AMD, ARM allows anyone to find a vendor with close enough specs to what they need. If there isn't one then you can have a vendor design and spin one for you. You want one with 3 DSP cores, 2 Neural network cores, etc. and can't find one? Ask a vendor to make you one.

Apple did something like this in-house for their iPhone since Intel can't put everything they want in the CPU at the rate they want it. (plus the power consumption controls ...)

Ultimately ARM will win because of the speed of customization is in months and it will keep on eating into the x86 market. It will, however, take time.

How to nab a HTTPS cert for a stranger's website: Step one, shatter those DNS queries...

Re: Paranoid AF

I would definitely go after the RNG too. Or the software stack to retrieve the keys. One has to just look at cvedetails.com to realize how vulnerable our software is.

Re: Paranoid AF

Key size is not a measure of crypto strength when the algorithms are different. Enigma had fundamental flaws. It doesn't mean AES doesn't. But we currently don't know of any real ones.

Just to further confuse the issue, AES-128 is stronger than AES-256. AES-256 refers to the key size and not the block size. Bruce Schneider and others pointed out that the number of rounds were too few.

Finally:

Look up Dan Bernstein's ChaCha, Salsa and Poly series of ciphers and MAC. They have been adopted by many non-government related entities like Google, are being proposed for various RFC's etc.

You are right to be paranoid for a different reason ... quantum crypto attacks are coming.

https://www.linkedin.com/pulse/crypto-armageddon-nsa-says-current-asymmetric-key-quantum-kanungo/

And badly implemented crypto can lead to side channel attacks. The simplest one is a timing attack ...

https://www.linkedin.com/pulse/simple-ecc-implementations-approach-side-channel-attacks-kanungo/

Boffins are building an open-source secure enclave on RISC-V

Re: Please no

Someone just broke into the IME via JTAG.

https://www.theregister.co.uk/2018/08/29/intel_jtag_flaw/

Anything can be skewed, TRNG, side channel, extra registers, etc

Tampering with the Silicon: It is probably quite easy to skew the RNG. There goes all ECC. If you are more bold, you might even have a separate pathway to extract secrets (private, symmetric, passwords, etc.). One could also introduce modes where side-channel attacks became easier ...

So you’ve got a zero-day – do you sell to black, grey or white markets?

Question of ethics

We know that FB sold information to Cambridge Analytica which was used to target citizens in various elections around the globe. Both FB and CA made a ton of money. FB was also the platform of choice for Russian trolls. So FB made money from them.

I KNOW I will never do this but as a security professional, I can see an immoral person justifying selling an FB 0 day to a foreign agency and keeping the money for himself. This is a very slippery slope.

Companies are making a ton of money writing bad software and not following SDLC. Shouldn't they be to blame? I can see occasional mistakes slipping through the cracks but a whole slew of them? Every day I hear of flash 0 days. What is up with that? And they are still making money?

Intel's security light bulb moment: Chips to recruit GPUs to scan memory for software nasties

Graphics co processors are written for speed

Traditionally, software (and the microcode) written for GPU's is optimized for blindingly fast performance. Don't check for nulls, ranges, types, etc. Just make it run fast. That makes them nice targets for hackers.

Would security experts who have graphics chip knowledge have any insights into the feasibility of being proposed? Would a hacker not target the GPU and take advantage of it?

Microsoft has designed an Arm Linux IoT cloud chip. Repeat, an Arm Linux IoT cloud chip

Isolating the communications is good

In general, IoT attacks occur via normal communications mechanisms and less likely via hardware. In some areas the latter is fairly common; smart meters, set top boxes, etc. It is interesting to see MS isolate the basic communications outside of the main functionality. I wonder how far the isolation goes. Would a driver issue create main kernel issues or is it isolated to the baseband co-processors?

Moreover, how do you isolate higher level communication stack vulnerabilities from the rest of the system?

Maybe someone can educate me.

Also, I think MS intends to open up the VHDL to inspection, right? If not it will be an uphill battle to expose issues.

Rajesh

Brains behind seL4 secure microkernel begin RISC-V chip port

Key management/Crypto operations

I looked through the ISA and somethings I work with on a regular basis are not there. I guess ISA can be used to implement a secure element? But then, how does it beat a Javacard? The instruction set is too rich for a standard Javacard. Some of the things I do regularly:

1. Secure keys stores including One Time Programmable key stores

2. Secure boot

3. Cryptographic operations

4. Secure elements for operating on sensitive data with sensitive keys. The moment you pul keys into regular memory you are toast; just freeze the DRAM and read it out. Or rely on a software bug.

5. Handling large numbers of keys (i.e. a key-chain).

6. Introduce new cryptographic algorithms.

7. Optimizing energy consumption/peak performance/speed depending upon use-case.

Just protecting address spaces hasn't worked: most applications will need to pull keys from somewhere to use them and therein lies the problem.