Slides from our first LiveCast. A brief dive into the foundational aspects of API security, from an architectural and technical perspective. In it, Jacob Ideskog of Curity explains how to pair OAuth with OpenID Connect, and Kristopher Sandoval covers security concerns for the emerging trend of Internet of Things devices in the healthcare field.

3. LIVECAST: API SECURITY 101

4. WHAT IS NORDIC APIS?
A international community of API practitioners and enthusiasts.
Quality events
all over the
world - 2018
High impact
blog posts
Illuminating
eBooks

5. UPCOMING EVENTS
● Annual Platform Summit: Oct 22-24th
2018
● API Event in Austin: TBA
PLEASE TAKE OUR SURVEY
Help us improve our events, and get 15%
off your next Nordic APIs event ticket! visit
https://nordicapis.com/

6. NEWSLETTER
Bi-weekly digest of critical API insights
Sign up at:
https://nordicapis.com/newsletter/
"Nordic APIs is invested in educating the community,
something that makes their work stand out"
-Kin Lane, The API Evangelist

7. EBOOKS
Compendiums of our top insights on niche API topics. FREE downloads:
https://nordicapis.com/api-ebooks/
Will be released Tuesday, Dec 19!

8. SECURING THE API
STRONGHOLD
How to properly authenticate, control access, delegate
authority, and federate credentials across a system.
● OAuth 2.0 and OpenID Connect
● Public, Private, vs Partner APIs
● Delegation of user identity across microservices
● Differentiating Authentication, Authorization,
Federation, and Delegation, and the importance of
each
● Using OpenID Connect for Native Single Sign On
(SSO), Mobile Identity Management (MIM) & secure
IoT applications
● ... and more
FREE Download: https://nordicapis.com/ebooks/

9. WHY FOCUS ON API SECURITY?
● Underappreciated
● Not much knowledge shared
○ Exploits, tabloids, vulnerabilities
● Experts are limited
● Effects entire industry

10. APIs ARE VULNERABLEREAD: https://nordicapis.com/your-api-is-vulnerable-if-these-4-risks-arent-mitigated/
● APIs are affecting all industries
○ banks, healthcare, marketing,
shipping, eCommerce, IoT,
cryptocurrency, & more
● All businesses at risk
○ DDOS Attacks
○ Reverse-Engineering
○ Code injection, spoofing
● Case Studies, exploits

11. ● Authentication: identity control
● Authorization: user access level
● Federation: reusing credentials across
services
● Delegation: authorizing an entity to
perform actions on behalf of a user.
HOLISTIC API SECURITYREAD: https://nordicapis.com/api-security-the-4-defenses-of-the-api-stronghold/

12. ● Rate limiting
● API Gateways
● Open standards: OAuth, JWTs,
OpenID, SCIM, ...
● Testing/debugging
● HTTP Basic Auth, API Keys
API SECURITY STRATEGIESREAD: API Security: Deep Dive into OAuth and OpenID Connect
https://nordicapis.com/api-security-oauth-openid-connect-depth/

13. API KEYS ≠ SECURITYREAD: https://nordicapis.com/why-api-keys-are-not-enough/
● Most common method
● Code tied to specific user. String of characters
○ Ex)
IP84UTvzJKds1Jomx8gIbTXcEEJSUilGqpxCcmnx
● Exposure of API keys is a real threat
○ API key commit to Github is common
○ Can't rely on dev consumers to secure keys
○ API provider should have responsibility.
● What we really need are robust Identity
management solutions: OAuth and OpenID Connect

14. NOW UP:

15. Pairing OAuth with
OpenID Connect
for maximum use
Combining standards to create secure identity management for
APIs
Copyright Curity AB 2017

16. Quick recap of OAuth
Resource Owner (RO)
Authorization
Server (AS)
Client
Resource Server
(RS)
Authentication
Server

17. The client requests access
Resource Owner (RO)
Client
Resource Server
(RS)
Authorization
Server (AS)
Authentication
Server

18. The AS requires the RO to authenticate
Resource Owner (RO)
Client
Resource Server
(RS)
Authorization
Server (AS)
Authentication
Server

19. The AS issues the tokens
Resource Owner (RO)
Client
Resource Server
(RS)
Authorization
Server (AS)
Authentication
Server

20. The Client presents the token to the RS
Resource Owner (RO)
Client
Resource Server
(RS)
Authorization
Server (AS)
Authentication
Server

21. Authorization
Server (AS)
The RS validates the Token
Resource Owner (RO)
Client
Resource Server
(RS)
Authentication
Server

