While your scenario is entirely plausible; why would anyone spend money to 'hack' a rental car? They wouldn't be able to predict who will drive it next or even when. I mean, sure, teenagers will shoplift spraypaint to tag up the local underpass; but with regards to this, the talented have better things to do and sophomoric aren't renting cars.
Personally, I'd worry about this less than I worry about skin cancer.
P.S. That being said, I will admit I bought a more expensive bluetooth OBD-II adapter to use in my explorer that requires a physical button press to pair. Cheaper adapters are generally discoverable when not connected to a host and used a generic 0000 or 1234 pin. I leave the adapter plugged in all the time because there's an old android tablet between the seats that logs OBD-II PIDs while I'm driving and auto-uploads them when I'm in my driveway.
Running out of conventional memory? Yeah, I know your pain. Well, I'll tell you a secret. There's this fancy thing called EMM386.. just add it to your CONFIG.SYS after the LOAD=HIMEM.SYS and don't forget to specify DOS=HIGH. It's really that easy and it should get you an easy extra 30 maybe even 45 kB more free RAM.
What he describes is plausible, especially if the flash is socketed. But, not bloody likely. Considering that this malware would have to add itself to the existing flash image as an option rom or by infecting and rewriting part of the bios code and then writing that back to the rom.. Unless this was a targeted attack, the malware author would have to work out logic for each one of the major base BIOSes in use - phoenix, award, dell, lenovo, etc to be able to infect them. This is ignoring lots of machines which prevent either prevent rewriting the flash without physical access or require the new system image to be signed. Also, keep in mind that testing this ahead of time is rather difficult given the wide range of different BIOSes on different motherboards, etc. any unexpected bug could render an infected machine unbootable. So, hell of a lot of work for the malware/virus author with quite a lot of risk for failure.. especially when there's a lot of lower hanging fruit.
I don't doubt that it's happened to someone out there.
Also, I do believe this is one of the scenarios Intel TXT is for.
What about the Sony SVO-5800? It would appear to be a "broadcast quality" sony s-vhs deck and would appear to be able to read and write regular VHS tapes. Am I missing something or is this a rare exception to your stated rule?
Are you new here? I'm surprised he isn't citing a petrified Natalie Portman covered in grits and vetted by the GNAA. "Netcraft confirms X" is an old, old, late 90s slashdot comment "joke." Granted, it's as funny as those forwarded email I get from my aunt; but it's the thought that counts, right?
If you're the same anonymous coward, then I am flattered that you returned to check your post for my reply.
> And pardon me, but could you explain to me what the need is for a(n undocumented!) way to gain access to "certain files" on a phone by a remote person ? As far as I can tell there is nothing on a phone a remote person should have access to without the explicit say-so of the owner.
Sweet jesus. The system is not an undocumented way to allow a reomte, third party unauthenticated arbitrary access to your data. It's a system used to allow the modem firmware running on a separate DSP core to save and recall information. Yes, there exists a <b>possibility</b> that a flaw in the modem firmware could allow a third party to command the modem to make IPC requests to the device's host processor to read information and then, potentially, transmit it back. There is no evidence to suggest that such a flaw exists.
> You mean to say that as they all have got similar backdoors (do they ?) its OK ? Strange reasoning...
No I don't mean to say all have any backdoors; a backdoor is a camouflaged or otherwise hidden system installed to circumvent access restrictions. This is niether camouflaged nor hidden. It's purpose is not to circumvent access controls. It is not a backdoor.
> Bottom line: A phone which has got RPC file-IO calls from the cellular into the smart part of the phone is at least questionable.
Questionable? Yes, of course. But do not attribute to malice what is adequately explained as incompetence.
I'm replying again because it occurred to me. to check the dictionary.
A backdoor is an indirect and devious system conceived for the purpose of allowing access to resources by circumventing security protections.
This is not. This is a set of IPC requests an "API" to allow the modem firmware to store non-volatile information in a specific location of the host phone's filesystem.
You're absolutely right that a backdoor is a backdoor; however, this is not a backdoor. If they'd really meant to introduce backdoors, don't you think they'd have made even a trivial effort to hide or obfuscate it? For example, D-Link's special request header “xmlset_roodkcableoj28840ybtide” that would bypass the web admin authentication. That's a backdoor. Minterpreting wrappers for read() and write() is not.
I do believe you missed the point of my comment entirely. These IPC requests for doing file I/O are there to allow the to read and write to a small subset of files constrained to a specific portion of directory hierarchy.
Yes, the modem could potentially read other files - limited by unix access controls, but it cannot read nor write from arbitrary files.
> Maybe you're right and it should be called "criminal negligence" instead.
I was growing the impression you'd authored a post with value worth contributing to the discussion until I noticed this statement. I thank you for announcing your ignorance so clearly.
Want to prevent people from destroying/modifying your IMEI using a yet-unknown-and-incredibly-unlikely-but-still-technically-possible hypothetical remote privilege escalation? Use the chmod(1) command with the argument 640 to remove the group write permissions.
Really, how is this unlike any other phone that has a cellmodem with firmware and nvram?
If you really wanted to limit what files the rild could interact with on behalf of the modem, a trivial bind mount and chroot( ) would suffice.
Unfortunately, the daemon that opens, reads, and writes files on behalf of the modem, is running as a specific unprivileged user, radio (uid 1001 on my phone.) It could only wipe out the information I have in/efs and a few specific files in/data. Nothing bars it from triggering some other system/daemon/process responsible for more thorough wiping of data.
Two things, "Even Ham radio operators?" When did they become the retards of the RF world - I thought that title belonged to CB'ers? Honestly, hams are not interested in your phone.
While, yes, technically anyone can communicate with your modem; anyone can communicate with your wifi card or your bluetooth adapter as well. And it would appear that the samsung radio interface IPC layer at least has a modicum less access to the entirety of your device than your wifi driver - which is in the kernel. People have, in the past, exploited mistakes in wifi drivers and wifi card firmware to remote exploit via wifi. (*: The specific instance I remember, was with an old intel 802.11b/g card and specially crafted management frames which could be trivially spoofed and didn't need to be encrypted to be accepted by the wireless card. The proof of concept was able to issue busmaster DMA read/writes which, ostensibly, would allow rewriting arbitrary kernel ram, etc.)
Across the scope of samsung phones I was able to check (ok, two of them), the radio interface, the android host side of this communications channel, runs as uid 1001 (radio). As far as my cursory inspection revealed, meant that the radio/modem can read/write the files in/efs and only read a number of other places, such as/sdcard. Granted,/sdcard contains a lot of your personal data. My point is that, in this case, a compromised modem is still less privileged than a compromised android service or, worse, compromised driver/kernel. Also, given that these IPC instructions are used for reading/writing modem "nvram" data such as the handset IMEI, to describe them as a "backdoor" is horribly inappropriate.
So, yeah, as you said, "huge technological challenge." Agreed. But, the idea that a data modem may be exploitable is by no means new.
I couldn't agree more. There is no evidence to suggest that it's a malicious backdoor.
A quick strings on my samsung captivate glide's modem firmware, reveals all manner of novel debug messages and log strings:
err/CP_MA_TRACE_%d_%04d%02d%02d%02d%02d%02d.bin [DUMP] FILE OPEN FAIL [ERROR]%s,%d,%s [DUMP] FILE CREATE FAIL [DUMP] Write MA Trace To/data/efs/err ===== aurrcbp: discard cell due to system information read error [Net]NV Read Fail! OEM_NVM_TESTBED
etc..
I do know that a lot of data persistence for the radio is done with dotfiles scattered around and throughout/data and/efs (because real nvram is expensive).
I'm curious what functionality is affected, if any is, by rejecting any of these IPC_RFS_ I/O.
I don't think it's clearly a backdoor. But, I do believe the concern is warranted. The radio/modem's firmware blob is not auditable. Perhaps a combination of logging/auditing filesystem requests and limiting which files are accessible by the RILD? Actually, isn't the rild run as an unprivileged user, radio? (Possibly for this very reason?)
At risk of being put online? Don't people risk exposing their license plates every time they back out of the garage?
I think the real concern is, "This just puts millions of illegally parking individuals at risk of being publicly shamed."
The best protection for any one concerned their license plate may end up online seems pretty simple and obvious: think ahead, be considerate, and don't park like an asshole.
Can't you just download the keplerian elements from NORAD and use gpredict? Actually, doesn't gpredict automate that for you? I don't think you need any special hardware, just an accurate clock.
You know, I think the lack of fire alarms is by far the biggest WTF especially considering how much effort they invested in the HV room's grounding setup, for example.
So, I read your initial question a bit closer and realized you'd identified the IPs as microsoft and amazon services. In fact, I suspect they're IPs related to content distribution servers. I'm quite certain your router's DOS warnings are false positives.
Your problem is most certainly not the result of a DOS.
I can envision two scenarios. First, the less likely one.
First Scenario: Trojan Horse One or more machines on your network have been infected/trojaned/compromised somehow. Every time you switch your external IP address, the infected machine dutifully contacts it's nefarious overloards with the news. There's a good chance that one of your compromised machines may actually be part of a botnet. One important question is, "what conditions, specifically, trigger my router's 'DOS attack from xxx' in it's logs." These warnings could well be simply legitimate traffic.
Second Scenario: Operator Error. Does anyone in your house use BitTorrent? If so, you're probably overflowing your upstream channel and, lo and behold, TCP acks start dropping like flies in a pool of DDT. Netflix doesn't really require a lot of bandwidth to stream it's content and it can manage with even moderate tcp congestion control. If your internet suddenly stops working, I'd suggest checking if your DSL modem has an internal diagnostic webpage. There's a convention, especially common to cablemodems, where the cable/dsl modem will accept traffic to 192.168.100.1 as itself. So, simply browse to http://192.168.100.1 and check if you have any signal quality issues. Basically, the situation needs to be more closely analyzed. Check your bandwidth usage on your router, if you find that your upload traffic is at or near the limit of your bandwidth - if so, get the roommate torrenting to cap his upload to something reasonable - like half of your upload limit.
Your router is fine. No greater, bigger, or fancier of a router will improve your situation if you really, truly are getting DOS'd. If the amount of packets being spewed at your IP address consumes the entirety of your subscribed bandwidth, then that's that. A fancier car won't get you through a traffic jam any faster than my honda, though, I imagine the fancier car's AC might actually work... which would be novel.
Bear in mind that there are different types of DOS attacks. Ping floods or UDP floods/smurf attacks. Making as many concurrent TCP connections to a server as possible to consume the server's kernel connection bookkeeping structures as well as to monopolize file descriptors in the actual server application. Botnet's may even DOS by making as many concurrent requests (you try to go for the cpu intensive ones, like, doing a directory lookup for *.) to consume the server's resources and, effectively, deny service to legitimate users. Oh, and if they get really fancy, they'll use a reverse tarpit wherein the client intentionally drags it's feet receiving the reply (a few bytes here, a few bytes 20 seconds later.) requiring the server's outbound buffers and application contexts bloated.
The above is why I genuinely doubt the veracity of your router's "DOS ATTACK FROM XXY" log message. Also because designing a computer program for identifying what traffic constitutes a DOS and what is legitimate are really quite non trivial.
Oh, hey, my backups are done and it's time to take these tapes to the vault; therefore, I shall conclude my post.
As usual, people fear what they don't understand. The trick to TPM is *WHO HAS THE KEYS*. If *I* have the keys, it is a great feature. TPM itself isn't inherently bad any more than any safe is inherently bad.
I use my TPM to store my sshkeys. Unfortunately, only RSA. Also, I have no idea what the private key is, it was generated and stored inside the TPM. The TPM even does the signing internally (I use a hacked up version of ssh-agent that basically passes requests to/from the TPM as if it were a smartcard.)
Advantages? 1. If someone cracks my laptop, they can only sign with my key while they are connected to it. 2. If I reinstall, swap harddrives, whatever, my keys are still there. 3. If someone steals my harddrive, they dont have my keys. 4. Novelty. I'm the only person I know that has used their TPM to do anything.
Cons? 1. I can't get my private key out. 2. If someone figures out how to get my private key out AND they crack my laptop, they could steal my private key. 3. It's kinda slow. 4. If my motherboard dies, my private key goes with it. I'm sure there are a few more.
Slashdot Mirror
Well that's obvious. We stay down there for the organic, all-natural artisinal radon gas, of course.
While likely related, Martin Burnicki posted a more detailed explanation of the actual event to the time-nuts mailing list:
https://www.febo.com/pipermail...
While your scenario is entirely plausible; why would anyone spend money to 'hack' a rental car? They wouldn't be able to predict who will drive it next or even when. I mean, sure, teenagers will shoplift spraypaint to tag up the local underpass; but with regards to this, the talented have better things to do and sophomoric aren't renting cars.
Personally, I'd worry about this less than I worry about skin cancer.
P.S. That being said, I will admit I bought a more expensive bluetooth OBD-II adapter to use in my explorer that requires a physical button press to pair. Cheaper adapters are generally discoverable when not connected to a host and used a generic 0000 or 1234 pin. I leave the adapter plugged in all the time because there's an old android tablet between the seats that logs OBD-II PIDs while I'm driving and auto-uploads them when I'm in my driveway.
Running out of conventional memory? Yeah, I know your pain. Well, I'll tell you a secret. There's this fancy thing called EMM386.. just add it to your CONFIG.SYS after the LOAD=HIMEM.SYS and don't forget to specify DOS=HIGH. It's really that easy and it should get you an easy extra 30 maybe even 45 kB more free RAM.
Cheers.
P.S. MSCDEX is for wimps.
I agree. I call bullshit.
What he describes is plausible, especially if the flash is socketed. But, not bloody likely. Considering that this malware would have to add itself to the existing flash image as an option rom or by infecting and rewriting part of the bios code and then writing that back to the rom.. Unless this was a targeted attack, the malware author would have to work out logic for each one of the major base BIOSes in use - phoenix, award, dell, lenovo, etc to be able to infect them. This is ignoring lots of machines which prevent either prevent rewriting the flash without physical access or require the new system image to be signed. Also, keep in mind that testing this ahead of time is rather difficult given the wide range of different BIOSes on different motherboards, etc. any unexpected bug could render an infected machine unbootable. So, hell of a lot of work for the malware/virus author with quite a lot of risk for failure.. especially when there's a lot of lower hanging fruit.
I don't doubt that it's happened to someone out there.
Also, I do believe this is one of the scenarios Intel TXT is for.
What about the Sony SVO-5800? It would appear to be a "broadcast quality" sony s-vhs deck and would appear to be able to read and write regular VHS tapes. Am I missing something or is this a rare exception to your stated rule?
It appears I set it as a preference once. I hadn't bothered to change it. This better? Sorry for the horrification.
That's correct. Netcraft confirms X has never, to the best of my knowledge, related to TFA.
Are you new here? I'm surprised he isn't citing a petrified Natalie Portman covered in grits and vetted by the GNAA. "Netcraft confirms X" is an old, old, late 90s slashdot comment "joke." Granted, it's as funny as those forwarded email I get from my aunt; but it's the thought that counts, right?
It's sad, but it's true. Kind of like x86. Did you know IPv6 is almost 20 years old?
If you're the same anonymous coward, then I am flattered that you returned to check your post for my reply.
...
> And pardon me, but could you explain to me what the need is for a(n undocumented!) way to gain access to "certain files" on a phone by a remote person ? As far as I can tell there is nothing on a phone a remote person should have access to without the explicit say-so of the owner.
Sweet jesus. The system is not an undocumented way to allow a reomte, third party unauthenticated arbitrary access to your data. It's a system used to allow the modem firmware running on a separate DSP core to save and recall information. Yes, there exists a <b>possibility</b> that a flaw in the modem firmware could allow a third party to command the modem to make IPC requests to the device's host processor to read information and then, potentially, transmit it back. There is no evidence to suggest that such a flaw exists.
> You mean to say that as they all have got similar backdoors (do they ?) its OK ? Strange reasoning
No I don't mean to say all have any backdoors; a backdoor is a camouflaged or otherwise hidden system installed to circumvent access restrictions. This is niether camouflaged nor hidden. It's purpose is not to circumvent access controls. It is not a backdoor.
> Bottom line: A phone which has got RPC file-IO calls from the cellular into the smart part of the phone is at least questionable.
Questionable? Yes, of course. But do not attribute to malice what is adequately explained as incompetence.
I'm replying again because it occurred to me. to check the dictionary.
A backdoor is an indirect and devious system conceived for the purpose of allowing access to resources by circumventing security protections.
This is not. This is a set of IPC requests an "API" to allow the modem firmware to store non-volatile information in a specific location of the host phone's filesystem.
You're absolutely right that a backdoor is a backdoor; however, this is not a backdoor. If they'd really meant to introduce backdoors, don't you think they'd have made even a trivial effort to hide or obfuscate it? For example, D-Link's special request header “xmlset_roodkcableoj28840ybtide” that would bypass the web admin authentication. That's a backdoor. Minterpreting wrappers for read() and write() is not.
I do believe you missed the point of my comment entirely. These IPC requests for doing file I/O are there to allow the to read and write to a small subset of files constrained to a specific portion of directory hierarchy.
Yes, the modem could potentially read other files - limited by unix access controls, but it cannot read nor write from arbitrary files.
> Maybe you're right and it should be called "criminal negligence" instead.
I was growing the impression you'd authored a post with value worth contributing to the discussion until I noticed this statement. I thank you for announcing your ignorance so clearly.
Want to prevent people from destroying/modifying your IMEI using a yet-unknown-and-incredibly-unlikely-but-still-technically-possible hypothetical remote privilege escalation? Use the chmod(1) command with the argument 640 to remove the group write permissions.
Really, how is this unlike any other phone that has a cellmodem with firmware and nvram?
If you really wanted to limit what files the rild could interact with on behalf of the modem, a trivial bind mount and chroot( ) would suffice.
Unfortunately, the daemon that opens, reads, and writes files on behalf of the modem, is running as a specific unprivileged user, radio (uid 1001 on my phone.) It could only wipe out the information I have in /efs and a few specific files in /data. Nothing bars it from triggering some other system/daemon/process responsible for more thorough wiping of data.
It's no more a backdoor than using using static functions in your compiled C. Simply because it's not documented, does not make it a backdoor.
Two things, "Even Ham radio operators?" When did they become the retards of the RF world - I thought that title belonged to CB'ers? Honestly, hams are not interested in your phone.
While, yes, technically anyone can communicate with your modem; anyone can communicate with your wifi card or your bluetooth adapter as well. And it would appear that the samsung radio interface IPC layer at least has a modicum less access to the entirety of your device than your wifi driver - which is in the kernel. People have, in the past, exploited mistakes in wifi drivers and wifi card firmware to remote exploit via wifi. (*: The specific instance I remember, was with an old intel 802.11b/g card and specially crafted management frames which could be trivially spoofed and didn't need to be encrypted to be accepted by the wireless card. The proof of concept was able to issue busmaster DMA read/writes which, ostensibly, would allow rewriting arbitrary kernel ram, etc.)
Across the scope of samsung phones I was able to check (ok, two of them), the radio interface, the android host side of this communications channel, runs as uid 1001 (radio). As far as my cursory inspection revealed, meant that the radio/modem can read/write the files in /efs and only read a number of other places, such as /sdcard. Granted, /sdcard contains a lot of your personal data. My point is that, in this case, a compromised modem is still less privileged than a compromised android service or, worse, compromised driver/kernel. Also, given that these IPC instructions are used for reading/writing modem "nvram" data such as the handset IMEI, to describe them as a "backdoor" is horribly inappropriate.
So, yeah, as you said, "huge technological challenge." Agreed. But, the idea that a data modem may be exploitable is by no means new.
I couldn't agree more. There is no evidence to suggest that it's a malicious backdoor.
A quick strings on my samsung captivate glide's modem firmware, reveals all manner of novel debug messages and log strings:
err/CP_MA_TRACE_%d_%04d%02d%02d%02d%02d%02d.bin /data/efs/err =====
[DUMP] FILE OPEN FAIL
[ERROR]%s,%d,%s
[DUMP] FILE CREATE FAIL
[DUMP] Write MA Trace To
aurrcbp: discard cell due to system information read error
[Net]NV Read Fail! OEM_NVM_TESTBED
etc..
I do know that a lot of data persistence for the radio is done with dotfiles scattered around and throughout /data and /efs (because real nvram is expensive).
I'm curious what functionality is affected, if any is, by rejecting any of these IPC_RFS_ I/O.
I don't think it's clearly a backdoor. But, I do believe the concern is warranted. The radio/modem's firmware blob is not auditable. Perhaps a combination of logging/auditing filesystem requests and limiting which files are accessible by the RILD? Actually, isn't the rild run as an unprivileged user, radio? (Possibly for this very reason?)
I always include a $20.00 and a note when I send a laptop in for repair. In the note I explain exactly what I'd like done. Always works with Lenovo.
At risk of being put online? Don't people risk exposing their license plates every time they back out of the garage?
I think the real concern is, "This just puts millions of illegally parking individuals at risk of being publicly shamed."
The best protection for any one concerned their license plate may end up online seems pretty simple and obvious: think ahead, be considerate, and don't park like an asshole.
Can't you just download the keplerian elements from NORAD and use gpredict? Actually, doesn't gpredict automate that for you? I don't think you need any special hardware, just an accurate clock.
I'm sorry but the energy density of hopes and dreams is nowhere close to that of gasoline.
You know, I think the lack of fire alarms is by far the biggest WTF especially considering how much effort they invested in the HV room's grounding setup, for example.
Hindsight's 20/20.
So, I read your initial question a bit closer and realized you'd identified the IPs as microsoft and amazon services. In fact, I suspect they're IPs related to content distribution servers. I'm quite certain your router's DOS warnings are false positives.
Your problem is most certainly not the result of a DOS.
I can envision two scenarios. First, the less likely one.
First Scenario: Trojan Horse
One or more machines on your network have been infected/trojaned/compromised somehow. Every time you switch your external IP address, the infected machine dutifully contacts it's nefarious overloards with the news. There's a good chance that one of your compromised machines may actually be part of a botnet. One important question is, "what conditions, specifically, trigger my router's 'DOS attack from xxx' in it's logs." These warnings could well be simply legitimate traffic.
Second Scenario: Operator Error.
Does anyone in your house use BitTorrent? If so, you're probably overflowing your upstream channel and, lo and behold, TCP acks start dropping like flies in a pool of DDT. Netflix doesn't really require a lot of bandwidth to stream it's content and it can manage with even moderate tcp congestion control. If your internet suddenly stops working, I'd suggest checking if your DSL modem has an internal diagnostic webpage. There's a convention, especially common to cablemodems, where the cable/dsl modem will accept traffic to 192.168.100.1 as itself. So, simply browse to http://192.168.100.1 and check if you have any signal quality issues. Basically, the situation needs to be more closely analyzed. Check your bandwidth usage on your router, if you find that your upload traffic is at or near the limit of your bandwidth - if so, get the roommate torrenting to cap his upload to something reasonable - like half of your upload limit.
Your router is fine. No greater, bigger, or fancier of a router will improve your situation if you really, truly are getting DOS'd. If the amount of packets being spewed at your IP address consumes the entirety of your subscribed bandwidth, then that's that. A fancier car won't get you through a traffic jam any faster than my honda, though, I imagine the fancier car's AC might actually work... which would be novel.
Bear in mind that there are different types of DOS attacks. Ping floods or UDP floods/smurf attacks. Making as many concurrent TCP connections to a server as possible to consume the server's kernel connection bookkeeping structures as well as to monopolize file descriptors in the actual server application. Botnet's may even DOS by making as many concurrent requests (you try to go for the cpu intensive ones, like, doing a directory lookup for *.) to consume the server's resources and, effectively, deny service to legitimate users. Oh, and if they get really fancy, they'll use a reverse tarpit wherein the client intentionally drags it's feet receiving the reply (a few bytes here, a few bytes 20 seconds later.) requiring the server's outbound buffers and application contexts bloated.
The above is why I genuinely doubt the veracity of your router's "DOS ATTACK FROM XXY" log message. Also because designing a computer program for identifying what traffic constitutes a DOS and what is legitimate are really quite non trivial.
Oh, hey, my backups are done and it's time to take these tapes to the vault; therefore, I shall conclude my post.
Do some more diagnosis and good luck!
As usual, people fear what they don't understand. The trick to TPM is *WHO HAS THE KEYS*. If *I* have the keys, it is a great feature. TPM itself isn't inherently bad any more than any safe is inherently bad.
I use my TPM to store my sshkeys. Unfortunately, only RSA. Also, I have no idea what the private key is, it was generated and stored inside the TPM. The TPM even does the signing internally (I use a hacked up version of ssh-agent that basically passes requests to/from the TPM as if it were a smartcard.)
Advantages?
1. If someone cracks my laptop, they can only sign with my key while they are connected to it.
2. If I reinstall, swap harddrives, whatever, my keys are still there.
3. If someone steals my harddrive, they dont have my keys.
4. Novelty. I'm the only person I know that has used their TPM to do anything.
Cons?
1. I can't get my private key out.
2. If someone figures out how to get my private key out AND they crack my laptop, they could steal my private key.
3. It's kinda slow.
4. If my motherboard dies, my private key goes with it.
I'm sure there are a few more.