Matthew Dickie

CTO, Group-BMC

Matthew Dickie (SCF, CISA, CISSP) is a strategic, goal-oriented Enterprise Security Architect, with a proven record in providing world-class professional solutions and advice in the areas of high risk information and systems security, to leading global organisations like BNP Paribas Fortis, Novartis, Euroclear, Bank of Ireland, IBM, Mastercard and Motorola.

He is recognized as a thought leader and coach, with a strong technical and business background and is a proficient speaker. He is experienced in mentoring security professionals and setting goal oriented architectures / development plans for specialist technologists and generalists alike.

Specialties include:

– Enterprise Security Architecture (ArchiMate (Archi)),
– Security Strategy Development (Capability Based),
– Data Security, Privacy (GDPR), Cryptography, PKI, E-Signature,
– ABAC, ZTA, DLP, ISO 27xxx – Policy & Risk Management/Mitigation;
– Cloud Computing Security,
– Regulatory compliance and standards – PCI (PIN, DSS), EMV, ISO, NIST8800-53;
– Smartcards, Operations, Audit, User awareness programs.


“PKI Certificates: a ticking time-bomb in your IoT system?”

The following topics will be covered in the talk:

So if we know system failures will occur due to certificate expiry and we know when it will happen, how do we miss it?
Typically, skilled staff are involved in the definition, design and deployment of any system. A few years later this knowledge and experience is not available, and staff may not know the ticking time bombs that await them.
So how can we design this out…

When designing a PKI solution, the following questions arise:
– How do I generate the device keys, get the certificate and install it on the device?
– How long do I need certificates to last?
– How to I change them?

Why change a certificate?
There are multiple reasons to change a certificate, such as access policy – older devices do not get a renewed certificate and hence by default are no longer authorised, and therefore cannot gain access. This can be based on a business / licencing decision or device management.

Can we just give very long lifetimes and rely on revocation?
Not really, the challenge is that no one really knows what the lifetime of all IoT devices will be. Generalised IT devices may have a 5-8 year lifetime, hence they could have a cert of `10 years.

There are certificates and certificates.
Certificates are typically issued in a 3-layer hierarchy. An issuing CA should not issue certificate with a validity longer than itself. This can lead to significant confusion in the validation process.

What’s the impact of CAB Forum changes?
Due to performance and effectiveness (including reliance on others) Google and others have pushed away from online certificate status checking (CRL/OCSP). They have pushed to mitigate the risk of this change by reducing the validity period of the server certificate to one year. This change is now upon us…

Can we just use Certificate Automation?
There are many services available which scan for expiring certificates, profile their lifetime and can feed into device management systems to generate and deploy new certificates. Within IoT this approach has a number of limitations.

Do I have to reject a connection based on an expired certificate?
This is a business / risk decision. Depending on the business impact it may be better to continue to operate to buy time to react. However certificate expiry is a way to avoid the need for extensive blacklisting.

View all our Speakers