Discussion on answer by Andrew Philips: Prevent or detect key copy

user200312

10:21 AM

@AndrewPhilips Can you please tell me once again what was the problem with my approach?
And also how can I believe what you say when EVERYWHERE in the internet it is said MAC is used to authenticate a message?

So I need
(1)Securely store key
(2) Use MAC for message authentication
(3) Replay protection

Do you disagree with above?

@AndrewPhilips: security.stackexchange.com/questions/33569/…

user200312

11:25 AM

@AndrewPhilips en.wikipedia.org/wiki/Message_authentication_code

Andrew Philips

2:02 PM

You posted two other links to the Q&A that started this discussion, I repost them here for completeness: cseweb.ucsd.edu/~mihir/cse207/w-mac.pdf and security.stackexchange.com/questions/105160/…

Now, let's go through these one at a time.

I'm not going to read this entire section, as I know how MACs work. Cryptographic protocols cannot be separated out and used as you see fit. They must be used in a larger context, that is, each protocol is used for its purpose and supports another. So, MAC is used for Integrity Protection, NOT Authentication, even though that word is in the name and even though this section appears to say otherwise. Bear with me, I will explain that.

Here's the important quote from this section. It's what I've been saying all along, so hopefully, you can begin to trust what I say: "Message authentication is said to protect the integrity of a message, ensuring that each message that it is received and deemed acceptable is arriving in the same condition that it was sent out—with no bits inserted, missing, or modified."

That last bit was for the link from CSEWEB.UCSD.EDU Chapter 7. This is an excellent chapter for you to read and understand some of the attacks that are possible on MAC.

You refer me to the question you asked on Nov 10 (security.stackexchange.com/questions/105160/…). I haven't even bothered to answer this one because the current answer is excellent. Notice, the author writes: "It's really difficult to answer your question of "how to use it correctly", because we don't know anything about your use case."

I will address the other links above in a moment. However, I want to point out that in a comment on security exchange, I said you've designed a protocol and you said you didn't. Storing key codes, trying to protect against key theft, MAC'ing network messages and checking those MACs at another machine IS a protocol. Just because you don't see it that way doesn't make it true. As I've designed, built, broken and improved protocols, I know one when I see one.

"Protocol" definition from MW dictionary: a system of rules that explain the correct conduct and procedures to be followed in formal situations.

Wiki link: I'm not sure why you keep sending this to me. You'll have to provide some context. I know the word "Authenticate" appears in MAC, that doesn't mean what you think it means. If you want to stay focused on it, you're not going to learn.

The first link for security stack exchange has the finest of points: Why do you need MAC in addition to encryption? The accepted answer argues that it Authentication is really the point of MAC, not Integrity. Does this counter everything I've said? Not really. Here's why, even that author is confused on a very subtle point and we can see it in his comment.

He writes: "The ability to prove that a message was generated by a particular party" THAT IS THE POINT. MAC is about proving a message originated with a PARTICULAR party. The reason I'm calling out your protocol as insecure and ad-hoc is because you are missing the proof of the other party.

You need to state the problem you are trying to solve. The problem you are trying to solve is not numbers 1,2,&3 above. In fact, it wasn't even #3 (replay attacks) until I pointed it out. These things are steps in a security protocol. You've taken some crypto algorithms, slapped them together and are trying to build SOMETHING.

What is that something? What are you trying to achieve at a higher level. Then, we can talk about the best way to approach it.

Next, your question "do I disagree with above?" I neither agree nor disagree because I cannot tell what you really need, only what you're asking for. And, the questions you're asking indicate you don't understand the nature of the thing you're trying to do. Which is why I'm here helping you. I'd like you to (a) understand all of this better (b) prevent you from making the mistake of building an insecure system and (c) help you build a more secure system.

So, please don't ask about these things, right now. Just tell me what the problem is that you have (not key storage and MAC problems, but the security over all problem, what does these messages do, how do they fit into your system).