22. Access!
Resource Owner (RO)
Client
Resource Server
(RS)
Authorization
Server (AS)
Authentication
Server

23. What about the real world?
Copyright Curity AB 2017 23

24. 2 types of tokens
123XYZ
Jane Doe
By Value By
Reference

25. Contains NO information outside the network
123XYZ
Jane Doe
By Reference

26. Contains ALL necessary information
By Value (often JWT)

27. JWT - A signed JSON document
{
"sub": "janedoe",
"name" : "Jane Doe",
"email" : "jane@doe.com",
"phone_number" "+46 (0) 12345678",
"aud": "https://mymail.com",
"iss": "https://fs.oidc.net",
"nbf": 1409213888783,
"jti": "622a9973-fc4d-4797-be31-7c2116f549df",
"exp": 1409213890583,
"iat": 1409213888783
}
{
"iss": "https://fs.oidc.net",
"x5t": "5F0A1359B4BB9FBB104155908DEC1FDCB5AC8865",
"typ": "JWT",
"alg": "RS256”
}
Certificate
orQOOKvXN3jbEpBSl0RHAyaQNxcx9DFgtMsJJgMxm9Az6QJMKKy6m0WvP1UzXZA_nsK
16g9etg2yEW9IXbQU0RbSQktUtObRB9SxHtW_AcCk693XDAz15Y4aP9DeD62nROzd1M
S4FZTmY3Cgzo1-3-sqW6_4Rgzs94aLO3aLP_zoVtJycCUKtJQhGhPTyjXXYWMsp0E4uTtL8
Rif7cWu4olme_XNFlAs73pOrfzsQYc1GD2dB70l1M8SDaJZFURr9jAAaavX7Xqs_FPXY1PZ
LXLbc3ARXFmRf_-Z4B6uLCGI2shzl12ni54Yun6dflL9rQwaxXYuNZZodUWchID2cA
Signature

28. External vs. Internal
123XYZ
By ValueBy
Reference
Outside the network Inside the network
API Firewall /
Reverse
Proxy
API

29. Phantom Token
123XYZ
By ValueBy
Reference
Outside the network Inside the network
API Firewall /
Reverse
Proxy
API

30. Now – what does the API really
need?
Copyright Curity AB 2017 30

31. Adding: OpenID Connect

32. In the backend
sub=jacob
API

33. Find the Public Key
kid = 12345
…
sub=jacob
API
/JWK
S
{
"keys": [
{
"kty": "RSA",
"kid": ”12345",
"use": "sig",
"alg": "RS256",
"n":
"yMAHZiIfbAgmZJ-_4Gj-wdS8rvaKN…
"e": "AQAB",
"x5t": "MR-pGTa866RdZLjN6Vwrfay907g"
}]
}

34. Json Web Key Set - JWKS
•OpenID Connect endpoint
•All active public keys
•Cached and use
•On cache miss fetch new keys

35. When token data isn’t enough
•The goal of the Access token is to contain info most APIs
need
•Some APIs and operations require more information
•Details about the user, access info etc.

36. The client requests access
Resource Owner (RO)
Client
Resource Server
(RS)
Authentication
Server
scope=openid
profile Authorization
Server (AS)

37. In the backend (again)
sub=jacob
scope=openid
profile
API

38. Call UserInfo
sub=jacob
scope=openid
profile
API
/userinf
o
{
“sub” : “jacob”,
”email”: “jacob@example.com“,
“account_type” :”premium”,
…
}

39. Conclusion
•OpenID Connect adds useful extension even for APIs
•It is the identity layer ontop of OAuth
•Commonly used by the client but very useful in the backend
•UserInfo is an extension to the attributes in the token
•JWKS is a handy way to avoid complex key distribution
problems

40. Visit curity.io or e-mail us for more information
Copyright Curity AB 2017

41. Q & A

43. NOW UP:

44. Securing Medical Grade Devices in the IoT
HACKING THE BODY

45. SETTING THE STAGE
• Implantable Myoelectric Sensors (IMESs) are being used to control
prosthetic limbs. These devices can use electromyography (EMG)
signals and wireless telemetry to control complex movements in
prosthetic limbs.
• Some pacemakers include wireless interfaces as part of their
structure. Near-field communication interfaces can be used to
adjust configurations and wireless modules can output data for
device logs and remote monitoring.
• Wireless implants are being used in some trials to delivery
temporary low-voltage jolts to nerve endings to prevent migraines
and other headaches. The device is triggered by using a near-field
handheld interface that states a duration and level of shock, which
temporarily stops the feeling of sensation in the nerve.
• Prosthetic skin is being developed that uses a series of surface
sensors to emulate feeling, returning sensations like touch,
pleasure, pain, etc. to amputees.
• This may not be common yet – but the market is
dramatically expanding. Someone here could
develop the next big medical API breakthrough
in 5-10 years.

