Mixing
Proprietary RF Protocol Security
I've just been reading this article on proprietary RF protocols vs Bluetooth and it seems to be suggesting that the security through obscurity gained through a proprietary protocol is advantageous over the more well-known Bluetooth.
It states that
The case for proprietary PHY and protocol is strong if a design requires optimization in the direction of security...
and
...proprietary designs ensure “security-through-obscurity,” in that an RF interface that isn’t well known is harder to hack.
From a purely security standpoint, would I be better off developing my product targeting a proprietary RF protocol that I design, or sticking with Bluetooth?
bluetooth
asked Jan 15 at 0:24
Oliver.ROliver.R
184
add a comment |
I've just been reading this article on proprietary RF protocols vs Bluetooth and it seems to be suggesting that the security through obscurity gained through a proprietary protocol is advantageous over the more well-known Bluetooth.
It states that
The case for proprietary PHY and protocol is strong if a design requires optimization in the direction of security...
and
...proprietary designs ensure “security-through-obscurity,” in that an RF interface that isn’t well known is harder to hack.
From a purely security standpoint, would I be better off developing my product targeting a proprietary RF protocol that I design, or sticking with Bluetooth?
bluetooth
asked Jan 15 at 0:24
Oliver.ROliver.R
184
add a comment |
I've just been reading this article on proprietary RF protocols vs Bluetooth and it seems to be suggesting that the security through obscurity gained through a proprietary protocol is advantageous over the more well-known Bluetooth.
It states that
The case for proprietary PHY and protocol is strong if a design requires optimization in the direction of security...
and
...proprietary designs ensure “security-through-obscurity,” in that an RF interface that isn’t well known is harder to hack.
From a purely security standpoint, would I be better off developing my product targeting a proprietary RF protocol that I design, or sticking with Bluetooth?
bluetooth
asked Jan 15 at 0:24
Oliver.ROliver.R
184
I've just been reading this article on proprietary RF protocols vs Bluetooth and it seems to be suggesting that the security through obscurity gained through a proprietary protocol is advantageous over the more well-known Bluetooth.
It states that
The case for proprietary PHY and protocol is strong if a design requires optimization in the direction of security...
and
...proprietary designs ensure “security-through-obscurity,” in that an RF interface that isn’t well known is harder to hack.
From a purely security standpoint, would I be better off developing my product targeting a proprietary RF protocol that I design, or sticking with Bluetooth?
bluetooth
bluetooth
asked Jan 15 at 0:24
Oliver.ROliver.R
184
asked Jan 15 at 0:24
Oliver.ROliver.R
184
asked Jan 15 at 0:24
Oliver.ROliver.R
184
asked Jan 15 at 0:24
Oliver.ROliver.R
184
asked Jan 15 at 0:24
Oliver.ROliver.R
184
184
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
That article's security advice is so wrong that presenting it borders on engineering negligence. "Security through obscurity" has been known to be a flawed approach for over 160 years. Pretending that nobody cares about your signals is a strategy best left to the ostriches that came up with it; it is not an actual, viable security strategy in the modern world.
Like everything else associated with security, this past decade has seen the world getting much tougher for the security of RF communications. The introduction of cheap Software Defined Radio hardware has led to a host of open source RF protocol disassembly and analysis tools, rendering the security properties of most proprietary applications all but transparent. If you'd like to see some examples, here's a video demo showing decoding various 433MHz signals using rtl_433; and here's a Universal Radio Hacker tool that can automatically detect, parse, and playback many forms of communications. The only investment needed to get started is an under-$20 USB receiver and a computer.
Standardized protocols have the advantage of years of real-world attackers trying to break into the communications. The few comparatively secure protocols in common use today (Bluetooth, WPA3, NFC) are those that have had earlier implementations cracked and broken over and over, and through the iterative process have been refined and improved. Even so, today's "secure" protocols can have exploitable vulnerabilities discovered tomorrow.
So where does all that bad news that leave you? Your first task is to figure out what an attacker stands to gain by breaking your protocol. Can he remotely operate equipment? Unlock cars? Disable alarms? Make a children's toy emit terrifying noises? The more "value" your protocol protects (including your customers' reputations), the more incentive attackers have to crack it.
Today's "RF script kiddies" are an extremely well-armed bunch, and they gain respect by hacking new signals; do not discount their abilities or tenacity.
A homegrown protocol may be cheap, but it will be completely insecure. If security researchers and professionals can't get a protocol secure after 20 years of trying, you know it's not an easy problem to solve. Homegrown might be fine if you're looking to change the color of a desk lamp; it will not be so good if you're looking to operate door locks. A standard protocol will have a much better security model, but might have higher unit costs or energy requirements; and even a standard protocol won't remain perfect over time. Your best defense in both cases is to provide a firmware patching mechanism that will allow your customers to securely upgrade and fix future security bugs.
In summary: everything that DigiKey article said about security is wrong. Please disregard it. Your customers deserve much better.
answered Jan 15 at 3:41
John DetersJohn Deters
27.6k24191
1
Okay, very bad idea, thank you for the straightforward advice!
– Oliver.R
Jan 15 at 6:50
This is a great answer, especially the threat model stuff; this is where you define why and how you need to be protected. Figuring that out would be the first step. Perhaps a toy walky-talky can do with an insecure home grown RF design. Perhaps that
– John Keates
Jan 16 at 1:56
add a comment |
This is a great question and very important as companies move to industrial IoT, which is where I see this come up the most. I can say, from first hand pentesting experience, that proprietary protocols using "Security through obscurity" are very dangerous.
The problem with proprietary protocols is that they are not typically fully developed or developed with a specific focus on security in mind, or at all, in my experience. Typically the RF engineer to build the protocol is an EE not a security professional.
Proprietary protocols not being safe is also true with more than RF and also applies to ethernet or serial protocols. I've had companies tell me their device is secure because [pick someone] couldn't figure out the protocol. Yes, that can happen if you have a classic IT red-team, but when you send it to us and we pull out a spectrum analyzer and reverse it and everything is in plain text I'd call that almost no security. Definitely not security you can count on. I can personally verify my lab reversing multiple proprietary Ethernet protocols and 2 wireless RF and one IR. All insecure.
You can also run into multiple other problems, like information leakage, developer backdoors (how about a command to factory reset a device with no authentication, for example), and just broken QA. You also have to pay for all of that now.
Standard bluetooth has a built ability to use AES encryption. I'd highly recommend that approach. 6lowpan and Zigbee are less "known" but both have undoubtedly been fully broken apart by nation state security professionals, as if we did it in our 10 man lab I don't believe the NSA has not although, I have no proof.
So to be clear, if you would like to pay engineers and security engineers to build you a secure protocol and go through full QA and Pen testing, that's not a bad thing. If you want to create a simple, unencrypted protocol, and hope "no one will look" I'd say that's a recipe for disaster. Or you could just use Zigbee/Bluetooth and make sure encryption is enabled.
That said, yes proprietary protocols will be out of reach of the "Script Kiddie," but I wouldn't call that ideal security.
answered Jan 15 at 0:58
bashCypherbashCypher
1,650315
Agreed with this approach. I was thinking at a point designing an alternate to the IP protocol, but the possible security implication did not make viable for trying.
– Overmind
Jan 15 at 6:30
@Overmind I know comments aren't supposed to be for chat but I would love to talk about that. You can't DM in SE can you?
– bashCypher
Jan 15 at 22:47
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f201466%2fproprietary-rf-protocol-security%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
That article's security advice is so wrong that presenting it borders on engineering negligence. "Security through obscurity" has been known to be a flawed approach for over 160 years. Pretending that nobody cares about your signals is a strategy best left to the ostriches that came up with it; it is not an actual, viable security strategy in the modern world.
Like everything else associated with security, this past decade has seen the world getting much tougher for the security of RF communications. The introduction of cheap Software Defined Radio hardware has led to a host of open source RF protocol disassembly and analysis tools, rendering the security properties of most proprietary applications all but transparent. If you'd like to see some examples, here's a video demo showing decoding various 433MHz signals using rtl_433; and here's a Universal Radio Hacker tool that can automatically detect, parse, and playback many forms of communications. The only investment needed to get started is an under-$20 USB receiver and a computer.
Standardized protocols have the advantage of years of real-world attackers trying to break into the communications. The few comparatively secure protocols in common use today (Bluetooth, WPA3, NFC) are those that have had earlier implementations cracked and broken over and over, and through the iterative process have been refined and improved. Even so, today's "secure" protocols can have exploitable vulnerabilities discovered tomorrow.
So where does all that bad news that leave you? Your first task is to figure out what an attacker stands to gain by breaking your protocol. Can he remotely operate equipment? Unlock cars? Disable alarms? Make a children's toy emit terrifying noises? The more "value" your protocol protects (including your customers' reputations), the more incentive attackers have to crack it.
Today's "RF script kiddies" are an extremely well-armed bunch, and they gain respect by hacking new signals; do not discount their abilities or tenacity.
A homegrown protocol may be cheap, but it will be completely insecure. If security researchers and professionals can't get a protocol secure after 20 years of trying, you know it's not an easy problem to solve. Homegrown might be fine if you're looking to change the color of a desk lamp; it will not be so good if you're looking to operate door locks. A standard protocol will have a much better security model, but might have higher unit costs or energy requirements; and even a standard protocol won't remain perfect over time. Your best defense in both cases is to provide a firmware patching mechanism that will allow your customers to securely upgrade and fix future security bugs.
In summary: everything that DigiKey article said about security is wrong. Please disregard it. Your customers deserve much better.
answered Jan 15 at 3:41
John DetersJohn Deters
27.6k24191
1
Okay, very bad idea, thank you for the straightforward advice!
– Oliver.R
Jan 15 at 6:50
This is a great answer, especially the threat model stuff; this is where you define why and how you need to be protected. Figuring that out would be the first step. Perhaps a toy walky-talky can do with an insecure home grown RF design. Perhaps that
– John Keates
Jan 16 at 1:56
add a comment |
That article's security advice is so wrong that presenting it borders on engineering negligence. "Security through obscurity" has been known to be a flawed approach for over 160 years. Pretending that nobody cares about your signals is a strategy best left to the ostriches that came up with it; it is not an actual, viable security strategy in the modern world.
Like everything else associated with security, this past decade has seen the world getting much tougher for the security of RF communications. The introduction of cheap Software Defined Radio hardware has led to a host of open source RF protocol disassembly and analysis tools, rendering the security properties of most proprietary applications all but transparent. If you'd like to see some examples, here's a video demo showing decoding various 433MHz signals using rtl_433; and here's a Universal Radio Hacker tool that can automatically detect, parse, and playback many forms of communications. The only investment needed to get started is an under-$20 USB receiver and a computer.
Standardized protocols have the advantage of years of real-world attackers trying to break into the communications. The few comparatively secure protocols in common use today (Bluetooth, WPA3, NFC) are those that have had earlier implementations cracked and broken over and over, and through the iterative process have been refined and improved. Even so, today's "secure" protocols can have exploitable vulnerabilities discovered tomorrow.
So where does all that bad news that leave you? Your first task is to figure out what an attacker stands to gain by breaking your protocol. Can he remotely operate equipment? Unlock cars? Disable alarms? Make a children's toy emit terrifying noises? The more "value" your protocol protects (including your customers' reputations), the more incentive attackers have to crack it.
Today's "RF script kiddies" are an extremely well-armed bunch, and they gain respect by hacking new signals; do not discount their abilities or tenacity.
A homegrown protocol may be cheap, but it will be completely insecure. If security researchers and professionals can't get a protocol secure after 20 years of trying, you know it's not an easy problem to solve. Homegrown might be fine if you're looking to change the color of a desk lamp; it will not be so good if you're looking to operate door locks. A standard protocol will have a much better security model, but might have higher unit costs or energy requirements; and even a standard protocol won't remain perfect over time. Your best defense in both cases is to provide a firmware patching mechanism that will allow your customers to securely upgrade and fix future security bugs.
In summary: everything that DigiKey article said about security is wrong. Please disregard it. Your customers deserve much better.
answered Jan 15 at 3:41
John DetersJohn Deters
27.6k24191
1
Okay, very bad idea, thank you for the straightforward advice!
– Oliver.R
Jan 15 at 6:50
This is a great answer, especially the threat model stuff; this is where you define why and how you need to be protected. Figuring that out would be the first step. Perhaps a toy walky-talky can do with an insecure home grown RF design. Perhaps that
– John Keates
Jan 16 at 1:56
add a comment |
That article's security advice is so wrong that presenting it borders on engineering negligence. "Security through obscurity" has been known to be a flawed approach for over 160 years. Pretending that nobody cares about your signals is a strategy best left to the ostriches that came up with it; it is not an actual, viable security strategy in the modern world.
Like everything else associated with security, this past decade has seen the world getting much tougher for the security of RF communications. The introduction of cheap Software Defined Radio hardware has led to a host of open source RF protocol disassembly and analysis tools, rendering the security properties of most proprietary applications all but transparent. If you'd like to see some examples, here's a video demo showing decoding various 433MHz signals using rtl_433; and here's a Universal Radio Hacker tool that can automatically detect, parse, and playback many forms of communications. The only investment needed to get started is an under-$20 USB receiver and a computer.
Standardized protocols have the advantage of years of real-world attackers trying to break into the communications. The few comparatively secure protocols in common use today (Bluetooth, WPA3, NFC) are those that have had earlier implementations cracked and broken over and over, and through the iterative process have been refined and improved. Even so, today's "secure" protocols can have exploitable vulnerabilities discovered tomorrow.
So where does all that bad news that leave you? Your first task is to figure out what an attacker stands to gain by breaking your protocol. Can he remotely operate equipment? Unlock cars? Disable alarms? Make a children's toy emit terrifying noises? The more "value" your protocol protects (including your customers' reputations), the more incentive attackers have to crack it.
Today's "RF script kiddies" are an extremely well-armed bunch, and they gain respect by hacking new signals; do not discount their abilities or tenacity.
A homegrown protocol may be cheap, but it will be completely insecure. If security researchers and professionals can't get a protocol secure after 20 years of trying, you know it's not an easy problem to solve. Homegrown might be fine if you're looking to change the color of a desk lamp; it will not be so good if you're looking to operate door locks. A standard protocol will have a much better security model, but might have higher unit costs or energy requirements; and even a standard protocol won't remain perfect over time. Your best defense in both cases is to provide a firmware patching mechanism that will allow your customers to securely upgrade and fix future security bugs.
In summary: everything that DigiKey article said about security is wrong. Please disregard it. Your customers deserve much better.
answered Jan 15 at 3:41
John DetersJohn Deters
27.6k24191
That article's security advice is so wrong that presenting it borders on engineering negligence. "Security through obscurity" has been known to be a flawed approach for over 160 years. Pretending that nobody cares about your signals is a strategy best left to the ostriches that came up with it; it is not an actual, viable security strategy in the modern world.
Like everything else associated with security, this past decade has seen the world getting much tougher for the security of RF communications. The introduction of cheap Software Defined Radio hardware has led to a host of open source RF protocol disassembly and analysis tools, rendering the security properties of most proprietary applications all but transparent. If you'd like to see some examples, here's a video demo showing decoding various 433MHz signals using rtl_433; and here's a Universal Radio Hacker tool that can automatically detect, parse, and playback many forms of communications. The only investment needed to get started is an under-$20 USB receiver and a computer.
Standardized protocols have the advantage of years of real-world attackers trying to break into the communications. The few comparatively secure protocols in common use today (Bluetooth, WPA3, NFC) are those that have had earlier implementations cracked and broken over and over, and through the iterative process have been refined and improved. Even so, today's "secure" protocols can have exploitable vulnerabilities discovered tomorrow.
So where does all that bad news that leave you? Your first task is to figure out what an attacker stands to gain by breaking your protocol. Can he remotely operate equipment? Unlock cars? Disable alarms? Make a children's toy emit terrifying noises? The more "value" your protocol protects (including your customers' reputations), the more incentive attackers have to crack it.
Today's "RF script kiddies" are an extremely well-armed bunch, and they gain respect by hacking new signals; do not discount their abilities or tenacity.
A homegrown protocol may be cheap, but it will be completely insecure. If security researchers and professionals can't get a protocol secure after 20 years of trying, you know it's not an easy problem to solve. Homegrown might be fine if you're looking to change the color of a desk lamp; it will not be so good if you're looking to operate door locks. A standard protocol will have a much better security model, but might have higher unit costs or energy requirements; and even a standard protocol won't remain perfect over time. Your best defense in both cases is to provide a firmware patching mechanism that will allow your customers to securely upgrade and fix future security bugs.
In summary: everything that DigiKey article said about security is wrong. Please disregard it. Your customers deserve much better.
answered Jan 15 at 3:41
John DetersJohn Deters
27.6k24191
answered Jan 15 at 3:41
John DetersJohn Deters
27.6k24191
answered Jan 15 at 3:41
John DetersJohn Deters
27.6k24191
answered Jan 15 at 3:41
John DetersJohn Deters
27.6k24191
27.6k24191
1
Okay, very bad idea, thank you for the straightforward advice!
– Oliver.R
Jan 15 at 6:50
This is a great answer, especially the threat model stuff; this is where you define why and how you need to be protected. Figuring that out would be the first step. Perhaps a toy walky-talky can do with an insecure home grown RF design. Perhaps that
– John Keates
Jan 16 at 1:56
add a comment |
1
Okay, very bad idea, thank you for the straightforward advice!
– Oliver.R
Jan 15 at 6:50
This is a great answer, especially the threat model stuff; this is where you define why and how you need to be protected. Figuring that out would be the first step. Perhaps a toy walky-talky can do with an insecure home grown RF design. Perhaps that
– John Keates
Jan 16 at 1:56
1
1
Okay, very bad idea, thank you for the straightforward advice!
– Oliver.R
Jan 15 at 6:50
Okay, very bad idea, thank you for the straightforward advice!
– Oliver.R
Jan 15 at 6:50
This is a great answer, especially the threat model stuff; this is where you define why and how you need to be protected. Figuring that out would be the first step. Perhaps a toy walky-talky can do with an insecure home grown RF design. Perhaps that
– John Keates
Jan 16 at 1:56
This is a great answer, especially the threat model stuff; this is where you define why and how you need to be protected. Figuring that out would be the first step. Perhaps a toy walky-talky can do with an insecure home grown RF design. Perhaps that
– John Keates
Jan 16 at 1:56
add a comment |
This is a great question and very important as companies move to industrial IoT, which is where I see this come up the most. I can say, from first hand pentesting experience, that proprietary protocols using "Security through obscurity" are very dangerous.
The problem with proprietary protocols is that they are not typically fully developed or developed with a specific focus on security in mind, or at all, in my experience. Typically the RF engineer to build the protocol is an EE not a security professional.
Proprietary protocols not being safe is also true with more than RF and also applies to ethernet or serial protocols. I've had companies tell me their device is secure because [pick someone] couldn't figure out the protocol. Yes, that can happen if you have a classic IT red-team, but when you send it to us and we pull out a spectrum analyzer and reverse it and everything is in plain text I'd call that almost no security. Definitely not security you can count on. I can personally verify my lab reversing multiple proprietary Ethernet protocols and 2 wireless RF and one IR. All insecure.
You can also run into multiple other problems, like information leakage, developer backdoors (how about a command to factory reset a device with no authentication, for example), and just broken QA. You also have to pay for all of that now.
Standard bluetooth has a built ability to use AES encryption. I'd highly recommend that approach. 6lowpan and Zigbee are less "known" but both have undoubtedly been fully broken apart by nation state security professionals, as if we did it in our 10 man lab I don't believe the NSA has not although, I have no proof.
So to be clear, if you would like to pay engineers and security engineers to build you a secure protocol and go through full QA and Pen testing, that's not a bad thing. If you want to create a simple, unencrypted protocol, and hope "no one will look" I'd say that's a recipe for disaster. Or you could just use Zigbee/Bluetooth and make sure encryption is enabled.
That said, yes proprietary protocols will be out of reach of the "Script Kiddie," but I wouldn't call that ideal security.
answered Jan 15 at 0:58
bashCypherbashCypher
1,650315
Agreed with this approach. I was thinking at a point designing an alternate to the IP protocol, but the possible security implication did not make viable for trying.
– Overmind
Jan 15 at 6:30
@Overmind I know comments aren't supposed to be for chat but I would love to talk about that. You can't DM in SE can you?
– bashCypher
Jan 15 at 22:47
add a comment |
This is a great question and very important as companies move to industrial IoT, which is where I see this come up the most. I can say, from first hand pentesting experience, that proprietary protocols using "Security through obscurity" are very dangerous.
The problem with proprietary protocols is that they are not typically fully developed or developed with a specific focus on security in mind, or at all, in my experience. Typically the RF engineer to build the protocol is an EE not a security professional.
Proprietary protocols not being safe is also true with more than RF and also applies to ethernet or serial protocols. I've had companies tell me their device is secure because [pick someone] couldn't figure out the protocol. Yes, that can happen if you have a classic IT red-team, but when you send it to us and we pull out a spectrum analyzer and reverse it and everything is in plain text I'd call that almost no security. Definitely not security you can count on. I can personally verify my lab reversing multiple proprietary Ethernet protocols and 2 wireless RF and one IR. All insecure.
You can also run into multiple other problems, like information leakage, developer backdoors (how about a command to factory reset a device with no authentication, for example), and just broken QA. You also have to pay for all of that now.
Standard bluetooth has a built ability to use AES encryption. I'd highly recommend that approach. 6lowpan and Zigbee are less "known" but both have undoubtedly been fully broken apart by nation state security professionals, as if we did it in our 10 man lab I don't believe the NSA has not although, I have no proof.
So to be clear, if you would like to pay engineers and security engineers to build you a secure protocol and go through full QA and Pen testing, that's not a bad thing. If you want to create a simple, unencrypted protocol, and hope "no one will look" I'd say that's a recipe for disaster. Or you could just use Zigbee/Bluetooth and make sure encryption is enabled.
That said, yes proprietary protocols will be out of reach of the "Script Kiddie," but I wouldn't call that ideal security.
answered Jan 15 at 0:58
bashCypherbashCypher
1,650315
Agreed with this approach. I was thinking at a point designing an alternate to the IP protocol, but the possible security implication did not make viable for trying.
– Overmind
Jan 15 at 6:30
@Overmind I know comments aren't supposed to be for chat but I would love to talk about that. You can't DM in SE can you?
– bashCypher
Jan 15 at 22:47
add a comment |
This is a great question and very important as companies move to industrial IoT, which is where I see this come up the most. I can say, from first hand pentesting experience, that proprietary protocols using "Security through obscurity" are very dangerous.
The problem with proprietary protocols is that they are not typically fully developed or developed with a specific focus on security in mind, or at all, in my experience. Typically the RF engineer to build the protocol is an EE not a security professional.
Proprietary protocols not being safe is also true with more than RF and also applies to ethernet or serial protocols. I've had companies tell me their device is secure because [pick someone] couldn't figure out the protocol. Yes, that can happen if you have a classic IT red-team, but when you send it to us and we pull out a spectrum analyzer and reverse it and everything is in plain text I'd call that almost no security. Definitely not security you can count on. I can personally verify my lab reversing multiple proprietary Ethernet protocols and 2 wireless RF and one IR. All insecure.
You can also run into multiple other problems, like information leakage, developer backdoors (how about a command to factory reset a device with no authentication, for example), and just broken QA. You also have to pay for all of that now.
Standard bluetooth has a built ability to use AES encryption. I'd highly recommend that approach. 6lowpan and Zigbee are less "known" but both have undoubtedly been fully broken apart by nation state security professionals, as if we did it in our 10 man lab I don't believe the NSA has not although, I have no proof.
So to be clear, if you would like to pay engineers and security engineers to build you a secure protocol and go through full QA and Pen testing, that's not a bad thing. If you want to create a simple, unencrypted protocol, and hope "no one will look" I'd say that's a recipe for disaster. Or you could just use Zigbee/Bluetooth and make sure encryption is enabled.
That said, yes proprietary protocols will be out of reach of the "Script Kiddie," but I wouldn't call that ideal security.
answered Jan 15 at 0:58
bashCypherbashCypher
1,650315
This is a great question and very important as companies move to industrial IoT, which is where I see this come up the most. I can say, from first hand pentesting experience, that proprietary protocols using "Security through obscurity" are very dangerous.
The problem with proprietary protocols is that they are not typically fully developed or developed with a specific focus on security in mind, or at all, in my experience. Typically the RF engineer to build the protocol is an EE not a security professional.
Proprietary protocols not being safe is also true with more than RF and also applies to ethernet or serial protocols. I've had companies tell me their device is secure because [pick someone] couldn't figure out the protocol. Yes, that can happen if you have a classic IT red-team, but when you send it to us and we pull out a spectrum analyzer and reverse it and everything is in plain text I'd call that almost no security. Definitely not security you can count on. I can personally verify my lab reversing multiple proprietary Ethernet protocols and 2 wireless RF and one IR. All insecure.
You can also run into multiple other problems, like information leakage, developer backdoors (how about a command to factory reset a device with no authentication, for example), and just broken QA. You also have to pay for all of that now.
Standard bluetooth has a built ability to use AES encryption. I'd highly recommend that approach. 6lowpan and Zigbee are less "known" but both have undoubtedly been fully broken apart by nation state security professionals, as if we did it in our 10 man lab I don't believe the NSA has not although, I have no proof.
So to be clear, if you would like to pay engineers and security engineers to build you a secure protocol and go through full QA and Pen testing, that's not a bad thing. If you want to create a simple, unencrypted protocol, and hope "no one will look" I'd say that's a recipe for disaster. Or you could just use Zigbee/Bluetooth and make sure encryption is enabled.
That said, yes proprietary protocols will be out of reach of the "Script Kiddie," but I wouldn't call that ideal security.
answered Jan 15 at 0:58
bashCypherbashCypher
1,650315
edited Jan 15 at 1:07
answered Jan 15 at 0:58
bashCypherbashCypher
1,650315
answered Jan 15 at 0:58
bashCypherbashCypher
1,650315
answered Jan 15 at 0:58
bashCypherbashCypher
1,650315
1,650315
Agreed with this approach. I was thinking at a point designing an alternate to the IP protocol, but the possible security implication did not make viable for trying.
– Overmind
Jan 15 at 6:30
@Overmind I know comments aren't supposed to be for chat but I would love to talk about that. You can't DM in SE can you?
– bashCypher
Jan 15 at 22:47
add a comment |
Agreed with this approach. I was thinking at a point designing an alternate to the IP protocol, but the possible security implication did not make viable for trying.
– Overmind
Jan 15 at 6:30
@Overmind I know comments aren't supposed to be for chat but I would love to talk about that. You can't DM in SE can you?
– bashCypher
Jan 15 at 22:47
Agreed with this approach. I was thinking at a point designing an alternate to the IP protocol, but the possible security implication did not make viable for trying.
– Overmind
Jan 15 at 6:30
Agreed with this approach. I was thinking at a point designing an alternate to the IP protocol, but the possible security implication did not make viable for trying.
– Overmind
Jan 15 at 6:30
@Overmind I know comments aren't supposed to be for chat but I would love to talk about that. You can't DM in SE can you?
– bashCypher
Jan 15 at 22:47
@Overmind I know comments aren't supposed to be for chat but I would love to talk about that. You can't DM in SE can you?
– bashCypher
Jan 15 at 22:47
add a comment |
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f201466%2fproprietary-rf-protocol-security%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