If you want to trust me, go check out my linked in page and my credentials. I spent the better part of decade securing computer systems, including time at Oracle where I advised 100's of application development teams; improving their security and improving database security. There were (and still are) a lot of problems there created because people failed to do things right the first time. I want you to do this right from the beginning.

user200312

3:22 PM

@AndrewPhilips Dear Andrew, first are you telling me everything that is written here: en.wikipedia.org/wiki/Message_authentication_code, is false? In that article it is mentioned that MAC can be used to protect both integrity AND authenticity

of the message

Andrew Philips

Listen, I get that this conversation is challenging. However, please bear with me and describe the problem you are trying to solve. Forget what you know for the moment. I really want to help you.

user200312

@AndrewPhilips At the least I have client and server. I want the messages which client sends to the server to be authenticated - e.g. the server should not accept messages from non legitimate users and vice versa

replay protection can also be provided

Andrew Philips

OK, do you have more than one client?

user200312

@AndrewPhilips Yes could be more

Andrew Philips

Great. Do you want to differentiate between clients? Do you want to know which client sent which message?

user200312

3:26 PM

@AndrewPhilips Preferably

Andrew Philips

OK. So, this is kind of like a user/password scheme, but not really and not yet. Let's keep going. I have another question.

Do you have more than one server receiving the messages? Or just the one.

user200312

There is one server and it receives messages from multiple clients

just one more sec, I will add smth. Thing is there is already a protocol which this client and server use to achieve above. Just it is not that secure, e.g. it uses DES. It also uses symmetric key to provide message authentication using MAC. So I was thinking if I can secure the storage of the key somehow, then I could as well leave current protocol and tunnel it through SSL say, or encrypt with some STRONGER cipher e.g. AES

So if I can find means to store keys securely on the client side, then I could leave existing protocol, and additionally encrypt it with stronger cipher say AES. and I am done. This current protocol works - just it isn't that secure as uses DES say for authentication etc.

Andrew Philips

OK, I'm sorry. I'm a little bit confused. Thanks for adding this information, this is helpful. I have another question, but I need to read your paragraph again.

OK, I think what you're telling me is there is already a secure network protocol in place and you are trying to modify or piggy back off of that to keep the network session going and you're also trying to improve the security of it?

Is this right?

user200312

@AndrewPhilips Yes we are trying to improve it becayse it uses DES for authentication

Andrew Philips

Got it. And, just for the sake of argument, why can't you just up it to AES or 3DES, for example.

user200312

3:32 PM

@AndrewPhilips Keys are stored in a file encrypted though

Andrew Philips

Sorry, answer the up it question first, then we will get to the keys...

user200312

@AndrewPhilips That is a good point I noticed this now, thing is DES is used in a way to obtain MAC - not for encryption, so maybe I can really replace it with better cipher and I am done

Andrew Philips

Well, maybe. Let's be thorough here, and fix whatever might be broken. There could be more stuff since the system was originally written or might have been done incorrectly.

So, how would you upgrade the encryption protocol? Is it a TLS cipher suite?

user200312

@AndrewPhilips Dear Andrew current protocol only supports authentication and I think(not sure) replay protection. It uses DES for authentication, that is it mainly

Andrew Philips

Got it. Was this protocol hand written?

user200312

3:36 PM

@AndrewPhilips Apparently it was written from some programmers some time ago

Andrew Philips

OK. Can you just drop in a TLS library (like Open SSL) to replace it?

user200312

@AndrewPhilips Good point but - if I drops in TLS - how do I ensure client authentication? Also if I store private key of client on client machine - I am going back to my initial problem - someone might steal that key

Andrew Philips

Right, key storage is a problem that we will have to address. One thing at a time, however.

When you say "how do I ensure client authentication", I think what you mean is how do you authenticate the client when using TLS?

IS that right?

user200312

@AndrewPhilips Also please note preferably I would like to improve this with as little changes to the project as possible - I mean from code, the server is huge C++ program, and I don't want to put many changes there - as one can introduce bugs