46. AN EXAMPLE
In August of 2017, a pacemaker manufacturer issued an open letter to
doctors who had implanted a specific range of popular pacemakers.
465k patients implanted with this range of pacemaker were considered
at risk, and medical professionals were urged to upgrade the firmware
of the pacemaker software.
The company stated in their letter, “If there were a successful attack, an
unauthorized individual (i.e., a nearby attacker) could gain access and
issue commands to the implanted medical device through radio
frequency (RF) transmission capability, and those unauthorized
commands could modify device settings (e.g., stop pacing) or impact
device functionality.”

47. MORALITY
• We can’t plan for everything. Our solutions are always going to have an
inherent amount of risk. How much is too much?
• As medical devices become more integrated with APIs, it will become
almost impossible to find a non-linked system. Should we slow progress to
allow for patient trust and comfort in technology, or should we adopt
wholeheartedly while possibly exposing ourselves? Example: FDA
medicine trials.
• Privacy policies and data collection are already a fine line between value
adding and invasive. What does this mean when start tracking personal
data like heartrate, steps taken, sensations felt, etc.?
• During the Industrial Revolution, we adopted technologies and practices
that, while beneficial in the short-term, had long-term, unforeseen,
measurable negative impacts on quality of life, air pollution, and populace
health. How do we know the IoT is not the Industrial Revolution 2.0?

48. LEGALITY
• Who owns the data? Who’s responsible?
• Privacy policies, disclosure policies, data retention, and data destruction.
• FDA regulations – proactive security, vague demands to prioritize security.
• HIPAA and HITECH violations for data and API providers. Best case
scenario $100 per violation, maxed at $25k per year. Worst case scenario
$50k per violation, maxed at $1.5m per year.
• Exposure of additional resources. A linked network may reveal other data
that is legally protected, making your liability in legal and financial terms
exponentially larger.

49. SECURITY
• Passive exposure. Medical device data can be passively collected by a
malicious party for advertising purposes, geolocation, etc.
• Active exposure. Device data could be used for corporate crimes
(threatening a CEO with exposure of an embarrassing illness), harassment
(“did you know your wife’s blood sugar this morning was 76?), and “trolling”
(web-connected video doorbell ringing on a loop every five minutes).
• Active attacks. A pacemaker can be shot off, an insulin pump told to pump
too much insulin, incorrect test data replacing actual test data complicating
treatment.
• Future attacks. “Pain sensory overload” on smart skin, disabling ocular
implants, reversing prosthetic control interpretations, etc.
• The target isn’t just our digital representations of money or our web
servers – they might be our hearts, kidneys, and lungs.

50. LAYERED SECURITY
ORGANIZATIONAL STRUCTURAL TECHNICAL

51. ORGANIZATIONAL SECURITY
• Ensure proper data collection. Do we really need to be collecting as much data as we are in order to deliver the needed data to the consumer? Does a
blood glucose level analyzer need to export geolocation data, blood type, levels of salts, minerals, etc.?
• Ensure proper data disposal. Do we need to keep every single bit of data for a patient regardless of whether its used or not? How do we securely
erase stored data? Should we even store data?
• Is any data being sent outside a secure network? i.e. are we sending data to a third party without establishing a Service Level Agreement?
• Practice risk identification and evaluation. Are we securing elements of the API that should be secured? Is our internal security culture resistant to
attack?
• Are we properly securing data according to regulation and compliance documents? Is data properly encrypted, destroyed in compliance, is PHI stored
in plaintext, etc.?
• Medical data might have additional regulation and compliance concerns unrelated to medical regulations. Devices that track the usage of diabetic
equipment and report results might also have an integrated ordering mechanism, and might thus handle payment processing – this would be covered
under regulation like PCI-DSS.

52. STRUCTURAL SECURITY
• How much cross-talk do we allow between devices? It might makes for a simpler data flow, but it makes for a more exposed one.
• What protocol do we use? What technology? Do we incorporate wi-fi, and if so, which standard? Do we utilize Bluetooth? NFC? Can we
standardize this?
• Where is the processing for authentication/authorization located? Larger devices such as EKG monitors can have (in theory) as much
processor power, RAM, storage, etc. that it could need. What about a pacemaker, where the device needs to be as small as possible?
What about micro-IoT devices in the brain or spinal cord?
• Do we implicitly trust data and only reject at the source of computation outside given parameters? Do we try and limit API data at the
device itself?
• Where exactly do we implement security in a practical sense?

