April 25, 2025 • 17 mins
Upwardly Mobile
Episode Title: The Good, The Bad, and The Ugly in Mobile Encryption
In this episode of Upwardly Mobile, hosted by George & Skye and sponsored by Approov, we dive deep into the crucial world of encryption algorithms for mobile app developers. Protecting user data is paramount for trust, compliance, and preventing breaches, but navigating the landscape of encryption can be challenging. We break down algorithms into three categories: The Good, The Bad, and The Ugly, discussing which ones to use, which to avoid, and learning from past failures.Episode Summary:Encryption is non-negotiable in mobile development, affecting data security, privacy, and compliance. Choosing the right algorithm is critical, as not all are created equal.The Good: We highlight modern, reliable encryption algorithms essential for mobile applications.
Episode Title: The Good, The Bad, and The Ugly in Mobile Encryption
In this episode of Upwardly Mobile, hosted by George & Skye and sponsored by Approov, we dive deep into the crucial world of encryption algorithms for mobile app developers. Protecting user data is paramount for trust, compliance, and preventing breaches, but navigating the landscape of encryption can be challenging. We break down algorithms into three categories: The Good, The Bad, and The Ugly, discussing which ones to use, which to avoid, and learning from past failures.Episode Summary:Encryption is non-negotiable in mobile development, affecting data security, privacy, and compliance. Choosing the right algorithm is critical, as not all are created equal.The Good: We highlight modern, reliable encryption algorithms essential for mobile applications.
- AES (Advanced Encryption Standard): The industry standard for symmetric encryption. AES-256 is recommended for its strength, performance, and flexibility. Using AES-GCM mode provides both confidentiality and integrity/authenticity, which is vital. Modern mobile CPUs often have hardware acceleration (AES-NI) making it very fast.
- ECC (Elliptic Curve Cryptography): The modern choice for asymmetric cryptography, particularly valuable in mobile environments with limited resources. ECC offers robust security with significantly smaller key lengths compared to RSA, leading to faster computations, less memory, lower power consumption, and less data transmitted. It's ideal for secure key exchange (like ECDHE in TLS) and digital signatures (like ECDSA).
- ChaCha20-Poly1305: An excellent AEAD symmetric cipher. It offers security comparable to AES-256-GCM and performs exceptionally well in software, often faster than AES on devices without dedicated hardware acceleration. It's widely used in TLS 1.3.
- Hashing Algorithms: For integrity checks and password storage. Use the SHA-2 family (SHA-256, SHA-384, SHA-512) or the newer SHA-3 family. For password hashing, never just hash passwords; use dedicated functions like Argon2 (current best practice) or bcrypt, designed to be slow and memory-intensive to resist brute-force attacks.
- Secure Protocols: Always use TLS 1.3 for securing network communications (HTTPS), as it mandates strong ciphers and removes insecure options.
- Key Management: Leverage platform-provided secure key storage like Android Keystore and iOS Keychain, which often use hardware-backed secure elements.
- The Hybrid Approach: The standard practice involves using asymmetric crypto (like ECDHE) to establish a shared secret key securely, and then using that secret key with a fast symmetric AEAD cipher (like AES-GCM or ChaCha20-Poly1305) to encrypt the actual application data.
- DES (Data Encryption Standard): Long obsolete with a small 56-bit key size, easily cracked with modern hardware. Completely insecure.
- 3DES (Triple DES): While an improvement over DES, it's considered weak against current cryptanalysis and is significantly slower than modern standards like AES.
- RC4: A stream cipher vulnerable to multiple types of attacks, deprecated in TLS 1.3.
- MD5 & SHA-1: Hashing algorithms considered broken for security purposes like digital signatures or password hashing due to practical collision attacks. Use SHA-2 or SHA-3 instead.
- CBC Mode without MAC: Using modes like AES-CBC without combining them correctly with a strong Message Authentication Code (MAC) can lead to vulnerabilities like padding oracle attacks (POODLE) and bit-flipping attacks. AEAD modes like GCM handle this automatically.
- ECB Mode (Electronic Codebook): Never use for more than one block of data, as it leaks patterns visibly.
- Older Protocols: SSLv2, SSLv3, TLS 1.0, and TLS 1.1 have known vulnerabilities (POODLE, BEAST). Use TLS 1.2 minimum, strongly prefer TLS 1.3.
- MD5 & SHA-1: Suffered severe cryptographic failures with discovered collisions.
- WEP (Wired Equivalent Privacy): A notorious failure in wireless network security, riddled with vulnerabilities exploitable in minutes.
- Implementation Errors: This is where most failures occur. Examples include hardcoded keys, weak random number generation, insecure key storage (plaintext in preferences/files), missing certificate validation (allowing MitM attacks), and protocol downgrade attacks.
- Rolling Your Own Crypto: Unless you are an expert cryptographer, do not invent your own algorithms or protocols; stick to well-vetted standards and libraries.
- Library Vulnerabilities: Bugs in crypto librarie
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Welcome back to our Deep Dive series. Today, we're tackling
something crucial, the security of your mobile apps and the
API as they talk to.
Speaker 2 (00:08):
That's right, we're focusing specifically on encryption, the algorithms you
as mobile developers need to know about, whether you're on iOS, Android, HarmonyOS,
Flutter or even React Native.
Speaker 1 (00:21):
Yeah, we want to cut through the complexity. Well, look
at what's essential, what's well obsolete, and frankly, what's just
dangerous to use in your apps today.
Speaker 2 (00:29):
Think of this as your quick guide to making informed
crypto choices. We'll cover the algorithms you should be using,
the ones to absolutely avoid, and maybe most importantly, the
common pitfalls.
Speaker 3 (00:39):
That mess things up.
Speaker 1 (00:40):
Okay, let's get into it. The good, the essential stuff.
First on the list has to be AES, right, the
Advanced Encryption Standard.
Speaker 2 (00:46):
Absolutely, AES is pretty much the industry benchmark. Yes, specifically,
you should aim for AES two fifty six, and.
Speaker 1 (00:52):
Not just as, but a specific.
Speaker 2 (00:54):
Mode exactly AES GCM. That's Gallas counter mode. It's an
AEAD mode authenticated encryption with associated data.
Speaker 1 (01:02):
Okay, so what does that actually mean for a developer.
Speaker 2 (01:05):
It means you get confidentiality. Keeping the data secret and
integrity and authenticity so you know that data hasn't been
tampered with.
Speaker 1 (01:13):
That's super important, prevents manipulation. And it's fast on phones.
Speaker 3 (01:17):
Oh yeah.
Speaker 2 (01:18):
Modern mobile CPUs, especially ARMv eight and later often have
hardware acceleration like ASNI makes it really speedy, less drained
on the battery too.
Speaker 1 (01:27):
Good point. Now, there's another symmetric cipher that gets mentioned
a lot Shot twenty poly three three ZHO five. Quite
a mouthful it is.
Speaker 2 (01:34):
But it's another excellent AED choice, developed by Google. It
provides similar security strength to AES too fifty.
Speaker 1 (01:40):
Six gcm, So why choose it over AES.
Speaker 2 (01:43):
The main advantage is performance in software. If a device
doesn't have that dedicated ADS hardware acceleration we just mentioned,
Josh twenty can often be faster.
Speaker 1 (01:52):
Ah okay, So it's a strong alternative, especially for maybe
lower end devices or specific scenarios.
Speaker 2 (01:57):
Precisely, and the fact that it's used heavily in TLS
one point three. He kind of speaks volumes about its robustness.
It's a solid choice, all right.
Speaker 1 (02:03):
Shifting gears a bit to asymmetric crypto Public private key
stuff ECC seems dominant now elliptic curve cryptography.
Speaker 2 (02:11):
It really is the modern standard for asymmetric the big
win key size smaller rastically smaller. You get roughly the
same security level with say a two hundred and fifty
six bit ECC key as you would with a thirty
seventy two bit RSA key.
Speaker 1 (02:25):
Wow, that's a huge difference.
Speaker 2 (02:26):
And for mobile that means faster key generation, faster signing,
faster key exchange, less data to transmit over the network,
less memory needed, less battery used. It's just a much
better fit for constrained devices like phones.
Speaker 1 (02:40):
Makes sense. We see it in things like TLS key.
Speaker 2 (02:42):
Exchange, ECDH Elliptic curve diffie helmet ephemeral is standard in
TLS for perfect forward secrecy and ECDSA for digital signatures.
Speaker 1 (02:52):
What about the old work hourse RSA still relevant?
Speaker 2 (02:55):
It's still around often for legacy compatibility. Yeah, but if
you have to use RSA, the guide this is clear,
use strong keys minimum twenty forty eight bit minimum yeah,
and really forty ninety six bit is recommended if the
data is sensitive. But honestly, compared to ECC, it's slower
and more resource hungry on mobile for equivalent security.
Speaker 1 (03:12):
So ECC preferred for new systems RSA for compatibility if
needed with big keys.
Speaker 3 (03:18):
That's the gist of it.
Speaker 1 (03:18):
Okay, hashing, This isn't encryption exactly, but it's crucial for
integrity and passwords. What should we use for.
Speaker 2 (03:25):
General integrity checks? Digital signatures, things like that. The SAHA
two family is solid SAHA two five six, SAHA three
eighty four, SAHA five twelve, or the newer SAHA three family.
Speaker 1 (03:38):
But not for passwords, absolutely not.
Speaker 2 (03:40):
This is critical. Standard hashes like SAHA two are designed
to be fast. That's the opposite of what you want
for passwords because of brute forcing exactly. For passwords, you
need dedicated, slow, memory intensive functions. Are Gone two is
the current best practice. Bcrypt is another well regarded option.
They make brute force attacks much much harder.
Speaker 1 (03:58):
Got it slow is good for passwords and for network traffic.
Speaker 2 (04:01):
Always use TLS, and specifically TLS one point three if
you can caring off. It mandates strong cipher suites, removes
outdated insecure options automatically, and fixes vulnerabilities found in earlier versions.
It simplifies things and improves security. TLS one point two
is the absolute minimum baseline these days.
Speaker 1 (04:18):
And managing all these keys where do they live?
Speaker 2 (04:20):
Don't just store them in plain text files. Use the
platform secure key storage mechanisms, that's the Android key store
and the iOS keychain.
Speaker 1 (04:29):
They often use hardware security.
Speaker 2 (04:30):
Yes, many devices have hardware backed secure elements like trusted
Execution environment or as secure enclave key stored. There are
much better protected even if the main OS is compromised.
Speaker 3 (04:42):
It's a huge security boost.
Speaker 1 (04:43):
Okay. One last point in the good section the hybrid approach,
why don't we just use ECC or RSA for everything?
Speaker 2 (04:50):
Because asymmetric crypto is slow, really slow for encrypting large
amounts of data. So the standard pattern, like in TLS,
is you use the slower asymmetric crypto maybe ECDG just
to securely agree on a shared symmetric key OKA like
a session key exactly, and then you use that shared
key with a fast symmetric cipher like ads GCM or
(05:12):
a Chaucha twenty balty one three zero four five to
encrypt all the actual application data being sent back and forth.
Speaker 1 (05:17):
Gust in both worlds secure key exchange, fast data encryption.
Speaker 3 (05:21):
You got it. That's the standard sensible.
Speaker 1 (05:23):
Way to do it, right, So that covers the essentials.
Now let's move into the danger zone, the bad algorithms
to avoid, like the plague. First up DES.
Speaker 2 (05:34):
Oh DES data encryption standard. Yeah, avoid it completely. It's
fifty six bit key, is laughably small by today's standards.
Speaker 1 (05:41):
It can be cracked very very quickly, seriously obsolete.
Speaker 3 (05:44):
Totally never use it period.
Speaker 1 (05:45):
What about three DES triple DES sounds better.
Speaker 2 (05:48):
It was an improved over DES back in the day,
but it's also considered weak now against modern crypt analysis. Yeah,
and it's slow, really slow compared to AES. There's just
no good reason to use three DES anymore. AES replaced it.
Speaker 1 (06:02):
Okay, another one, RC four. I feel like I saw
that a lot previously.
Speaker 2 (06:05):
You probably did. It was used in older versions of
SSLT allis even WP for Wi Fi. But it's a
stream cipher with known serious vulnerabilities and biases. It's fundamentally
broken for security purposes now.
Speaker 1 (06:16):
And TLS one point three dropped it right.
Speaker 2 (06:17):
Yep, it's officially deprecated. Don't touch RC four.
Speaker 1 (06:20):
Moving to hashing again. MD five and SAHA one still
see those sometimes you shouldn't.
Speaker 2 (06:25):
Both have severe weaknesses. Specifically, practical collision attacks.
Speaker 1 (06:29):
Exist, meaning you can find two different inputs that produce
the same hash exactly.
Speaker 2 (06:33):
Which completely undermines their use for things like verifying file
integrity or digital signatures. Imagine signing one document and someone
creates a malicious one with the same SAHA one hash.
Speaker 1 (06:44):
Bad news Browsers don't trust SAHA one SERTs anymore.
Speaker 2 (06:47):
Either, correct, the industry has moved on. Stick to SAHA
two or SAHA three for anything security related.
Speaker 1 (06:54):
Okay, this next one's a bit more subtle. AESCBC mode
without a MACI right.
Speaker 2 (07:00):
So AES itself is fine, and CBC mode cipher blockchaining
can be used securely, but.
Speaker 1 (07:06):
The key is can be what's the catch?
Speaker 2 (07:08):
It only provides confidentiality, It doesn't inherently provide integrity or authenticity.
You must combine it correctly with a separate message authentication
code AMAC.
Speaker 1 (07:18):
Like HMAC SAHA two five six or.
Speaker 2 (07:20):
Something yes, using what's called an encrypt Then ACAD approach
encrypted data first. Then you calculate the MAC over the
resulting ciphertext.
Speaker 1 (07:27):
And if you don't do that or do it wrong, you're.
Speaker 2 (07:29):
Vulnerable to things like padding oracle attacks. Remember Poudley that
exploited CBC issues in SSL, and also bitflipping attacks where
an attacker can subtly change the ciphertext to predictably alter
the decrypted plain text.
Speaker 1 (07:43):
Yikes, So just using aes CBC isn't enough.
Speaker 3 (07:47):
Not on its own.
Speaker 2 (07:48):
No, that's why EEAD modes like GCM or such a
twenty poly twenty three oh five are strongly preferred. They
bundle the encryption and the integrity check together, making them
much harder to misuse.
Speaker 1 (07:59):
Okay, good clarification. Now, ECB mode electronic codebook.
Speaker 2 (08:03):
ECB the simplest block cipher mode and also the most dangerous.
Never ever use it for encrypting more than a single
block of data. Why is that Because it's stateless. Every
identical block of plaintext encrypts to the exact same block of.
Speaker 1 (08:17):
Ciphertext, so patterns remain visible.
Speaker 3 (08:19):
Totally visible.
Speaker 2 (08:20):
The classic example is encrypting a bitmap image like a logo.
With ECB, you can still clearly see the outline of
logo and the encrypted image because all the blocks are
the same color encrypt of the same pattern. It leaks
way too much information.
Speaker 1 (08:32):
Just don't use ECB.
Speaker 3 (08:33):
Just don't, there's no good reason.
Speaker 1 (08:34):
And finally, in the bad list old protocols, we touched
on TLS, but which ones are definite?
Speaker 2 (08:39):
No, gos, SSLv two, SSLv three, TLS one point zero,
and TLS one point one.
Speaker 3 (08:44):
All of them.
Speaker 4 (08:45):
Why specific vulnerabilities, Yes, known exploitable vulnerabilities things like poodle
affected SSLv three, beast TLS one point zero, heart bleed wasn't.
Speaker 2 (08:55):
A protocol flaw, but hit librarries supporting older TLS go on.
They're simply not secure enough for modern use.
Speaker 1 (09:02):
So TLS one point two minimum one point three strongly recommended.
Speaker 2 (09:06):
It absolutely configured your servers and apps accordingly.
Speaker 1 (09:09):
Okay, that's a pretty clear list of things to avoid.
Now for the ugly, the implementation mistakes. The sources say
this is where things really go wrong most often.
Speaker 2 (09:17):
That's sadly true. You can pick the best algorithm like AESGCM,
but implement it four lee and get zero actual security. Yeah.
Speaker 3 (09:24):
The number one ugly mistake hard coded keys.
Speaker 1 (09:27):
Embedting the encryption key directly in the app's code or.
Speaker 2 (09:30):
Anigonfig file bundled with the app. Yeah, it seems easy,
but it means anyone who can decompile your app or
just poke around its files can potentially find your secret.
Speaker 1 (09:37):
Key and then all that encryption is useless, completely useless
game over. What's another common one.
Speaker 2 (09:42):
Weak random number generation. Good cryptography relies heavily on strong,
unpredictable random numbers for generating keys, initialization vectors, ivs, nonsis.
Speaker 1 (09:54):
If the random numbers aren't truly random.
Speaker 3 (09:56):
Then the security of app rates.
Speaker 2 (09:58):
If an attacker can predict your keys or nonss, they
could potentially break the encryption. Always use a cryptographically secure
pseudorandom number generator CSPRNG.
Speaker 1 (10:09):
Makes sense and related to keys, storing them insecurely YEP.
Speaker 2 (10:12):
Putting keys in plaintext in like shared preferences on Android
or user defaults on iOS, or just a regular file
that's almost as bad as hard coding them.
Speaker 1 (10:20):
Use the key store and key chain exactly.
Speaker 3 (10:22):
That's what they're for.
Speaker 1 (10:23):
Okay, shifting to networks off again. Missing certificate validation sounds
like a recipe for man in the middle attacks.
Speaker 3 (10:29):
It is.
Speaker 2 (10:30):
Your app connects to your server over HTTPS, which is great,
but if the app doesn't properly check that the server
certificate is valid issued by a trusted authority, matches the
host name it's connecting to, and hasn't been revoked.
Speaker 1 (10:42):
Then an attacker could potentially impersonate your server.
Speaker 2 (10:45):
Precisely, they could sit in the middle, decrypt traffic, steel credentials,
inject malware even though you thought you're using HTTPS. Proper
certificate validation, including pinning for high security apps, is non negotiable.
Speaker 1 (10:59):
And the classic advice don't roll your own crypto seems obvious,
but why is it so.
Speaker 2 (11:05):
Often repeated Because cryptography is incredibly difficult to get right.
Even the experts make mistakes. Designing secure algorithms and protocols
requires deep, specialized knowledge.
Speaker 1 (11:16):
It's easy to create something that looks secure, but isn't
extremely easy.
Speaker 2 (11:20):
Subtle flaws can lead to catastrophic breaks unless you are
a team of world class cryptographers. Just don't do it.
Stick to well vetted, standardized algorithms and libraries implemented by experts.
Speaker 1 (11:31):
Teaching of libraries. They aren't infallible either, are they No.
Speaker 2 (11:35):
Unfortunately, not even reputable libraries like open ssl have had
serious vulnerabilities. Heartbleeed is the most famous.
Speaker 1 (11:40):
Example that wasn't a flaw in TLS itself, right, It
was a bug in open SSL's implementation, exactly.
Speaker 2 (11:47):
A simple coding error. A missing downs check allowed attackers
to read sensitive memory from servers, including private keys. It
highlights that you need to use good libraries and keep
them updated with security patches.
Speaker 1 (12:00):
Point patching is crucial. What about protocol downgrade attacks?
Speaker 2 (12:03):
This is where an attacker tricks the client and server
into negotiating a connection using an older, weaker protocol version
like falling back from TLS one point two to SSLv.
Speaker 1 (12:13):
Three, and then they attack the weaknesses in that older protocol.
Speaker 2 (12:17):
Right like using the Poodel attack against the downgradeed SSLv
three connection. Proper server configuration is key here disabled those
old insecure protocols entirely, so downgrades aren't possible.
Speaker 1 (12:28):
Okay. Side channel attacks sound a bit more exotic.
Speaker 2 (12:31):
They are instead of attacking the math of the algorithm,
they attack the physical implementation. They might measure the precise
time and operation takes, or the power consumed, or even
electromagnetic radiation leaked by.
Speaker 1 (12:42):
The chip to treat the deuced bits of the key Potentially.
Speaker 2 (12:45):
Yes, it's harder to pull off, requires physical proximity or
specific access usually, but it's a real threat, especially for
things like cryptographic keys stored in secure hardware if it's
not designed carefully to resist these leaks. Particularly relevant for
ECC implementations sometimes, and we.
Speaker 1 (13:05):
See the impact of these kinds of failures in major breaches, don't.
Speaker 2 (13:08):
We We do you look at massive breaches like Equifax
or Heartland payment systems, well, often complex cryptographic failures are
frequently part of the picture. Maybe data wasn't encrypted at
rest when it should have been. Maybe weak algorithms were used,
maybe keys were mismanaged, maybe non vulnerabilities weren't patched.
Speaker 1 (13:26):
It shows the real world consequences.
Speaker 2 (13:28):
Absolutely, it's not just theoretical. Poor crypto practices lead to
tangible harm.
Speaker 1 (13:33):
Okay, let's slick to the horizon post quantum cryptography PQC.
What's the deal here? Why should mobile devs care?
Speaker 2 (13:40):
Now? So the public key crypto we rely on today
RSAECC is secure because factoring large numbers are solving discrete
logarithm problems on elliptic curves is incredibly hard for current.
Speaker 1 (13:51):
Computers, but maybe not for future quantum computers.
Speaker 2 (13:54):
That's the concern. A sufficiently powerful quantum computer, if built,
could potentially break RSA and ECC relatively easily using algorithms
like shores algorithm.
Speaker 1 (14:06):
Which would undermine a lot of our security infrastructure.
Speaker 2 (14:08):
A lot of it secure web browsing, digital signatures, secure
software updates. So the crypto community is proactively developing PQC
algorithms resistant to attacks from both classical and quantum computers, and.
Speaker 1 (14:21):
NIST has been standardizing these.
Speaker 2 (14:22):
Yes, the US National Institute of Standards and Technology ran
a multi year competition. In August twenty twenty four, they
finalized the first standards, mL KIM also known as Crystal's
Kuiber for.
Speaker 1 (14:33):
Key establishment replacing things like RSA Key Exchange or ECDH.
Speaker 2 (14:37):
Right and MLDSA Crystal's di Lithium for digital signatures replacing
RSA or ECDSA. There's also SLHDSA, SPINNCS plus sixties and
other signature scheme and just recently in March twenty twenty five,
they added HQC as another key establishment standard.
Speaker 1 (14:53):
Okay, so standards are emerging. What should a mobile developer
do about PQC today? Panic?
Speaker 2 (14:58):
No, definitely no panic needed right now. Implementing PQC and
mobile apps today isn't really necessary.
Speaker 3 (15:02):
Or practical yet?
Speaker 1 (15:03):
Why not?
Speaker 2 (15:04):
The standards are still relatively new and robust. Optimized library
support specifically for mobile platforms is still maturing. Plus the
back ends and infrastructure need to support it too.
Speaker 1 (15:15):
So what's the guidance.
Speaker 2 (15:16):
Then, awareness is key. Understand that this transition is happening.
The main thing is to plan for crypto.
Speaker 1 (15:24):
Agility, meaning design systems so you can swap out algorithms
later exactly.
Speaker 2 (15:29):
Avoid hard coding dependencies on specific algorithms or key sizes everywhere.
Make your systems flexible. Keep an eye on announcements from
OS vendors, library developers, and your back end service providers
about their PQC roadmaps.
Speaker 1 (15:43):
And performance might be different.
Speaker 2 (15:44):
Yeah, that's something to watch. Some PQC algorithms might have
larger keys or signatures or different computational costs compared to
ECC or RSA. That could impact performance, bandwidth, and battery
life on mobile. So we'll need to see how the
implementations evolve.
Speaker 1 (15:59):
So be aware, plan for agility, watch for updates, but
no need to rush implementation just yet.
Speaker 3 (16:05):
That's a good summary for now.
Speaker 1 (16:06):
Okay, Well, this has been a really useful tour through
the good, the bad, and the ugly of mobile encryption.
Speaker 2 (16:11):
Yeah, hopefully helpful. I think the bottom line for developers
is use the strong modern stuff like as GCM and ECC,
implement it carefully, using platform features like key store keychain, and.
Speaker 1 (16:23):
Definitely steer clear of the old broken algorithms like des
RC four, MD five, SAHA one and insecure modes like
ECB or unauthenticated CBC.
Speaker 2 (16:35):
Absolutely and be super mindful of those implementation mistakes hard
coded keys, bad random numbers, missing certificate checks. That's often
where the real damage happens.
Speaker 1 (16:44):
And looking ahead, keeping tabs on PQC developments is going
to be important for future proofing for sure.
Speaker 2 (16:49):
Remember, good encryption isn't just a nice to have, It's
fundamental for user trust and the actual security of your
app and data.
Speaker 1 (16:57):
This deep dive into mobile app and API security was
construct did using human expertise and enhanced with AI assistance.
Thanks so much for joining us today.
Speaker 2 (17:04):
Yeah, thanks for listening. We'd definitely encourage you to dig
deeper into these topics and really apply them to make
your mobile apps as secure as possible.
Welcome back to our Deep Dive series. Today, we're tackling
something crucial, the security of your mobile apps and the
API as they talk to.
Speaker 2 (00:08):
That's right, we're focusing specifically on encryption, the algorithms you
as mobile developers need to know about, whether you're on iOS, Android, HarmonyOS,
Flutter or even React Native.
Speaker 1 (00:21):
Yeah, we want to cut through the complexity. Well, look
at what's essential, what's well obsolete, and frankly, what's just
dangerous to use in your apps today.
Speaker 2 (00:29):
Think of this as your quick guide to making informed
crypto choices. We'll cover the algorithms you should be using,
the ones to absolutely avoid, and maybe most importantly, the
common pitfalls.
Speaker 3 (00:39):
That mess things up.
Speaker 1 (00:40):
Okay, let's get into it. The good, the essential stuff.
First on the list has to be AES, right, the
Advanced Encryption Standard.
Speaker 2 (00:46):
Absolutely, AES is pretty much the industry benchmark. Yes, specifically,
you should aim for AES two fifty six, and.
Speaker 1 (00:52):
Not just as, but a specific.
Speaker 2 (00:54):
Mode exactly AES GCM. That's Gallas counter mode. It's an
AEAD mode authenticated encryption with associated data.
Speaker 1 (01:02):
Okay, so what does that actually mean for a developer.
Speaker 2 (01:05):
It means you get confidentiality. Keeping the data secret and
integrity and authenticity so you know that data hasn't been
tampered with.
Speaker 1 (01:13):
That's super important, prevents manipulation. And it's fast on phones.
Speaker 3 (01:17):
Oh yeah.
Speaker 2 (01:18):
Modern mobile CPUs, especially ARMv eight and later often have
hardware acceleration like ASNI makes it really speedy, less drained
on the battery too.
Speaker 1 (01:27):
Good point. Now, there's another symmetric cipher that gets mentioned
a lot Shot twenty poly three three ZHO five. Quite
a mouthful it is.
Speaker 2 (01:34):
But it's another excellent AED choice, developed by Google. It
provides similar security strength to AES too fifty.
Speaker 1 (01:40):
Six gcm, So why choose it over AES.
Speaker 2 (01:43):
The main advantage is performance in software. If a device
doesn't have that dedicated ADS hardware acceleration we just mentioned,
Josh twenty can often be faster.
Speaker 1 (01:52):
Ah okay, So it's a strong alternative, especially for maybe
lower end devices or specific scenarios.
Speaker 2 (01:57):
Precisely, and the fact that it's used heavily in TLS
one point three. He kind of speaks volumes about its robustness.
It's a solid choice, all right.
Speaker 1 (02:03):
Shifting gears a bit to asymmetric crypto Public private key
stuff ECC seems dominant now elliptic curve cryptography.
Speaker 2 (02:11):
It really is the modern standard for asymmetric the big
win key size smaller rastically smaller. You get roughly the
same security level with say a two hundred and fifty
six bit ECC key as you would with a thirty
seventy two bit RSA key.
Speaker 1 (02:25):
Wow, that's a huge difference.
Speaker 2 (02:26):
And for mobile that means faster key generation, faster signing,
faster key exchange, less data to transmit over the network,
less memory needed, less battery used. It's just a much
better fit for constrained devices like phones.
Speaker 1 (02:40):
Makes sense. We see it in things like TLS key.
Speaker 2 (02:42):
Exchange, ECDH Elliptic curve diffie helmet ephemeral is standard in
TLS for perfect forward secrecy and ECDSA for digital signatures.
Speaker 1 (02:52):
What about the old work hourse RSA still relevant?
Speaker 2 (02:55):
It's still around often for legacy compatibility. Yeah, but if
you have to use RSA, the guide this is clear,
use strong keys minimum twenty forty eight bit minimum yeah,
and really forty ninety six bit is recommended if the
data is sensitive. But honestly, compared to ECC, it's slower
and more resource hungry on mobile for equivalent security.
Speaker 1 (03:12):
So ECC preferred for new systems RSA for compatibility if
needed with big keys.
Speaker 3 (03:18):
That's the gist of it.
Speaker 1 (03:18):
Okay, hashing, This isn't encryption exactly, but it's crucial for
integrity and passwords. What should we use for.
Speaker 2 (03:25):
General integrity checks? Digital signatures, things like that. The SAHA
two family is solid SAHA two five six, SAHA three
eighty four, SAHA five twelve, or the newer SAHA three family.
Speaker 1 (03:38):
But not for passwords, absolutely not.
Speaker 2 (03:40):
This is critical. Standard hashes like SAHA two are designed
to be fast. That's the opposite of what you want
for passwords because of brute forcing exactly. For passwords, you
need dedicated, slow, memory intensive functions. Are Gone two is
the current best practice. Bcrypt is another well regarded option.
They make brute force attacks much much harder.
Speaker 1 (03:58):
Got it slow is good for passwords and for network traffic.
Speaker 2 (04:01):
Always use TLS, and specifically TLS one point three if
you can caring off. It mandates strong cipher suites, removes
outdated insecure options automatically, and fixes vulnerabilities found in earlier versions.
It simplifies things and improves security. TLS one point two
is the absolute minimum baseline these days.
Speaker 1 (04:18):
And managing all these keys where do they live?
Speaker 2 (04:20):
Don't just store them in plain text files. Use the
platform secure key storage mechanisms, that's the Android key store
and the iOS keychain.
Speaker 1 (04:29):
They often use hardware security.
Speaker 2 (04:30):
Yes, many devices have hardware backed secure elements like trusted
Execution environment or as secure enclave key stored. There are
much better protected even if the main OS is compromised.
Speaker 3 (04:42):
It's a huge security boost.
Speaker 1 (04:43):
Okay. One last point in the good section the hybrid approach,
why don't we just use ECC or RSA for everything?
Speaker 2 (04:50):
Because asymmetric crypto is slow, really slow for encrypting large
amounts of data. So the standard pattern, like in TLS,
is you use the slower asymmetric crypto maybe ECDG just
to securely agree on a shared symmetric key OKA like
a session key exactly, and then you use that shared
key with a fast symmetric cipher like ads GCM or
(05:12):
a Chaucha twenty balty one three zero four five to
encrypt all the actual application data being sent back and forth.
Speaker 1 (05:17):
Gust in both worlds secure key exchange, fast data encryption.
Speaker 3 (05:21):
You got it. That's the standard sensible.
Speaker 1 (05:23):
Way to do it, right, So that covers the essentials.
Now let's move into the danger zone, the bad algorithms
to avoid, like the plague. First up DES.
Speaker 2 (05:34):
Oh DES data encryption standard. Yeah, avoid it completely. It's
fifty six bit key, is laughably small by today's standards.
Speaker 1 (05:41):
It can be cracked very very quickly, seriously obsolete.
Speaker 3 (05:44):
Totally never use it period.
Speaker 1 (05:45):
What about three DES triple DES sounds better.
Speaker 2 (05:48):
It was an improved over DES back in the day,
but it's also considered weak now against modern crypt analysis. Yeah,
and it's slow, really slow compared to AES. There's just
no good reason to use three DES anymore. AES replaced it.
Speaker 1 (06:02):
Okay, another one, RC four. I feel like I saw
that a lot previously.
Speaker 2 (06:05):
You probably did. It was used in older versions of
SSLT allis even WP for Wi Fi. But it's a
stream cipher with known serious vulnerabilities and biases. It's fundamentally
broken for security purposes now.
Speaker 1 (06:16):
And TLS one point three dropped it right.
Speaker 2 (06:17):
Yep, it's officially deprecated. Don't touch RC four.
Speaker 1 (06:20):
Moving to hashing again. MD five and SAHA one still
see those sometimes you shouldn't.
Speaker 2 (06:25):
Both have severe weaknesses. Specifically, practical collision attacks.
Speaker 1 (06:29):
Exist, meaning you can find two different inputs that produce
the same hash exactly.
Speaker 2 (06:33):
Which completely undermines their use for things like verifying file
integrity or digital signatures. Imagine signing one document and someone
creates a malicious one with the same SAHA one hash.
Speaker 1 (06:44):
Bad news Browsers don't trust SAHA one SERTs anymore.
Speaker 2 (06:47):
Either, correct, the industry has moved on. Stick to SAHA
two or SAHA three for anything security related.
Speaker 1 (06:54):
Okay, this next one's a bit more subtle. AESCBC mode
without a MACI right.
Speaker 2 (07:00):
So AES itself is fine, and CBC mode cipher blockchaining
can be used securely, but.
Speaker 1 (07:06):
The key is can be what's the catch?
Speaker 2 (07:08):
It only provides confidentiality, It doesn't inherently provide integrity or authenticity.
You must combine it correctly with a separate message authentication
code AMAC.
Speaker 1 (07:18):
Like HMAC SAHA two five six or.
Speaker 2 (07:20):
Something yes, using what's called an encrypt Then ACAD approach
encrypted data first. Then you calculate the MAC over the
resulting ciphertext.
Speaker 1 (07:27):
And if you don't do that or do it wrong, you're.
Speaker 2 (07:29):
Vulnerable to things like padding oracle attacks. Remember Poudley that
exploited CBC issues in SSL, and also bitflipping attacks where
an attacker can subtly change the ciphertext to predictably alter
the decrypted plain text.
Speaker 1 (07:43):
Yikes, So just using aes CBC isn't enough.
Speaker 3 (07:47):
Not on its own.
Speaker 2 (07:48):
No, that's why EEAD modes like GCM or such a
twenty poly twenty three oh five are strongly preferred. They
bundle the encryption and the integrity check together, making them
much harder to misuse.
Speaker 1 (07:59):
Okay, good clarification. Now, ECB mode electronic codebook.
Speaker 2 (08:03):
ECB the simplest block cipher mode and also the most dangerous.
Never ever use it for encrypting more than a single
block of data. Why is that Because it's stateless. Every
identical block of plaintext encrypts to the exact same block of.
Speaker 1 (08:17):
Ciphertext, so patterns remain visible.
Speaker 3 (08:19):
Totally visible.
Speaker 2 (08:20):
The classic example is encrypting a bitmap image like a logo.
With ECB, you can still clearly see the outline of
logo and the encrypted image because all the blocks are
the same color encrypt of the same pattern. It leaks
way too much information.
Speaker 1 (08:32):
Just don't use ECB.
Speaker 3 (08:33):
Just don't, there's no good reason.
Speaker 1 (08:34):
And finally, in the bad list old protocols, we touched
on TLS, but which ones are definite?
Speaker 2 (08:39):
No, gos, SSLv two, SSLv three, TLS one point zero,
and TLS one point one.
Speaker 3 (08:44):
All of them.
Speaker 4 (08:45):
Why specific vulnerabilities, Yes, known exploitable vulnerabilities things like poodle
affected SSLv three, beast TLS one point zero, heart bleed wasn't.
Speaker 2 (08:55):
A protocol flaw, but hit librarries supporting older TLS go on.
They're simply not secure enough for modern use.
Speaker 1 (09:02):
So TLS one point two minimum one point three strongly recommended.
Speaker 2 (09:06):
It absolutely configured your servers and apps accordingly.
Speaker 1 (09:09):
Okay, that's a pretty clear list of things to avoid.
Now for the ugly, the implementation mistakes. The sources say
this is where things really go wrong most often.
Speaker 2 (09:17):
That's sadly true. You can pick the best algorithm like AESGCM,
but implement it four lee and get zero actual security. Yeah.
Speaker 3 (09:24):
The number one ugly mistake hard coded keys.
Speaker 1 (09:27):
Embedting the encryption key directly in the app's code or.
Speaker 2 (09:30):
Anigonfig file bundled with the app. Yeah, it seems easy,
but it means anyone who can decompile your app or
just poke around its files can potentially find your secret.
Speaker 1 (09:37):
Key and then all that encryption is useless, completely useless
game over. What's another common one.
Speaker 2 (09:42):
Weak random number generation. Good cryptography relies heavily on strong,
unpredictable random numbers for generating keys, initialization vectors, ivs, nonsis.
Speaker 1 (09:54):
If the random numbers aren't truly random.
Speaker 3 (09:56):
Then the security of app rates.
Speaker 2 (09:58):
If an attacker can predict your keys or nonss, they
could potentially break the encryption. Always use a cryptographically secure
pseudorandom number generator CSPRNG.
Speaker 1 (10:09):
Makes sense and related to keys, storing them insecurely YEP.
Speaker 2 (10:12):
Putting keys in plaintext in like shared preferences on Android
or user defaults on iOS, or just a regular file
that's almost as bad as hard coding them.
Speaker 1 (10:20):
Use the key store and key chain exactly.
Speaker 3 (10:22):
That's what they're for.
Speaker 1 (10:23):
Okay, shifting to networks off again. Missing certificate validation sounds
like a recipe for man in the middle attacks.
Speaker 3 (10:29):
It is.
Speaker 2 (10:30):
Your app connects to your server over HTTPS, which is great,
but if the app doesn't properly check that the server
certificate is valid issued by a trusted authority, matches the
host name it's connecting to, and hasn't been revoked.
Speaker 1 (10:42):
Then an attacker could potentially impersonate your server.
Speaker 2 (10:45):
Precisely, they could sit in the middle, decrypt traffic, steel credentials,
inject malware even though you thought you're using HTTPS. Proper
certificate validation, including pinning for high security apps, is non negotiable.
Speaker 1 (10:59):
And the classic advice don't roll your own crypto seems obvious,
but why is it so.
Speaker 2 (11:05):
Often repeated Because cryptography is incredibly difficult to get right.
Even the experts make mistakes. Designing secure algorithms and protocols
requires deep, specialized knowledge.
Speaker 1 (11:16):
It's easy to create something that looks secure, but isn't
extremely easy.
Speaker 2 (11:20):
Subtle flaws can lead to catastrophic breaks unless you are
a team of world class cryptographers. Just don't do it.
Stick to well vetted, standardized algorithms and libraries implemented by experts.
Speaker 1 (11:31):
Teaching of libraries. They aren't infallible either, are they No.
Speaker 2 (11:35):
Unfortunately, not even reputable libraries like open ssl have had
serious vulnerabilities. Heartbleeed is the most famous.
Speaker 1 (11:40):
Example that wasn't a flaw in TLS itself, right, It
was a bug in open SSL's implementation, exactly.
Speaker 2 (11:47):
A simple coding error. A missing downs check allowed attackers
to read sensitive memory from servers, including private keys. It
highlights that you need to use good libraries and keep
them updated with security patches.
Speaker 1 (12:00):
Point patching is crucial. What about protocol downgrade attacks?
Speaker 2 (12:03):
This is where an attacker tricks the client and server
into negotiating a connection using an older, weaker protocol version
like falling back from TLS one point two to SSLv.
Speaker 1 (12:13):
Three, and then they attack the weaknesses in that older protocol.
Speaker 2 (12:17):
Right like using the Poodel attack against the downgradeed SSLv
three connection. Proper server configuration is key here disabled those
old insecure protocols entirely, so downgrades aren't possible.
Speaker 1 (12:28):
Okay. Side channel attacks sound a bit more exotic.
Speaker 2 (12:31):
They are instead of attacking the math of the algorithm,
they attack the physical implementation. They might measure the precise
time and operation takes, or the power consumed, or even
electromagnetic radiation leaked by.
Speaker 1 (12:42):
The chip to treat the deuced bits of the key Potentially.
Speaker 2 (12:45):
Yes, it's harder to pull off, requires physical proximity or
specific access usually, but it's a real threat, especially for
things like cryptographic keys stored in secure hardware if it's
not designed carefully to resist these leaks. Particularly relevant for
ECC implementations sometimes, and we.
Speaker 1 (13:05):
See the impact of these kinds of failures in major breaches, don't.
Speaker 2 (13:08):
We We do you look at massive breaches like Equifax
or Heartland payment systems, well, often complex cryptographic failures are
frequently part of the picture. Maybe data wasn't encrypted at
rest when it should have been. Maybe weak algorithms were used,
maybe keys were mismanaged, maybe non vulnerabilities weren't patched.
Speaker 1 (13:26):
It shows the real world consequences.
Speaker 2 (13:28):
Absolutely, it's not just theoretical. Poor crypto practices lead to
tangible harm.
Speaker 1 (13:33):
Okay, let's slick to the horizon post quantum cryptography PQC.
What's the deal here? Why should mobile devs care?
Speaker 2 (13:40):
Now? So the public key crypto we rely on today
RSAECC is secure because factoring large numbers are solving discrete
logarithm problems on elliptic curves is incredibly hard for current.
Speaker 1 (13:51):
Computers, but maybe not for future quantum computers.
Speaker 2 (13:54):
That's the concern. A sufficiently powerful quantum computer, if built,
could potentially break RSA and ECC relatively easily using algorithms
like shores algorithm.
Speaker 1 (14:06):
Which would undermine a lot of our security infrastructure.
Speaker 2 (14:08):
A lot of it secure web browsing, digital signatures, secure
software updates. So the crypto community is proactively developing PQC
algorithms resistant to attacks from both classical and quantum computers, and.
Speaker 1 (14:21):
NIST has been standardizing these.
Speaker 2 (14:22):
Yes, the US National Institute of Standards and Technology ran
a multi year competition. In August twenty twenty four, they
finalized the first standards, mL KIM also known as Crystal's
Kuiber for.
Speaker 1 (14:33):
Key establishment replacing things like RSA Key Exchange or ECDH.
Speaker 2 (14:37):
Right and MLDSA Crystal's di Lithium for digital signatures replacing
RSA or ECDSA. There's also SLHDSA, SPINNCS plus sixties and
other signature scheme and just recently in March twenty twenty five,
they added HQC as another key establishment standard.
Speaker 1 (14:53):
Okay, so standards are emerging. What should a mobile developer
do about PQC today? Panic?
Speaker 2 (14:58):
No, definitely no panic needed right now. Implementing PQC and
mobile apps today isn't really necessary.
Speaker 3 (15:02):
Or practical yet?
Speaker 1 (15:03):
Why not?
Speaker 2 (15:04):
The standards are still relatively new and robust. Optimized library
support specifically for mobile platforms is still maturing. Plus the
back ends and infrastructure need to support it too.
Speaker 1 (15:15):
So what's the guidance.
Speaker 2 (15:16):
Then, awareness is key. Understand that this transition is happening.
The main thing is to plan for crypto.
Speaker 1 (15:24):
Agility, meaning design systems so you can swap out algorithms
later exactly.
Speaker 2 (15:29):
Avoid hard coding dependencies on specific algorithms or key sizes everywhere.
Make your systems flexible. Keep an eye on announcements from
OS vendors, library developers, and your back end service providers
about their PQC roadmaps.
Speaker 1 (15:43):
And performance might be different.
Speaker 2 (15:44):
Yeah, that's something to watch. Some PQC algorithms might have
larger keys or signatures or different computational costs compared to
ECC or RSA. That could impact performance, bandwidth, and battery
life on mobile. So we'll need to see how the
implementations evolve.
Speaker 1 (15:59):
So be aware, plan for agility, watch for updates, but
no need to rush implementation just yet.
Speaker 3 (16:05):
That's a good summary for now.
Speaker 1 (16:06):
Okay, Well, this has been a really useful tour through
the good, the bad, and the ugly of mobile encryption.
Speaker 2 (16:11):
Yeah, hopefully helpful. I think the bottom line for developers
is use the strong modern stuff like as GCM and ECC,
implement it carefully, using platform features like key store keychain, and.
Speaker 1 (16:23):
Definitely steer clear of the old broken algorithms like des
RC four, MD five, SAHA one and insecure modes like
ECB or unauthenticated CBC.
Speaker 2 (16:35):
Absolutely and be super mindful of those implementation mistakes hard
coded keys, bad random numbers, missing certificate checks. That's often
where the real damage happens.
Speaker 1 (16:44):
And looking ahead, keeping tabs on PQC developments is going
to be important for future proofing for sure.
Speaker 2 (16:49):
Remember, good encryption isn't just a nice to have, It's
fundamental for user trust and the actual security of your
app and data.
Speaker 1 (16:57):
This deep dive into mobile app and API security was
construct did using human expertise and enhanced with AI assistance.
Thanks so much for joining us today.
Speaker 2 (17:04):
Yeah, thanks for listening. We'd definitely encourage you to dig
deeper into these topics and really apply them to make
your mobile apps as secure as possible.
Popular Podcasts
Las Culturistas with Matt Rogers and Bowen Yang
Ding dong! Join your culture consultants, Matt Rogers and Bowen Yang, on an unforgettable journey into the beating heart of CULTURE. Alongside sizzling special guests, they GET INTO the hottest pop-culture moments of the day and the formative cultural experiences that turned them into Culturistas. Produced by the Big Money Players Network and iHeartRadio.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
The Charlie Kirk Show
Charlie is America's hardest working grassroots activist who has your inside scoop on the biggest news of the day and what's really going on behind the headlines. The founder of Turning Point USA and one of social media's most engaged personalities, Charlie is on the front lines of America’s culture war, mobilizing hundreds of thousands of students on over 3,500 college and high school campuses across the country, bringing you your daily dose of clarity in a sea of chaos all from his signature no-holds-barred, unapologetically conservative, freedom-loving point of view. You can also watch Charlie Kirk on Salem News Channel