Andrew Philips

Got it on the low impact, low profile. I understand.

user200312

3:40 PM

@AndrewPhilips That is why I even thought about this stunnel.org/index.html

Andrew Philips

OK, so I took a quick look at stunnel. You're searching for the simplest solution.

user200312

@AndrewPhilips Seems like if I could tunnel my existing protocol through stunnel I am done

@AndrewPhilips No need for client authentication my current protocol would take care of that

Andrew Philips

Well, yes, perhaps you should do that. In case you can't, would you like to explore how to do it otherwise?

user200312

@AndrewPhilips Yes

Andrew Philips

OK, so let's drop stunnel from this convo. Let me re-read for a moment above and ask another question.

How come you write "it uses DES for authentication" Can you tell me more about what that means?

user200312

3:44 PM

@AndrewPhilips Sure I will check myself now, but idea is you can use symmetric ciphers to build message authentication codes from it. The document by Bellare I sent contains info about that too

Andrew Philips

Does it already work in the existing system or is this an idea you'd like to build? How does it currently work?

user200312

@AndrewPhilips No it is used like this - unfortunately I don

't have access to the source code now :(

Andrew Philips

OK, well, that's a challenge...

user200312

@AndrewPhilips I am not at the office. Yes but Bellare also mentions how to do that.. let me see

". The most general approach works like this. To authenticate a message M using the key K,
the sender will apply some encryption algorithm E to K, giving rise to a ciphertext C. When
we speak of encrypting M in this context, we are using the word in the broadest possible
sense, as any sort of keyed transformation on the message that obeys are earlier definition for
the syntax of an encryption scheme; in particular, we are not suggesting that C conceals M.
The sender S will transmit C to the receiver R. Maybe the receiver will receive C, or maybe

@AndrewPhilips From those lecture notes

@AndrewPhilips By Mihir Bellare

Andrew Philips

OK, I see. So, the original developer thought that one way to PROVE who the identity of remote user (computer) was to use DES (or a MAC) and a secret key unique to that remote user (computer) and run an exchange. Am I understanding that correctly?

user200312

3:50 PM

@AndrewPhilips Yes just there is no "exchange" Not sure what you meant, he basically generate a signature using this tools and sends along the message

and that's it

Andrew Philips

Sorry, I wrote "exchange" I meant "calculation".

user200312

@AndrewPhilips Yes using a secret key unique to client - a MAC is computed based on dES over the message, and sent along the message

Andrew Philips

OK, is it just one message infrequently or are there a lot of messages sent from a client around the same time?

user200312

@AndrewPhilips There can be many messages the client sends to server - I have doubt but not sure there maybe means of replay protection too, but I didn't check that yet

Andrew Philips

If I were designing this from scratch (meaning, doing it right from the beginning and not short cutting), I'd include a TLS library (like openssl) in my system and use that.

user200312

3:55 PM

