|
info4U Unregistered guest | Nagra 2: The $07 and $1C commands - A technical discussion -------------------------------------------------------------------------------- First off, this discussion is directed to the handful of real technical experts out there. The layman is also welcome to read this thread for it will give him a realistic picture of the new encryption technology, but he should refrain from participating in this discussion if he has nothing of technical merit to contribute. Otherwise, this thread will degenerate into useless rambling. I decided to post my findings because there is so much mis-information out there. There has been much talk recently that Nagra 2 is an impenetrable fortress that will never be compromised, much like the P4 card. At any rate, that is the prevailing view among the layman. Perhaps this thread will enlighten many of you. Anyone who has logged the Nagra 2 datastream and compared it to the Nagra 1 datastream will be astonished - nothing much has changed! Some of the commands have been renamed and slightly re-formatted. Why were the commands re-named? Most likely so that a Nagra 1 card wouldn't get confused with commands directed to the Nagra 2 card and vice-versa, while both the Nagra 1 and 2 streams were active together. Now, there are some commands that come down in plaintext and others that are encrypted. The plaintext commands are trivial and can be easily emulated for both Nagra 1 and 2 and we won't bother discussing them. The encrypted commands are $04, $07 and $1C for Nagra 2. (The corresponding ones for Nagra 1 are $00, $03 and $13). We can completely ignore command $04 because it only provides updates to the card that are not critical to generating video. This was the purpose of the $00 command in Nagra 1 and as many of you know, when you put blocker code on your Nagra 1 cards, you are simply ignoring command $00, but you still get video! So, that just leaves commands $07 and $1C. Since this is the heart of the Nagra 2 encryption, it is quite astonishing that nobody has much to say about these commands even when the demise of Nagra 1 is upon us. Well, here is where the discussion gets more technical, so do try to follow along. Technical Discussion: Command $07 Well, it would help if we all knew what a command $07 looks like, so here is a recent log of that command: 21 00 4D ; A0 CA 00 00 ;Standard Header 47 ;Instruction Length 07 ;Command 45 ;Command Data Length 01 01 ;System ID 86 00 08 ;ECM Type, Key Select xx xx xx xx xx xx xx xx ;Valid Hash (Signature) xx xx xx xx xx xx xx xx ;Encrypted Packet 1 xx xx xx xx xx xx xx xx ;Encrypted Packet 2 xx xx xx xx xx xx xx xx ;Encrypted Packet 3 xx xx xx xx xx xx xx xx ;Encrypted Packet 4 xx xx xx xx xx xx xx xx ;Encrypted Packet 5 xx xx xx xx xx xx xx xx ;Encrypted Packet 6 xx xx xx xx xx xx xx xx ;Encrypted Packet 7 02 ;Expected Response Length cs ;Checksum And the standard response from the card: 12 00 04 ; 87 ;Standard Response Header 00 ;Response Code Length 90 00 ;SW1/SW2 53 ;Checksum Well, for those of you who are familiar with Nagra 1, it looks exactly the same as the $03 command except we have 7 encrypted packets instead of 4. The first question we need to ask is why are there 3 more packets? The answer, as you will see later on when we discuss the $1C command is that 6 control words ?? are being sent as opposed to 2 in the Nagra 1 setup. So, we would expect 4 more encrypted packets over the original 4 in Nagra 1. But that would be a total of 8 packets and not 7? But remember, with Nagra 1, there were some pad bytes that they are probably now using for the extra control words. So 7 encrypted packets sounds about right. Now, what is the encryption being used? We can certainly rule out 64 byte RSA because there are only 56 bytes of data. So it has to be a block cipher that operates on 8 bytes or 64 bits at a time. We can rule out any block ciphers that operate on 16 bytes or 128 bits at a time because we have 7 packets and not 8. So what are the cipher candidates? DES, 3-DES, IDEA. There are other candidates like Lucifer, Madryga, NewDES, FEAL, etc. The problem with these latter ciphers is that they have either been proven unreliable or simply aren't widely implemented on silicon. I am hesitant to even include IDEA in the list because there has been no rush by industry to adopt it as a replacement to DES and a commercial license must be granted by the inventors for its use. IDEA also uses a 128 bit key and operates on 64 bits of data. Also, patents filed by Kudelski indicate a 64 bit ECM key and not 128 bit. Many in the testing community have suggested that 128 bit IDEA is being used. Yet, they have not offered any proof of this. They are welcome to substantiate their claims here. This writer believes that DES or variation of DES such as 3-DES is being used, similar to Nagra 1. Why would they change this encryption algorithm when it was never compromised? I mean everyone was getting the DES keys from card dumps and NOT from a genuine attack on the DES algorithm. It would be like a shopowner installing a bigger lock on his shop door after burglars broke in through the window...he would be better off putting bars on the window instead. Also, they had the DES crypto-processor in silicon already and my hunch is that they simply built around the Nagra 1 card. Put very simply: If you can't get the DES keys in a roundabout way, DES is quite secure. And at this time, nobody can get the DES keys! One way to settle this matter would be to perform a statistical power analysis of both Nagra 1 and 2 chips while they are decrypting $03 and $07 commands. If there 16 rounds of decryption, then it is DES. IF there are 8 rounds, then IDEA. If there are 48 rounds, then 3-DES. These patterns will be clear during the test. A secondary test, although less conclusive would be a to simply time the execution of the $03 and $07 commands. IDEA takes only half the time to execute on average. If anyone has more information about the block cipher or about command $07, please feel free to post. We really can't go any further until we know the block cipher with certainty. But the $1C command is much more interesting and easier to break! Keep reading... Technical Discussion: Command $1C This command is used to encrypt the control words and send them to the IRD. It is the counterpart to the $13 command in Nagra 1. It is slightly different in format to the $13 command, which led us to our observations about the extra 3 packets in the $07 command. Here is a log of the $1C command: 21 00 08 ; A0 CA 00 00 ;Standard Header 02 ;Instruction Length 1C ;Command 00 36 ;Response Length cs ;Checksum And the response from the Nagra 2 card 12 00 38 ; 9C 34 ;Standard Response Header 00 08 ;Control Select? Filler? aa aa aa aa aa aa aa aa ;Control Word 1a bb bb bb bb bb bb bb bb ;COntrol Word 1b cc cc cc cc cc cc cc cc ;Control Word 1c 00 08 ;Control Select? Filler? AA AA AA AA AA AA AA AA ;Control Word 2A BB BB BB BB BB BB BB BB ;Control Word 2B CC CC CC CC CC CC CC CC ;Control Word 2C 90 00 ;SW1/SW2 cs ;Checksum The response is exactly as expected from the Nagra 1 card except Control Words 1b, 1c, 2B and 2C are new! Now, since the control words come down in the $07 command, we are justfied in assuming the extra 3 packets in the $07 command are simply these extra control words coming down. These extra "control words" must be important or they would not be added to the $07 payload! What are these extra control words and why are they there? The Mpeg-2 stream only needs 2 control words to be descrambled. Perhaps the extra "control words" are for future use on the Mpeg-4 stream. If there are any experts on the Mpeg-4 digital format, please enlighten us on the use of control words in Mpeg-4. As far as I know, there is an extra DEFAULT control word, in addition to the ODD/EVEN control words used in Mpeg-2. Although we are not entirely certain that these extra "control words" are really control words, we shall call them by that name. We are certain that 2 of the 6 are indeed control words, or otherwise, the current MPEG-2 stream could not be descrambled. Now, lets discuss the encryption used by $1C. First off, the encryption used by Nagra 1 and command $13 was DES and the 64 bit key used for encryption was the infamous IRD boxkey. Whatever the encryption for command $1C, the IRD boxkey is still being used as anyone can confirm by changing the IRD boxkey on a subbed Nagra 2 IRD. The result will be a black screen. Furthermore, one can easily clone receivers and still use a valid Nagra 2 card. IDEA has been proposed as the new encryption schema here too, but no proof has been given. Nobody has publicly disassembled the firmware and reverse engineered the algorithm. If IDEA is not being used on the $07 command, it definitely not be used on a much less sensitive command like $1C. Again, thos who claim IDEA is being used are welcome to offer proof. It is the opinion of this writer that DES or a variation of DES is being used. I am led to believe this because I have not succeeded in finding the S-box constants in any IRD TSOP dumps...leading me to believe that DES decryption is being done by a dedicated crypto-processor inside the IRD. A card swap does not mean any chips inside the IRD are changing...so unless an IDEA chip already existed in all IRDs (farfetched, but possible), they would have to implement IDEA in software and that would give the inner workigs of the algorithm away. If anyone knows where the S-Box constants are stored, please tell us and that would settle this matter. There has been some talk about a "secondary key" in some model IRDs. This supposedly prevents receiver cloning as both the boxkey and mysterious "secondary key" have to be known. Some have argued that this supports the hypothesis of IDEA being used with a 16 byte key. However, any secondary or tertiary keys may also be used in 3-DES or some variant. The model IRDs I have examined do not seem to have any "extra" keys. The decryption process of the $1C command should not be too hard to break, and I expect it to be broken first. It would be the first step towards a married-sub solution. More than likely, what is happening is the 6 "control words" are being decrypted using DES and then combined using basic logic functions to come up with the "valid" 2 control words that we were all used to with Nagra 1. For if they sent down only 2 control words in Nagra 2, we could compare them with the known 2 control words being used by Nagra 1 and quickly break the cipher. Hence, the most logical reason for 6 "control words" is confusion. Something to try: If anyone is running an emulation setup for Nagra 2, they could try changing control words 1b, 1c, 1B, 1C or, any combination thereof, before sending them to the IRD and see what difference it makes. Are you still getting video? So folks, that is a realistic view of Nagra 2...it is one of the simplest Conditional Access systems around, but, when you don't have the cipher keys, one of the most complex too |
|
info4U Unregistered guest | Command $1C - Important Observations In our previous post we mentioned that the response to the $1C command included 6 encrypted packets. We concluded that 2 of these packets had to be control words. For lack of a better name, we called these packets "control words" 1a, 1b, 1c, 1A, 1B, 1C. Some tests were done and we have confirmed that "control words" 1b,1c,1B and 1C do absolutely nothing. In fact, these packets were "zeroed out" and only 1a, 1A were returned to the IRD in the original format for processing. The IRD did not complain and video was generated as usual without interruption. If 1a or 1A were modified, then video disappeared. So this proves that the real Control Words are 1a and 1A. The other packets, at least for the moment, are not being utilized for any obvious purpose. We can only speculate as to their purpose. Someone mentioned that Nagra 2 doesn't have the equivalent of an $02 command...Perhaps the additional 4 packets in response to $1C will be used in MECM logic operations on the 2 real control words sometime in the future?? It has also been proven (by using an AVR in blocker mode) that command $04 is currently not relavent to generating video. So this is a fact and doesn't need to validated as someone suggested. So, it looks like the response to command $1C is now exactly the same as the old $13 command in Nagra 1. I am almost positive DES is being used on the 2 valid control words. If someone has disassembled the IRD firmware and found evidence of IDEA being implemented...it may have something to do with the other 4 packets. Please PM me your findings, as I would be very interested in any IRD disassembly, but unfortunately don't have the time to look into this myself! As for command $07, firmware disassembly will not reveal the encryption algorithm because the IRD never processes command $07. More attention needs to be directed to commands $1C and $07. Informative posts are welcome! |
|
Silver Member Username: PawnmasterCanada Post Number: 142 Registered: Jun-04 | Sorry forgot the user and pass for the account before posting these posts, you can PM me here with your findings.... |
|
ENFORCER Unregistered guest | Kneegrow is now banned from dsscommunity .. |
|
Silver Member Username: PawnmasterCanada Post Number: 143 Registered: Jun-04 | I see not much has changed around here since Ive been gone! You try to share some facts on a subject that is of intrest to all of us and look what happens.......back to Card Coders........ |
|
Silver Member Username: PawnmasterCanada Post Number: 144 Registered: Jun-04 | Good to know, speaking from expirience I assume? |
|
Knick Gar Unregistered guest | Hey Knee Grow, is there a different between a pull start or push start? |
|
Picasso Unregistered guest | Thank you very much to Info4U for these technical infos. At last, some facts on Nag2. It's my first visit here and I'm very surprised of the quality of the knowledge shared but unfortunately, a lot of kid behavior from some visitors. Come on, there's some people that are spending time to inform us. A little thank you wouldn't kill anyone. |
|
New member Username: Castaway682Post Number: 1 Registered: Apr-05 | how bout we meet somewhere and you will find out what we can do for you,"on your kness" or my knees grow when im on them.Or what ever your stupid nick is. |
|
Silver Member Username: PawnmasterCanada Post Number: 145 Registered: Jun-04 | -------------------------------------------------------------------------------- RSA AND IDEA ='s PGP The PGP Attack FAQ Abstract PGP is the most widely used hybrid cryptosystem around today. There have been AMPLE rumours regarding it's security (or lack there of). There have been rumours ranging from PRZ was coerced by the Gov't into placing backdoors into PGP, that the NSA has the ability to break RSA or IDEA in a reasonable amount of time, and so on. While I cannot confirm or deny these rumours with 100% certianty, I really doubt that either is true. This FAQ while not in the 'traditional FAQ format' answers some questions about the security of PGP, and should clear up some rumours... -------------------------------------------------------------------------------- The Feasibility of Breaking PGP The PGP attack FAQ 2/96 - v1.0 by infiNity [ ftp://ftp.infonexus.com/pub/Philes/...assphraseFAQ.gz 4 - The PRNG ANSI X9.17 (cryptRand) Latency Timer (trueRand) X9.17 Prewash with MD5 Randseed.bin wash PGP employs 2 PRNG's to generate and manipulate (pseudo) random data. The ANSI X9.17 generator and a function which measures the entropy from the latency in a user's keystrokes. The random pool (which is the randseed.bin file) is used to seed the ANSI X9.17 PRNG (which uses IDEA, not 3DES). Randseed.bin is initially generated from trueRand which is the keystroke timer. The X9.17 generator is pre-washed with an MD5 hash of the plaintext and postwashed with some random data which is used to generate the next randseed.bin file. The process is broken up and discussd below. ANSI X9.17 (cryptRand) The ANSI X9.17 is the method of key generation PGP uses. It is oficially specified using 3DES, but was easily converted to IDEA. X9.17 requires 24 bytes of random data from randseed.bin. (PGP keeps an extra 384 bytes of state information for other uses...) When cryptRand starts, the randseed.bin file is washed (see below) and the first 24-bytes are used to initialize X9.17. It works as follows: E() = an IDEA encryption, with a reusable key used for key generation T = timestamp (data from randseed.bin used in place of timestamp) V = Initialization Vector, from randseed.bin R = random session key to be generated R = E[E(T) XOR V] the next V is generated thusly: V = E[E(T) XOR R] Latency Timer (trueRand) The trueRand generator attempts to measure entropy from the latency of a user's keystrokes every time the user types on the keyboard. It is used to generate the initial randseed.bin which is in turn used to seed to X9.17 generator. The quality of the output of trueRand is dependent upon it's input. If the input has a low amount of entropy, the output will not be as random as possible. In order to maxmize the entropy, the keypresses should be spaced as randomly as possible. X9.17 Prewash with MD5 In most situations, the attacker does not know the content of the plaintext being encrypted by PGP. So, in most cases, washing the X9.17 generator with an MD5 hash of the plaintext, simply adds to security. This is based on the assumption that this added unknown information will add to the entropy of the generator. If, in the event that the attacker has some information about the plaintext (perhaps the attacker knows which file was encrypted, and wishes to prove this fact) the attacker may be able to execute a known-plaintext attack against X9.17. However, it is not likely that, with all the other precautions taken, that this would weaken the generator. Randseed.bin wash The randseed is washed before and after each use. In PGP's case a wash is an IDEA encryption in cipher-feedback mode. Since IDEA is considered secure (see section 1), it should be just as hard to determine the 128-bit IDEA key as it is to glean any information from the wash. The IDEA key used is the MD5 hash of the plaintext and an initialization vector of zero. The IDEA session key is then generated as is an IV. The postwash is considered more secure. More random bytes are generated to reinitialize randseed.bin. These are encrypted with the same key as the PGP encrypted message. The reason for this is that if the attacker knows the session key, she can decrypt the PGP message directly and would have no need to attack the randseed.bin. (A note, the attacker might be more interested in the state of the randseed.bin, if they were attacking all messages, or the message that the user is expected to send next). 5 - Practical Attacks Passive Attacks (Snooping) Keypress Snooping Van Eck Snooping Memory Space Snooping Disk Cache Snooping Packet Sniffing Active Attacks Trojan Horse Reworked Code Most of the attacks outlined above are either not possible or not feasable by the average adversary. So, what can the average cracker do to subvert the otherwise stalwart security of PGP? As it turns out, there are several "doable" attacks that can be launched by the typical cracker. They do not attack the cryptosystem protocols themselves, (which have shown to be secure) but rather system specific implementations of PGP. Passive Attacks (Snooping) These attacks do not do need to do anything proactive and can easily go undetected. Keypress Snooping Still a very effective method of attack, keypress snooping can subvert the security of the strongest cryptosystem. If an attacker can install a keylogger, and capture the passphrase of an unwary target, then no cryptanalysis whatsoever is necessary. The attacker has the passphrase to unlock the RSA private key. The system is completely compromised. The methods vary from system to system, but I would say DOS-based PGP would be the most vulnerable. DOS is the easiest OS to subvert, and has the most key-press snooping tools that I am aware of. All an attacker would have to do would be gain access to the machine for under 5 minutes on two seperate occasions and the attack would be complete. The first time to install the snooping software, the second time, to remove it, and recover the goods. (If the machine is on a network, this can all be done remotely and the ease of the attack increases greatly.) Even if the target boots clean, not loading any TSR's, a boot sector virus could still do the job, transparently. Just recently, the author has discovered a key logging utility for Windows, which expands this attack to work under Windows-based PGP shells (this logger is available from the infonexus via ftp, BTW). Keypress snooping under Unix is a bit more complicated, as root access is needed, unless the target is entering her passphrase from an X-Windows GUI. There are numerous key loggers available to passively observe keypresses from an X-Windows session. Van Eck Snooping The original invisible threat. Below is a clip from a posting by noted information warfare guru Winn Schwartau describing a Van Eck attack: Van Eck Radiation Helps Catch Spies "Winn Schwartau" <p00506@psilink.com> - Thu, 24 Feb 94 14:13:19 -0500 Van Eck in Action Over the last several years, I have discussed in great detail how the electromagnetic emissions from personal computers (and electronic gear in general) can be remotely detected without a hard connection and the information on the computers reconstructed. Electromagnetic eavesdropping is about insidious as you can get: the victim doesn't and can't know that anyone is 'listening' to his computer. To the eavesdropper, this provides an ideal means of surveillance: he can place his eavesdropping equipment a fair distance away to avoid detection and get a clear representation of what is being processed on the computer in question. (Please see previous issues of Security Insider Report for complete technical descriptions of the techniques.) The problem, though, is that too many so called security experts, (some prominent ones who really should know better) pooh-pooh the whole concept, maintaining they've never seen it work. Well, I'm sorry that none of them came to my demonstrations over the years, but Van Eck radiation IS real and does work. In fact, the recent headline grabbing spy case illuminates the point. Exploitation of Van Eck radiation appears to be responsible, at least in part, for the arrest of senior CIA intelligence officer Aldrich Hazen Ames on charges of being a Soviet/Russian mole. According to the Affidavit in support of Arrest Warrant, the FBI used "electronic surveillance of Ames' personal computer and software within his residence," in their search for evidence against him. On October 9, 1993, the FBI "placed an electronic monitor in his (Ames') computer," suggesting that a Van Eck receiver and transmitter was used to gather information on a real-time basis. Obviously, then, this is an ideal tool for criminal investigation - one that apparently works quite well. (From the Affidavit and from David Johnston, "Tailed Cars and Tapped Telephones: How US Drew Net on Spy Suspects," New York Times, February 24, 1994.) From what we can gather at this point, the FBI black-bagged Ames' house and installed a number of surveillance devices. We have a high confidence factor that one of them was a small Van Eck detector which captured either CRT signals or keyboard strokes or both. The device would work like this: A small receiver operating in the 22MHz range (pixel frequency) would detect the video signals minus the horizontal and vertical sync signals. Since the device would be inside the computer itself, the signal strength would be more than adequate to provide a quality source. The little device would then retransmit the collected data in real-time to a remote surveillance vehicle or site where the video/keyboard data was stored on a video or digital storage medium. At a forensic laboratory, technicians would recreate the original screens and data that Mr. Ames entered into his computer. The technicians would add a vertical sync signal of about 59.94 Hz, and a horizontal sync signal of about 27KHz. This would stabilize the roll of the picture. In addition, the captured data would be subject to "cleansing" - meaning that the spurious noise in the signal would be stripped using Fast Fourier Transform techniques in either hardware or software. It is likely, though, that the FBI's device contained within it an FFT chip designed by the NSA a couple of years ago to make the laboratory process even easier. I spoke to the FBI and US Attorney's Office about the technology used for this, and none of them would confirm or deny the technology used "on an active case." Of course it is possible that the FBI did not place a monitoring device within the computer itself, but merely focused an external antenna at Mr. Ames' residence to "listen" to his computer from afar, but this presents additional complexities for law enforcement. 1. The farther from the source the detection equipment sits means that the detected information is "noisier" and requires additional forensic analysis to derive usable information. 2. Depending upon the electromagnetic sewage content of the immediate area around Mr. Ames' neighborhood, the FBI surveillance team would be limited as to what distances this technique would still be viable. Distance squared attenuation holds true. 3. The closer the surveillance team sits to the target, the more likely it is that their activities will be discovered. In either case, the technology is real and was apparently used in this investigation. But now, a few questions arise. 1. Does a court surveillance order include the right to remotely eavesdrop upon the unintentional emanations from a suspect's electronic equipment? Did the warrants specify this technique or were they shrouded under a more general surveillance authorization? Interesting question for the defense. 2. Is the information garnered in this manner admissible in court? I have read papers that claim defending against this method is illegal in the United States, but I have been unable to substantiate that supposition. 3. If this case goes to court, it would seem that the investigators would have to admit HOW they intercepted signals, and a smart lawyer (contradictory allegory would attempt to pry out the relevant details. This is important because the techniques are generally classified within the intelligence community even though they are well understood and explained in open source materials. How will the veil of national security be dropped here? To the best of my knowledge, this is the first time that the Government had admitted the use of Van Eck (Tempest Busting etc.) in public. If anyone knows of any others, I would love to know about it. The relevance to PGP is obvious, and the threat is real. Snooping the passphrase from the keyboard, and even whole messages from the screen are viable attacks. This attack, however exotic it may seem, is not beyond the capability of anyone with some technical know-how and the desire to read PGP encrypted files. Memory Space Snooping In a multi-user system such as Unix, the physical memory of the machine can be examined by anyone with the proper privaleges (usally root). In comparsion with factoring a huge composite number, opening up the virtual memory of the system (/dev/kmem) and seeking to a user's page and directly reading it, is trivial. Disk Cache Snooping In multitasking environments such as Windows, the OS has a nasty habit of paging the contents of memory to disk, usally transparently to the user, whenever it feels the need to free up some RAM. This information can sit, in the clear, in the swapfile for varying lengths of time, just waiting for some one to come along and recover it. Again, in a networked environment where machine access can be done with relative impunity, this file can be stolen without the owner's consent or knowledge. Packet Sniffing If you use PGP on a host which you access remotely, you can be vulnerable to this attack. Unless you use some sort of session encrypting utility, such as SSH, DESlogin, or some sort of network protocol stack encryption (end to end or link by link) you are sending your passphrase, and messages across in the clear. A packet sniffer sitting at a intermediate point between your terminal can capture all this information quietly and efficiently. Packet sniffers are available at the infonexus Active Attacks These attacks are more proactive in nature and tend to be a bit more difficult to wage. Trojan Horse The age old trojan horse attack is still a very effective means of compromise. The concept of a trojan horse should not be foriegn to anyone. An apparently harmless program that in reality is evil and does potentially malicious things to your computer. How does this sound...: Some 31it3 coder has come up with a k3wl new Windows front-end to PGP. All the newbies run out and ftp a copy. It works great, with a host of buttons and scrollbars, and it even comes with a bunch of *.wav files and support for a SB AWE 32 so you can have the 16-bit CD quality sound of a safe locking when you encrypt your files. It runs in a tiny amount of memory, coded such that nothing leaks, it intercepts OS calls that would otherwise have it's contents paged to disk and makes sure all the info stays in volatile memory. It works great (the first Windows app thar does). Trouble is, this program actually has a few lines of malevolent code that record your secret-key passphrase, and if it finds a modem (who doesn't have a modem these days?) it 'atm0's the modem and dials up a hard coded number to some compromised computer or modem bank and sends the info through. Possible? Yes. Likely? No. Reworked Code The code to PGP is publically available. Therefore it is easy to modify. If someone were to modify the sourcecode to PGP inserting a sneaky backdoor and leave it at some distribution point, it could be disasterous. However, it is also very easy to detect. Simply verify the checksums. Patching the MD5 module to report a false checksum is also possible, so verify using a known good copy. A more devious attack would be to modify the code, compile it and surreptitouly plant in the target system. In a networked environment this can be done without ever having physical access to the machine. 6 - What if... ...My secret key was comprimsed? ...PGP ran outta primes? ...What if someone made a list of all these prime numbers? ...And used them in a brute force search? ...PGP chose composites instead of primes? ...My secret key was comprimsed? A PGP secret key is kept conventionally encrypted with IDEA. Assuming your passphrase is secure enough (see section 3) the best method of attack will be a brute force key-search. If an attacker could test 1,000,000,000,000 keys per second, it would take 1x10^17 years before odds will be in the attacker's favor... ...PGP ran outta primes? There are an infinite amount of prime numbers. The approximate density of primes lesser than or equal to n is n/ln(n). For a 1024-bit key, this yields: 1.8*10^308/ln(1.8*10^30 = 2.5*10^305 There are about 2.5*10^228 times more prime numbers less than 1024-bits than there are atoms in the universe... ...What if someone made a list of all these prime numbers? If you could store 1,000,000 terabytes of information of a device that weighs 1 gram, (and we figure each number fits in a space of 128 bytes or less) we would need a device that weighs 3.2*10^289 grams or 7*10^286 pounds. This is 1.6*10^256 times more massive than our sun. Nevermind the fact that we don't have enough matter to even concieve of building such a device, and if we could, it would collapse into a black-hole... ...And used them in a brute force search? There are 2.5E305(2.5E305-1)/2 possible pairs. This is 3.12*10^610 combinations. Absurd, isn't it? ...PGP chose composites instead of primes? The likelyhood of the Fermat Tests of passing a composite off as a prime is 1 in 10^52. If PGP could generate 1,000,000,000,000 primes per second, It would take about 1x10^32 years until odds are better than even for that to happen. |
|
Silver Member Username: PawnmasterCanada Post Number: 146 Registered: Jun-04 | Things i noticed while browsing through logging files... 12 00 38 9c 34 00 08 1a 2a 3a 4a 5a 6a 7a 8a 1b 2b 3b 4b 5b 6b 7b 8b 1c 2c 3c 4c 5c 6c 7c 8c 00 08 1d 2d 3d 4d 5d 6d 7d 8d 1e 2e 3e 4e 5e 6e 7e 8e 1f 2f 3f 4f 5f 6f 7f 8f 90 00 CS Then the next 1C goes something like this.... 12 00 38 9c 34 00 08 1a 2a 3a 4a 5a 6a 7a 8a <-same as previous 1C but different on next 1C. xx xx xx xx xx xx xx xx <-different each time. xx xx xx xx xx xx xx xx <-different each time. 00 08 1y 2y 3y 4y 5y 6y 7y 8y <-used on next 1C in same place xx xx xx xx xx xx xx xx <-different each time. xx xx xx xx xx xx xx xx <-different each time. 90 00 CS Then the next 1C goes something like this.... 12 00 38 9c 34 00 08 1x 2x 3x 4x 5x 6x 7x 8x <-different as previous 1C but same on next 1C. xx xx xx xx xx xx xx xx <-different each time. xx xx xx xx xx xx xx xx <-different each time. 00 08 1y 2y 3y 4y 5y 6y 7y 8y <-same as previous 1C but different on next 1C. xx xx xx xx xx xx xx xx <-different each time. xx xx xx xx xx xx xx xx <-different each time. 90 00 CS Then the next 1C goes something like this.... 12 00 38 9c 34 00 08 1x 2x 3x 4x 5x 6x 7x 8x <-same as previous 1C but different on next 1C. xx xx xx xx xx xx xx xx <-different each time. xx xx xx xx xx xx xx xx <-different each time. 00 08 1z 2z 3z 4z 5z 6z 7z 8z <-different as previous 1C but same on next 1C. xx xx xx xx xx xx xx xx <-different each time. xx xx xx xx xx xx xx xx <-different each time. 90 00 CS |
|
Silver Member Username: PawnmasterCanada Post Number: 147 Registered: Jun-04 | Here this will better explain why the Black Epoxy ... (( And from what I understand they are useing this method in trinadad and tobago area to get into NDS cards, with a laser and a microscope, you simpley find what you want to shoot at, and shoot it right thru the scope's eye peice .... )) And I guess you can induce fault's just by useing a simple high power Xenon flash tube, with out a glass/plastic shielding ... Ah a use for that pile of throw away cameras with flashs, other then a cheap source of batteies for the remotes .... There's nothing like thinking outside the box .. From EE times By Anthony Clark May 20, 2002 (2:19 AM EDT) Researchers at Cambridge University's Computer Laboratory have developed a powerful class of attack on computer security systems that could fundamentally undermine existing smartcard technology. The attack was invented by Sergei Skorobogatov, a PhD student with the laboratory's security group, led by Dr Ross Anderson. Skorobogatov discovered that illuminating a single transistor in an IC using a laser or other tightly focussed source of energy can induce a transient fault in the circuit. The effect can be applied to smartcards, microcontrollers and other types of chip. Dr Anderson said: "Sergei's work will trigger a generation change in smartcard technology. The immediate effect of his work is that many attacks on computer systems that were developed as theoretical possibilities by the research communities in the 1990s have suddenly become practical." The Cambridge team initially induced faults using a photographer's flash gun, mounted on a microscope. By careful choice of the target transistor and the exact time of the transient, it has proved possible to circumvent a chip's protection. The use of fault attacks to crack security processors had been described by a number of researchers in the past, but the methods available for inducing faults were crude. For example, they included inserting a transient overvoltage into the power supply to the chip. Many security processors contain circuits to stop attacks. But the Cambridge approach works with such precision that existing countermeasures will have to be tightened, claims Dr Anderson. Work on perfecting the attack was completed by the Computer Laboratory a year ago, but has been kept under wraps until de-fensive technologies were developed.Dr Anderson and Dr Simon Moore, also a member of the Laboratory's security group, have developed and tested a silicon technology that can block the Skorobogatov and many other previously known attacks. Simply shielding the processor by adding a top metal layer is not sufficient; silicon becomes transparent to light in the IR spectrum so attacks can still be conducted through the rear of a chip. It is also possible that attacks of this new type could be conducted using other sources of energy, such as electromagnetic pulses and X-rays. Oh and this is on the Camera Flash idea .... and how it all works ... Some times it's all in how one looks at the problem ..... Camera flash opens up smart cards 17:47 13 May 02 NewScientist.com news service Sensitive information stored on a smart card microprocessor can be revealed with a flash of light, say UK researchers. Sergei Skorobogatov and Ross Anderson of CambridgeUniversity have discovered that firing light from an ordinary camera flash at parts of a smart card microchip can assist an attacker in determining the sensitive information stored on the card. This might include, for example, the cryptographic key used to gain access to a building or to secure internet transactions. In contrast to previous methods of cracking the cards, the researchers say this type of attack can be performed cheaply using off-the-shelf equipment. The attack is described as "semi-invasive" as the researchers only removed part of a chip's protective covering. The light from an ordinary camera flash was then focused using a microscope on particular parts of a smart card's microprocessor. Flipping bits This ionises the silicon and "flips" the individual bits stored on different parts of the card allowing data stored on the card to be probed and altered. An ordinary smart card reader is used to monitor the process. Skorobogatov says the technique could in theory be used to reset a smart card's password to a known value, so that it gives up the rest of its secure information. The research will be presented at the 2002 Institute of Electrical and Electronics Engineers (IEEE) Symposium on Security and Privacy in a paper entitled Optical fault induction attacks. Another group at CambridgeUniversity has developed a microchip design that could protect against the attack and this work will be presented at the same conference. The team, led by Simon Moore, has designed a more complex "asynchronous" microprocessor that would not respond in the same way to light interference. Moore says: "No single point of failure will result in information being leaked." Will Knight |
|
Silver Member Username: PawnmasterCanada Post Number: 148 Registered: Jun-04 | Most of this information is not for the layman, but if you do read it you may gain a better understanding of what it is we are trying to accomplish and how many of the testing worlds greatest minds are working on the problem. DirecTV is gone forever, there is not nor will there ever be a way into the P4 P5 and others, Di**Net and Be*l use the same access Cams and therefore the effort is a much more concentrated one as the Nagra Cam is widely used around the world. We can already log the stream, we have succesfully dissassembled the chip, processor and Cam commands, Emulation is working for the Nagra2 cam, although very minimal. Time will provide a solution and soon everyone will be watching free TV on the nagra2 stream. Just remember whom these people are and the ammount of effort they are directing at it all so as the rest of us (collectivly) can enjoy our TV. When you go to these sites, such as |
|
Silver Member Username: PawnmasterCanada Post Number: 149 Registered: Jun-04 | Good morning Knee Grow, I thought youd be here sooner with another of your most informative and intelligent observations! |
|
Silver Member Username: Knee_grows_backPost Number: 234 Registered: Jan-05 | oh by the way Monti...let me introduce you to our own illegal alien who posts here at ecoustics...his name is Punjavi Da...and when his turbon is too tight, he sometimes get's mad and yells at me and other posters...please excuse his grammer and ignorance...he just got off the boat..ROTF |
|
Silver Member Username: PawnmasterCanada Post Number: 150 Registered: Jun-04 | Punjavi Da, I'm sorry if the info is over your head, its only meant to inform, and to most it is all greek and makes no sense. Some of us however have some understanding of the processes and structures and all we want to do is share it with those of you whom are not as knowledgeable about the whole process. If however you have somthing productive to add we would love to hear it! |
|
Knick Gar Unregistered guest | This is all bullcraap!!!All I want to know is IS THERE A CRACK!!! Stop trying to show your intelligence of cut-and-paste others info and pretend it's all you...sad frickin' waste of time! |
|
Silver Member Username: PawnmasterCanada Post Number: 152 Registered: Jun-04 | Wow its amazing how easy it is to offend unintellagable pepople, If you could read you would now know that as of yet there is NOT a crack, but things are progressing rapidly. Much more has been accomplished towards cracking Nagra2 than was or will ever be done with the P4, P5 and all the others. Sorry for your loss. |
|
Knick Gar Unregistered guest | the offending part is YOU! cutting and pasting shiit from other's articles and for what???? Check yourself, Dude....we all know there is no crack on N2 yet and that 10 miles long of "technical info" can easily be summed up - "no crack" and I haven't a clue to what the fcuk im doing... |
|
Punjavi Da Unregistered guest | hello. ok magicuser I going to give you advise becouse you ready need advise europins have nagra2 long time and they havenot hacked why, becouse they dumbazzes americans are dumbazzes and lazyazzes but motherfukcer orientals are hacker geniuses and then sell it cheap so you sit and wait and shut the fukc up. ok thank you |
|
Anonymous | Frankly I am a bit surprised . There is a bunch of smart alecks trying to break the codes in Nagra 2 for the collective benefit of those who want to see "free TV". Then there are these useless kindergarted dropouts who think it's cool to swear and use abusive language. Surely there should be some way of stopping these retards........... they just seem to be in a great hurry to have the results - they don;t want to (or may be they can't) understand the efforts these guys are taking, Good luck to the smart aleck kids, Hope you find an solution to the "Nagra 2" codes. |
|
Bosox Unregistered guest | its a hard pill to swallow..... but unfortunately sometimes the bad guys win...... you just cant compete with the owner of the bats and balls....... best thing to do is an "honorable retreat"...... it was fun while it lasted.... I needed some vacations anyway. bye-bye and good luck Bosox |
|
Anonymous | can someone help with new keys please |
|
Beh Unregistered guest | I don't know much about encryption technology guys, but I do really find this whole thing very interesting. I don't claim to have any technical knowledge either and pardon my ignorant post, but at least I'm not swearing at people here. As I understand Nagra 1 uses a decryption key that is common for all receivers. Well if I was going to make that a little more sophisticated, I would make the decryption key related to infromation saved on each receiver (i.e. serial number) so that decryption information could not be shared amongst users (as with many computer software these days). Am I really talking non-sense here or does Nagra 2 already do this? |
|
Silver Member Username: Knee_grows_backPost Number: 534 Registered: Jan-05 | You're talking utter nonsense you idiot stick... |
|
Silver Member Username: PawnmasterCanada Post Number: 159 Registered: Jun-04 | Too bad you are still around.....one day....... |
|
Anonymous | ----GROW-KNEE-GROW-KNEE ----YOU ARE THE ONE WHO IS ALWAYS TALKING ----NONSENSE,SOMEDAY SOME ONE SOME WHERE IS ----GOING TO AUTOROLL YOU OUT FROM THIS PLACE ----YOU CAN'T BEHAVE-YOU CAN'T BE NICE ----SO ALL I HAVE TO SAY TO YOU (fffffffffOFF) |
|
Anonymous | IGNORE KNEEGROW......ITS THE ONLY WAY |
|
Anonymous | I had cloned my PVR 501 to sub 301.13 with yellow card. here is what happening.... last few weeks my PVR gets 005 message once a day or so... & then goes to black screen. unless I change channel... looks like dish changing keys daily on nagra2 stream. |
|
Anonymous | I had cloned my PVR 501 to sub 301.13 with yellow card. here is what happening.... last few weeks my PVR gets 005 message once a day or so... & then goes to black screen. unless I change channel... looks like dish changing keys daily on nagra2 stream. |
|
mforce Unregistered guest | Now I have to admit I don't know too much about nagra 2 and stuff ... For now ... I do have a question though . Couldn't we use some kind of distributed computing to break some of the weaker encrition there or use osme known information and distributed computing to break the more powefull encriptions ? Just an idea . Imagine what 10 000 Athlons or P IV-s could do . Quite a lot I think . Is there such a project already because I know programming and would like to write the software to do it . |
|
knick gar Unregistered guest | What??????? my head hurts......what the f......? |
|
Silver Member Username: HamtecPost Number: 103 Registered: Jun-04 | Most people do not know how to lodd the stream. Relacks the hack is here not layed out for the dummbies yet. |
|
knick gar Unregistered guest | Let me unload my stream on your face azzwipe! you think you are so smart and yet you can't even spell correctly! |
|
SiIent Bob Unregistered guest | I hate smartazzes the likes of Colin what a SCHMUCK |