53. TECHNICAL SECURITY
• How do we encrypt data? Do we rely on PKI? What about small devices without processor power to decrypt?
• Do we encrypt data in transit? Do we encrypt all data, or just some data?
• What encryption standard do we adopt? What protocol do we use for data transit? Can we leverage TLS/IPSec?
• Can we utilize hard-coded provisioned credentials? What about revocation? Hard-coded is more for identification, not useful for
authentication – but could it help build a system that is?
• Can we call on cellular tech security? UICC and SIM authentication – viable options?
• Solutions are great – but how do monitor to ensure breaches don’t happen?

54. 1
2
Our solution has to be small. Storage space is a premium, and we have limited physical space to fit logical data
storage into the system.
Our solution must be efficient. Space is at a premium, and so is processing power. We can’t have a heavy
protocol.
WHAT’S THE BEST SOLUTION?

55. 3
4
5
Our solution needs to be revocable. Updating hard-coded solutions in most devices would require surgery or
invasive placement of surface nodes, as well as the creation of security flaws.
Our solution needs to be monitor-enabled. We need to check that things are functioning correctly, and prove
authentication/authorization.
Our solution needs to work within a network. We should be able to share trust amongst networked devices.

56. • JWTs are mobile. They can be pushed through HTTP headers, POST
parameters, etc.
• JWTs are small. JSON scheme + base64 encoding means small
package sizes (assuming you keep Claims to a minimum).
• JWTs are efficient. In theory, a JWT can package PHI and medical data
as a signed, encoded package, ensuring integrity and transmission with
minimal overhead.
• They’re an important part of security – JWTs can encode and sign with
HMAC or RSA (RSA functions in the PKI configuration). They can be
encrypted using RFC 7517 JSON Web Encryption (also referred to as
JOSE, Javascript Object Signing and Encryption).
JSON Web Tokens
JWTs

57. • CWT is JWT – but in CBOR.
• Concise Binary Object Representation reduces some of the bulk in the
JSON encoding scheme.
• CBOR also results in faster processing.
• Skips the encoding step, represents in binary, quicker transmission and
easier encoding.
CBOR Web Tokens
CWTs

58. • Symmetric algorithms use the same key for both encryption and
decryption. While this is faster, there can be significant security
concerns (in some implementations).
• AES is relatively lightweight, but at smaller key sizes, can be broken.
Camellia is generally considered equal to AES, and is given equal
standing in international uses.
• This is still being (rapidly) developed for IoT-specific applications.
Tohoku University Research Group and NEC Corporation published
an AES application in 2016 that uses 50% less energy, resulting in a
much smaller and more efficient circuit. For embedded devices, we’re
on the cusp.
Symmetric Algorithms
Encryption (Symmetric)

59. • Asymmetric algorithms use different keys for encryption and
decryption. While this is slower, security is increased.
• RSA has long been considered the top asymmetric algorithm. It still
suffers from speed issues, however.
• NTRUEncypt is considerably faster than RSA, as has even been
acknowledged by RSA Labs staff. In many cases, it’s even faster than
ECC. It’s only recently moved into the public domain, however, and is
not considered a “mature” algorithm (in other words, not properly
tested).
Asymmetric Algorithms
Encryption (Asymmetric)

60. Assorted Encryption Speed Comparison
Aamer Nadeem et al, "A Performance Comparison of Data Encryption Algorithms", IEEE 2005
All tests were conducted using P-II 266 MHz

61. • Binds a token to a device given some encrypted data.
• When a client makes a request for an access token, it includes this
crypto piece, akin to a public key.
• The access token then takes this encrypted code and integrates it into
requests.
• When a request is made using the access token, the request is seen as
signed by the authorization service, and can be challenged.
• The challenge will either prove the token is held and being used by the
assigned device, or that it is not a proper request.
Proof for Integrity and Trust
Proof of Possession

62. Q & A

64. SPONSOR
Curity.io
@curityio
! THANK YOU !

65. FOLLOW NORDIC APIS
@nordicapis
slack.nordicapis.com

66. INTERESTED IN
PARTICIPATING IN OUR
NEXT LIVECAST?
Contact us:
info@nordicapis.com