@AndrewPhilips Yes I understand. Sticking TLS inside implementation now inside C++ could be challenging :( on the server side

Andrew Philips

The current system you have is not a good system, you already know that, you should upgrade in a way that makes it really secure based upon well reviewed s/w and does not rely on add hoc coding.

OK, why would it be challenging?

user200312

@AndrewPhilips I don't know it's large project, adding new features mayb introduce bugs, also many C++ crypto implementations aren't well documented

@AndrewPhilips But if I use SSL I still need to authenticate clients

Andrew Philips

Well, you already have a suspect crypto system to start with, so let's be clear that if your goal is better security, you should go towards your goal.

user200312

@AndrewPhilips I understand but hopefully with little changes to code. What do you think if in my current system I replace DES with AES?

Andrew Philips

I think without a deeper understanding of how all of this fits together, it's a challenge to make recommendations. Note, the more questions I ask, the more information you reveal, showing there is a lot more to this than what you originally presented in your questions. It's why I felt there was a protocol in play. Clearly, there is, even if you didn't create it!

user200312

3:59 PM

@AndrewPhilips Yes there is existing protocol - but I told you main characteristics of it

I can tell you more, just I don't have source at hand now

Andrew Philips

With that in mind and me unable to do a full security review, unless your company wants to hire me, I'd recommend we explore how to fit TLS into this.

I don't mean to sound facetious, this is complicated stuff, it's hard to give shoot from the hip answers for complex systems without making a mistake or providing standard guidance.

user200312

@AndrewPhilips But if I go see Mihir Bellares notes and check how to implement correct MAC - and have means of replay protection, that is also reasonable isn't it?

And stunnel you didn't like?

@AndrewPhilips I understand I did a MSc in Computer security

Andrew Philips

I think stunnel is fine, if you can implement it.

user200312

@AndrewPhilips If it will be possible yes - though someone may steal intercept data before it reaches stunnel (e.g. from my software till stunnel)

@AndrewPhilips And then I could leave my protocol intact right?

Andrew Philips

My concern about the notes you reference is that your piecemeal putting together cryptographic units. If you do this, and you examine all the types of security attacks and then build to defend against them, you'll be recreating TLS. So, why not just use TLS?

user200312

4:03 PM

@AndrewPhilips stunnel or maybe even VPN

Andrew Philips

For example, TLS solves Replay

Yes, stunnel or a VPN would also solve replay and other types of attacks.

user200312

@AndrewPhilips Again because I think to stick TLS in C++ code now sounds challenge to me :( And my protocol currently really doesn't sound to complex it has just two goals: message authentication and replay attack

Andrew Philips

I really like recommending existing infrastructure because it's been tested by lots of people and almost certainly has fewer security bugs.

Well, you only have those two for now. However, if your attacked in some other way that you don't understand because you're vulnerable, then you'll have a third or a fourth.

Also, you're concerned about key theft, that's an attack.

And, the theft of the key can be done by observing the message exchange because you don't rotate keys.

user200312

@AndrewPhilips Key attack from storage perspective but that remains even if I use TLS

On the client side someone may steal

users private ket=y

Andrew Philips

Yes, it does remain. That's not a mark against TLS, it is a mark against your algorithm, however, because of other vulnerabilities.

user200312

4:08 PM

@AndrewPhilips Yes I understand so let's say key storage problem remains

no matter I use TLS or existing

approach

Andrew Philips

Yup. that's correct.

So, let me show you how I can attack your system and guess the client key without stealing it from the client machine...

user200312

@AndrewPhilips So now I either can
1) Leave existing protocol and replace DES with AES
2) Or use stunnel
3) ....

Andrew Philips

MAC(msg, client_key)

user200312

@AndrewPhilips ok show

Andrew Philips

I see this, then offline try lots of keys for a long time until I find "client_key", then I can create new messages like: MAC(hacker_msg, client_key)

user200312

4:10 PM

@AndrewPhilips Yes good point but I assume if I use a GOOD MAC algorithm then brute force

should not

am I wrong

?

Andrew Philips

You never change the client_key, so if it takes me month, who cares?

user200312

be possible

Andrew Philips

Nope, brute force is not a problem if I through a lot of computation at it. If the thing I'm breaking into is valuable, then I'll spend time and effort to break it.

"I throw a lot..."

user200312

@AndrewPhilips Yes andrew but if I use good MAC and strong key it might take you

isn't it?

years

Andrew Philips

Not, really. don't make assumptions on people's commitment to breaking into things.

MAC is used for session based cryptography. It protects a session, which usually lasts for a few hours.

user200312

4:12 PM

@AndrewPhilips Yes I see but I am confident that there are MAC which are secure against brute force attacks, otherwise you have a point

Andrew Philips

nothing is secure against brute force. Only against brute force for a long time by today's standards.

user200312

@AndrewPhilips Please check this: en.wikipedia.org/wiki/…

Andrew Philips

The most common attack against HMACs is brute force to uncover the secret key.

That's from the article.

user200312

@AndrewPhilips Yup that's true although right now I am not sure whether it is possible to inject some strong key in a good MAC which makes brute force not practical

Andrew Philips

There are lots of attacks and because you and I aren't cryptographers, I'm suggesting we defer to the systems that have already been built to address these problems.

So, try stunnel and VPN to see if either of these can fix your security system.

Otherwise, make the case for TLS.

user200312

4:17 PM

@AndrewPhilips Yes I see just I am thinking of fixing this in a way which requires less code, and replacing DES with AES seems like to require little code intervention

Andrew Philips

Now, lets spend a moment on client authenticaiton under TLS

OK, well, you'll have to do what you like.

user200312

@AndrewPhilips Thanks, indeed this ""So, try stunnel and VPN to see if either of these can fix your security system." is one option

@AndrewPhilips right?

Andrew Philips

For client authentication, whatever you're doing currently is fine if you run inside of a TLS session.

user200312

"Now, lets spend a moment on client authenticaiton under TLS"

sure

@AndrewPhilips I see I mean I have current protocol right? So I will just additionally encrypt the message+MAC using AES

@AndrewPhilips No?

@AndrewPhilips I think this sounds well

imagine I leave protocol unchanged

and just encryot this using AES

Andrew Philips

Well, I would not manually encrypt. The challenge with that is there are a whole bunch of attacks that TLS addresses that you need to know and defeat "manually". By the time you're done, you'll have recreated TLS.

And, you'll probably have made a mistake. Which is why I recommend the libraries.

user200312

4:21 PM

@AndrewPhilips I mean I will just leave current protocol as is, and encrypt the message and MAC it sends using AES and send cipher text

this would be easier to implement

@AndrewPhilips And also secure because AES is strong cipher

isn't it?

Andrew Philips

"Easier to implement" - that depends upon your goal. If your goal is less programming work, then maybe. If your goal is more secure, then no, it's easier to implement TLS.

user200312

@AndrewPhilips Not less programming dear Andrew, just like I said adding lot of code to a existing large C++ project is risky

With AES I would just have to decipher ciphertext on the server side and done

Andrew Philips

Pick your poison. Risk is relative. Risk of code breakage. Risk of system attack. You'll have to decide which is riskier.

user200312

@AndrewPhilips Risk of introducing bug in code is not less risky especually in language such as C++ e.g. undefined behaviour etc

AES encryption on top doesn't sound well to you for some reasons :)

Andrew Philips

I don't trust your current system. I don't know who designed it, you don't have a good sense of it (you need to refer to the source code) and I'm generally against home grown protocols because I've seen too many be broken. So, yes, AES doesn't sound good because it feels like a patch on an already suspect protocol.

user200312

4:26 PM

@AndrewPhilips Yeah but if none can decipher AES text, then this is good already, isn't it?

@AndrewPhilips I can get better sense when I get to source code

Andrew Philips

You can't just stick cryptographic protocols together and hope for the best. So, you can't just stick AES in there and assume it's going to be fine. I

have never seen a home grown protocol that was secure. Your's isn't now by you own admission and I'm willing to be it won't be when you plug AES into it.

"willing to bet.."

user200312

@AndrewPhilips I see I see but if I can at least make

it more secure

I am sure adding AES on top of it

will make it more secure

or even replacing DES with AES don't you think?

I am also somewhat knowledgeable in security and could try to make this protocol little bit more secure

Or ask another question about that (e.g. when I decide to replace DES with AES etc.)

Andrew Philips

Well, I believe that most of the development work is a minor cost in the process of testing, QA'ing, smooth upgrading, etc. So, the dev costs are minimal compared to the gains of using a much more solid protocol.

user200312

@AndrewPhilips I see but please google undefined behaviour and what it means in C++ it means there may be bug which don't get revealed in testing for say even a month

Andrew Philips

I programmed for many years in C++. I know that language can be crazy making.

Here's a google search I just did on OpenSSL and C++. I'm sure you can dig into this, if you cared to. shanetully.com/2012/06/openssl-rsa-aes-and-c

user200312

4:34 PM

@AndrewPhilips Especially undefined behaviour it is type of bug compiler doesn't report

And you don't know when it can crash

@AndrewPhilips Maybe I could ditch SSL and just use public key encryption such as RSA

Andrew Philips

OK, so you could go that route. I wasn't going to suggest it because I didn't want to confuse the issue and you said messages were frequent, which would call for creating a session and leaving it open for some time rather than the public key version.

user200312

@AndrewPhilips Maybe client now encrypts the whole payload using servers public key?

and server responds with a signed message

Andrew Philips

With Public Key, each client and server could have public keys and you could sign with the client key and encrypt with the server key. That solves your problem.

It looks like this: Enc(Sign(msg, Client_Sign_key), Server_Enc_key)

Whoops! I got that backwards!!!!

user200312

@AndrewPhilips Yes but attacker can get ahold of the client key if it compromises machine

This way I am saying leave current protocol unchange

But encrypt the payload using servers

public key

Andrew Philips

Sign(Enc(msg, Server_Enc_Key), Client_Sign_Key)

user200312

4:39 PM

s

Andrew Philips

Attacker can always get whatever you leave on the client. We've already agreed that's a problem for every protocol.

user200312

@AndrewPhilips Yep but I already have some degree of authentication using existing protocol so I could leave existing protocol unchanged

and encrypt it using server's public key

@AndrewPhilips What do you think about that?

I suppose finding C++ implementation of RSA is easier

Andrew Philips

For the record, I'm still against roll your own protocol. If you use what I wrote (Sign(Enc)), I'd suggest it be all in PKI, not partial PKI and partial HMAC symmetric key.

Yes, I'm sure there are libraries for safe C++ RSA and OpenSSL.

user200312

@AndrewPhilips Yes but dropping existing protocol means rewriting all, just leaving it in, is less work it is better than plain text messages isn't it

I mean leaving existing protocol and top of it implementing public key / private key scheme is easier

@AndrewPhilips And I guess implementing just public key encryption and signature is easier than SSL implementation

Andrew Philips

Again, this is a matter of assessing risk and your goals. There's development work risk, bug risk and security risk. You need to have a conversation with your manager and work through everything, to understand all risks and make a decision that benefits your company. If you're only worried about the least amount of work, why change anything at all?

I'm not sure PKI is easier, it's just an alternative. It all depends upon what you're trying to accomplish.

user200312

4:44 PM

@AndrewPhilips Just C++ server part is bit scaring because of undefined behaviour

@AndrewPhilips It may even have some bugs and recompiling it with new compiler is even more risky - again due to undefined behaviour but it is different topic.
Btw what is your opinion about keys

??

Andrew Philips

I get it. Being scared makes you focused. It's not a reason to not do something, it's a reason to be really, really careful and understand what you're getting into. It tells you to bring in other people to help you make the decision. don't be afraid of being scared. It's a useful thing.

Opinion about what "keys"?

user200312

@AndrewPhilips How to store them?

It remains

right

a problem

Andrew Philips

You mean like at the client?

user200312

in every protocol I take

yes

is it possible

to store

would be nice

it securely

and if we can sum up the options I have

Andrew Philips

OK, so that's a problem. We struggled with this at Oracle. There are so many ways to do it badly or that look bad. I recommend OpenSSL because they have a notion of a wallet and you put your keys (or credentials) in there and then make it a server wallet or whatever they call it and make it OS accessible to only the user or process that needs it. That's how you solve the problem. There's no other way.

user200312

4:49 PM

@AndrewPhilips I see there is even

DPAPI

if you have heard

about it

Or maybe somehow to restrict access rigths from the OS

@AndrewPhilips Or there must be user intervention who enters password

Andrew Philips

OK, just read DPAPI. It's nothing more than a protected wallet like I described, just some fancy API bits added by MSFT. Not saying it's bad, just saying it's not anything more than storing the key data in a recoverable form. So, right, either human enters password (data not recoverable, human must be present) or machine can read it (no key outside of system, machine can recover the data somehow).

user200312

@AndrewPhilips Not sure I got your last sentence but to sum up, one my possible solution is
1) Store key securely e.g. use DPAPI, protect from OS with limiting rights etc.
2) use stunnel and existing protocol. Or VPN

am I right

:)

Andrew Philips

I don't recommend #1 for your current system because I don't recommend you stick with your current system. I do recommend #2 if you can determine it meets your needs. I recommend if #2 doesn't work, you move to C++ safe OpenSSL.

user200312

No I mean #1 and #2 must go HAND in HAND

they make sense

only together

Andrew Philips

Oh. Got it.

user200312

4:55 PM

@AndrewPhilips that should sound ok more or less

though

if I can

do it

Andrew Philips

Fine, use your existing system, if you must and send it all over a secure channel. That channel can be: STUNNEL, VPN or OpenSSL

user200312

@AndrewPhilips Yes that is one option

Andrew Philips

If you don't want to upgrade your authentication model. But keep in mind, I have no idea what your current model really looks like, so caveated.

user200312

@AndrewPhilips I see but if channeled through VPN should be ok more or less

What other options? I think these
1) Replace DES with AES. Or just encrypt existing protocol using AES. Try to manually improve this protocol using my knowledge
2) Dump everything and use plain SSL inside code
3) Or only RSA encryptio/signatures

am I right?

Andrew Philips

I don't know, you'll have to evaluate the system. I cannot say that VPN will work, because I don't know how it fits in. You're going to have to assess that. You've got the MsC in Computer Security, right?

user200312

4:58 PM

@AndrewPhilips yes

but that is not a joke I hope

Andrew Philips

Yup, those are your choices.

user200312

from yo

u

Andrew Philips

No, I wasn't joking.

user200312

:)

Andrew Philips

I smiled when I wrote that, not a joke.

Well, a joke, but in a kind way not a mean way.

user200312

4:59 PM

@AndrewPhilips I see these are my options
@AndrewPhilips I see but if channeled through VPN should be ok more or less
What other options? I think these
1) Replace DES with AES. Or just encrypt existing protocol using AES. Try to manually improve this protocol using my knowledge
2) Dump everything and use plain SSL inside code
3) Or only RSA encryptio/signatures

(or our first option with stunnel and improved key storage)

Andrew Philips

Here's the thing, I would never just patch this protocol, I'd do a full eval and analysis, and determine the costs and benefits of a complete overhaul or a partial patch with STUNNEL or VPN (if they can protect). I'd never do #1.

user200312

@AndrewPhilips I see I see just a complete rewrite maybe reallly costly

really

Andrew Philips

Got it. which is why I'd do the analysis in order to justify the situation. I wouldn't recommend a complete re-write without justification and justification takes work. Sorry, to ask this, but how old are you?

user200312

30

Andrew Philips

Got it. I'm 49, been a manager and a coder for decades.

user200312

5:06 PM

age is thirty. Or maybe when I get more details about protocol I can ask question how to improve it on crypto stack exchange site. and post my possible improved version

@AndrewPhilips I see I saw

Andrew Philips

You should be at the point where you feel comfortable analyzing this system, constructing alternatives and making recommendations. Engage your manger and co-workers. It will help you advance your career. You could try posting the protocol, but I'm not sure you're going to be happy with the response. I'd be interested in what you find out, if you do.

user200312

your linkedin

profile

Andrew Philips

Good luck with your process. I hope I helped you. I'm sorry it started out rough.

user200312

@AndrewPhilips It was nice talking, you seem a nice person, I am also sorry it started out that way. I'd be even glad to add you on linkedin or get email. Just a bit afraid, since I discussed these details with you:)

Andrew Philips

No worries. I usually don't link with people with whom I haven't worked. If you'd like to, go ahead and mention who you are. I'm a security professional and used to keeping secrets. I'd never divulge details outside of our conversation. It's entirely up to you.

user200312

5:13 PM

@AndrewPhilips I understand that thanks. No I am just saying becayse you really seem nice person with trying to help me. Even though now we don't have exact solution, but I hope we shed some lights on some directions, and at least I know now which directions I POSSIBLY have

right?

Andrew Philips

I think we've moved our understanding down the road. You've still got some work ahead of you.

user200312

@AndrewPhilips Yes, but at least now I know kind of alternative I have, e.g.
1) leave existing protocol, use stunnel + improve key storage security
2) Try to analyze and improve existing protocol
3) Use TLS
4) Use PKI

am I right?

Andrew Philips

Sounds like a plan. Good luck.

user200312

@AndrewPhilips And key storage remains issue in all

cases

Andrew Philips

Yup.

user200312

5:16 PM

@AndrewPhilips Thanks I hope to be able to talk to you in the future too. And if I happen to add you on Linkedin I hope you will remember me:)

Andrew Philips

Just remind me of this convo.

user200312

@AndrewPhilips Yep or I will just put a link to this question
So dear Andrew overall I think you are well familiar with the 4 situations I listed above

4 alternatives

Andrew Philips

Any link will do. cheers.

user200312

@AndrewPhilips Yes cheers to you too. SO dear Andrew just the 4 alternatives I mentioned above, I am just trying to make sure we understood each other, and I was also talking reasonable things

:)

those 4 alternatives make sense to you

@AndrewPhilips At this stage you don't have anything more to tell me

right?

Andrew Philips

I think you should start with these and do a complete analysis of them all. You might discover others along the way. That's the best I can help you with.

user200312

5:20 PM

@AndrewPhilips Thanks at this point you think there doesn't make much sense to add something from you right?

Andrew Philips

Yup, I think we're done. Good luck.

user200312

@AndrewPhilips Thanks a lot, good luck to you too!

@AndrewPhilips sorry just one more thing

about key storage I am really out of ideas there you have any possible directions I should investigate maybe

??

Andrew Philips

5:38 PM

PKCS 12

In cryptography, PKCS #12 defines an archive file format for storing many cryptography objects as a single file. It is commonly used to bundle a private key with its X.509 certificate or to bundle all the members of a chain of trust. A PKCS #12 file may be encrypted and signed. The internal storage containers, called "SafeBags", may also be encrypted and signed. A few SafeBags are predefined to store certificates, private keys and CRLs. Another SafeBag is provided to store any other data at individual implementer's choice. PKCS #12 is one of the family of standards called Public-Key Cryptography...

user200312

9:10 PM

@AndrewPhilips btw found some link here

2

Q: HMAC key storage for a web app?

If one is going to use an HMAC, I.E: http://php.net/manual/en/function.hash-hmac.php, where exactly are they storing the key? Without some sort of secure storage (i.e not in a local file or code), I feel like one is fooling oneself when using a HMAC (as with the above function). I missing someth...

about key storage, not sure if it applies to my case though-answer is bit unclear

Andrew Philips

10:48 PM

OK, I think I understand more what your system might be doing, IF you're doing something like this. If you're code is running HTTP-DIGEST with Nonces (I really recommend Nonces), then it's kind of secure, but still not optimal. Here's the Wiki on HTTP-Digest: en.wikipedia.org/wiki/Digest_access_authentication

This is really rather difficult getting things piecemeal. Honestly, I've given you a lot of my time. I hope you appreciate that. If you want me to do a security review, contact me through Linked In and we can discuss hiring my services. It was not my intention to use this process to drum up business. It's just that at some point, my time (I am self employed) becomes valuable to me and I can no longer donate it. Sincerely.

Transcript for

Discussion on answer by Andrew Philip…