Saturday, February 24, 2007

Can Contactless Credit Cards Be Hacked? 5 Tips to Stay Secure

Although RFID (Radio Frequency Identification) is still a tough sell to a many people, millions of contactless credit cards have been issued over the past year. Issuing banks are increasingly making RFID cards the default replacement card, and banks aren't required to tell cardholders that the new cards are RFID-enabled. Some contactless cards have visible microchips, but others don't, so it may be difficult to know if you own an RFID card.

The lack of knowledge about what type of credit card you have in your possession is just one part of the security problem. Other issues, like a misunderstanding about how these cards operate, create yet more reasons why you need to become proactive about your credit card security. One way to become more secure is to learn about what makes this technology "hackable".

Can Contactless Cards Be Hacked?

The only difference between a contactless credit card and a regular credit card is the way that your card's information is transmitted at the point of transaction. Instead of using the traditional magnetic stripe (magstripe), the contactless credit card uses a "tag". The tag consists of a semiconductor ship or set of chips and an antenna that relays radio frequency signals into and out of the chip. This passive RFID technology creates a fear factor for most people who don't understand how it works. In some cases, however, this fear is reasonable.

The problems behind this technology as utilized in credit cards lie in three distinct areas:

  1. The information contained on that chip.
  2. Whether that chip is secure or insecure.
  3. The radio frequencies and data transfer standard used to activate that chip.

The information contained on your contactless credit card may contain the same information that can be found within the magstripe in your traditional credit card. This information varies from issuer to issuer, but in essence your contactless card's chip will include your name, address, card number, and card security code. It may also include or be tapped into information about your birth date, social security number, and any other bits and bytes that you would deem highly sensitive and personal. Even at their tiny size, the chips contained in contactless credit cards can contain megabytes of memory.

As with any technology, issues often are addressed in "second-generation" products. Contactless cards are no exception. In first-generation issue, some cards were "open" to name and credit card number theft, but the security code couldn't be stolen. However, retailers often allow purchases without that security code, so the fact that a thief wouldn't have that code becomes moot.

Second-generation cards, like the Visa Contactless card, no longer send the cardholder's name, but it can still send the card number to malicious scanners. The argument as to why this security measure is better is that the card number would be difficult to use without the cardholder's name.

The chips used for contactless credit cards are, by most accounts, secure. A chip's memory can be altered as in a read/write program, and these "dynamic" chips are supposedly encrypted in credit cards. This means that the chip will contain some fixed information that can be programmed on the chip only once, like your personal information. Then, the chip may also contain a sophisticated processor that executes cryptographic elements that protect static data.

The chip contains an antenna that allows that chip to communicate with a reader through a radio frequency (RF). This is where the mystery lies for many folks, as this information often sounds as cryptic as the security issue. But, an understanding about this technology is critical in your quest to protect your identity and your privacy.

RFID credit cards rely on a reader to supply energy to its chip through the reader's RF field. The chip picks up the reader's energy, powers up, receives commands and/or data, processes it, and communicates back with the reader. This communication prevents identity theft from readers from a distance, but a malicious scanning device could still be able to read any card that can be read by a legitimate reader. The common RF used to activate the tags and readers for credit cards is at a higher frequency than the ones used in tagging animals or in many supply-chain management systems. The frequency chosen by most credit card companies is the 13.56MHz frequency with data transfer rates of ISO 14443.

The reader's 13.56MHz frequency seems very low, especially when compared with items such as current mobile phone systems that operate at ultra high frequencies between 800 and 1800 MHz. But, in reality, the 13.56 MHz frequency is mid-range with an operating distance that would depend upon the tag size and the reader type. Proximity can be close to one meter, or 3.28 feet.

The ISO 14443 standard for transfer rates was chosen to modify the 13.56MHz frequency. The ISO 14443, put simply, is a four-part international standard [PDF link] that was created for contactless smart cards that operate at the 13.56MHz frequency in close range with a reader antenna. It has a generally accepted read/write range of up to 10 cm, or four inches. ISO 14443 accepts authentication mechanisms such as encryption.

The transfer rate is also affected by certain materials placed between a reader and the chip. If metal is placed between a reader and a tag, the RF will be deflected. This is why thin sheets of metal are placed in biometric passports, to protect your information when the passport is closed. This response to metal is also the reason behind a new market for metal sleeves that claim to protect your biometric passport and your contactless credit cards from theft.

But while metal currently can create noise between the card and the reader and while it can also detune both reader and tag antennas, it's also possible to bypass this problem with the right frequency and data transfer standard. The ability to bypass metals to maintain "conversation" between the tag and a reader continues to evolve. So, eventually, this will be one problem that won't be resolved simply by wrapping your credit card in aluminum foil.

With that said, it's time to offer some tips on how to protect your contactless credit card and its information. When Texas Instruments, an industry leader in RFID technology and the world's largest integrated manufacturer of RFID tags, warns [PDF link] that the consequence of a successful compromise in the use of the tags is "large to enormous," it's time to take matters into your own hands. Below are five tips that should help you on your way to being more secure with your contactless credit cards.

Five Tips for RFID Card Security

  1. Take a pro-active role with your financial tools. Unlike the card's passive technology, you need to take a proactive stance to protect your information. Call your credit card company and ask them if your current card is a "contactless" card or a traditional card. If they've issued you a contactless card, you have one of two choices: 1) Ask for a traditional card, because you refuse to use the RFID technology, or; 2) Ask the company about the finer points to their system. If you go the second route, then…
  2. Ask the credit card company about their RF and ISO. If the numbers match those shown above, great. If not, ask why and demand detailed information. The bank may be using more advanced technology that may surpass the information above (yes, the technology is moving that quickly). Beyond this, if the bank states that the information on your card is "static," then destroy that card. The information on that chip must be "dynamic" to enable encryption on data transmissions. If your chip is dynamic, then…
  3. Ask the credit card company about its encryption methods. The encryption on contactless credit cards can contain from 32 to 128 bits for security. The fact that this encryption is enabled on a dynamic card allows the reader to alter certain information from transaction to transaction, and this is a good thing. But, even these encrypted cards can be compromised. So what do you do about that problem?...
  4. Ask about the credit card company's fraud detection and any other prevention measures. Unfortunately, credit card information ― even that contained in traditional credit cards ― is open to theft. As recently as last year over forty million credit cards were exposed to potential fraud due to a security breach that occurred at a third-party processor for payment card transactions. And, that's just one story about credit card hacks. Perhaps the question here isn't about credit card security so much as it is about how you can protect yourself against your credit card company. So be diligent about your records and transactions. Make sure that what you do corresponds with your credit card statements.
  5. Be careful where you shop. As any technology grows, its capabilities to cover security issues probably will remain just one step behind the hackers. Retailers failed to keep up with security issues in a safety measure led by Visa in 2005. So, at times the credit card company isn't to blame. You also need to be careful about where you shop online or at your local brick-and-mortar. The one question you might ask that retailer: "Do you use the card's ID code (or other measure) to finalize transactions?" If the answer is a resounding, "yes," then your transactions may be safer at these stores than ones that go without that extra security measure. The Smart Card has forced some retailers to understand the obligations they have to consumers, so this new technology may make your transactions safer.

Technology by itself is neutral. It's the people who handle that technology that need to be questioned. So, begin by questioning whether you own a contactless credit card and go from there. If you want to know the worst fears that people harbor about this technology, you can visit CASPIAN (Consumers Against Supermarket Privacy Invasion and Numbering) so you know which questions to ask about your cards.

On the other hand, you may realize that this technology isn't going to disappear and that it may become a more secure method for transactions than traditional credit cards. You can frequent the non-profit multi-industry association, Smart Card Alliance, to learn how this industry plans to secure your information and your privacy now and in the future for your peace of mind.

Digg!

A wikiHow article on How to Avoid Colloquial (Informal) Writing

----------------

Your friend just sent you the following article from wikiHow.com:

How to Avoid Colloquial (Informal) Writing
While it may be acceptable in friendly e-mails and chat rooms, a major pitfall that has been bringing down the quality of formal, written text is the use of excessive colloquialism. Here are some steps/tips that you can follow to help to improve your overall writing.

You can view the rest of this page at:
http://www.wikihow.com/Avoid-Colloquial-%28Informal%29-Writing

wikiHow is a collaborative writing project aiming to build the world's
largest how-to manual. Our mission is to provide free and useful instructions
to help people solve the problems of everyday life. wikiHow is a wiki, which
is a website that anyone can write or edit. You can help us, by editing any
page on wikiHow which needs improvement.

http://www.wikiHow.com - The How-to manual that anyone can write or edit

Digg!

Friday, February 23, 2007

西门子难道也产杯子?

今天到表弟家去过年吃饭,偶然在楼梯过道中发现印有Siemens商标的茶杯包装盒,心里充满疑问西门子难道连杯子都生产?不知有朋友知晓不?

Digg!

Saturday, February 17, 2007

C\C++ Boundary and Error Check (2)

Sample:
//ilist 中普通版本的insert()操作
//以一个待插入的值以及一个ilist_item 指针作为参数,新的项被插
//在这个指针所指的项的后边
inline void
ilist::
insert( ilist_item *ptr, int value )
{
new ilist_item( value, ptr );
++_size;
}

  • 一种方案是通过调用C标准库abort()函数来终止程序该函数在C头文件cstdlib 中.
#include<cstdlib>
// ...
if ( ! ptr )
abort();

  • 另一种方案是使用assert()宏来终止程序,但首先要声明引起断言的条件.
#include<cassert>
// ...
assert( ptr != 0 );

  • 第三种方案是抛出一个异常例如
if ( ! ptr )
throw "Panic: ilist::insert(): ptr == 0";

一般地我们应该尽可能地避免终止程序.终止程序实际上是对用户落井下石,而我们或者支持部门可以分离并解决这些问题.

如果我们在错误点上不能继续处理,那么一般来说抛出异常比终止程序更好一些.异常会把控制权传送到程序先前被执行的部分,而它们有可能能够解决这个问题.

assert()是C语台标准库中提供的一个通用预处理器宏.在代码中常利用assert()来判断一个必需的前提条件,以便程序能够正确执行.

为了使用assert() 必须包含与之相关联的头文件
#include <assert.h>
assert.h 是C 库头文件的C 名字,C++程序可以通过C库的C名字或C++名字来使用它,这个头文件的C++名字是cassert
#include <cassert>
using namespace std;
assert宏将会判断表达式,如果一个表达式为真,执行将继续,否则,程序将显示一条消息并且暂停,你可以选择忽视这条错误并继续、终止这个程序或者是跳到Debug器中。

  • 如何使用一个ASSERT宏去验证一个语句。
void foo(char *p, int size)
{
ASSERT(p != 0); //确认缓冲区的指针是有效的
ASSERT((size 〉= 100); //确认缓冲区至少有100个字节
// Do the foo calculation
}
这些语句不产生任何代码,除非—DEBUG处理器标志被设置。Visual C++只在Debug版本设置这些标志,而在Release版本不定义这些标志。

两个assertions将产生如下代码:
//ASSERT(p != 0);
do{if(!(p != 0) && AfxAssertFailedLine(—FILE—,—LINE—))AfxDebugBreak();
} while(0);
//ASSERT((size 〉= 100);
do{if(!(size 〉= 100) && AfxAssertFailedLine(—FILE—,—LINE—))AfxDebugBreak();
} while(0);
If语句将求取表达式的值并且当结果为零时调用AfxAssertFailedLine()函数。这个函数将弹出一个对话框,其中提供三个选项“取消、重试或忽略”,当你选取“重试”时,它将返回TRUE。重试将导致对AfxDebugBreak()函数的调用,从而激活调试器。

我们的实现能够识别空指针,并将其视为把value 插入链表头的请求

inline void
ilist::
insert( ilist_item *ptr, int value )
{
if ( !ptr )
insert_front( value ); //将value插入链表头
else {
bump_up_size(); //++_size;
new ilist_item( value, ptr );
}
}

直接返回给掉用者处理

inline bool
ilist::
insert( ilist_item *ptr, int value )
{
if ( !ptr )
return false;
else {
bump_up_size(); //++_size;
new ilist_item( value, ptr );
}
return true;
}

//声明一个ErrorCode的枚举
enum e_Error{
e_ErrorOK,
e_ErrorNullPointer,
……
}

inline e_Error
ilist::
insert( ilist_item *ptr, int value )
{
if ( !ptr )
return e_ErrorNullPointer;
else {
bump_up_size(); //++_size;
new ilist_item( value, ptr );
}
return e_ErrorOK;
}



Digg!

C\C++ Boundary and Error Check (1)

Sample:</br>

void CopyData(char *szData) {
char cDest[32];
strcpy(cDest,szData);
// 使用 cDest
...
}

char *szNames[] = {"Michael","Cheryl","Blake"};
CopyData(szName[1]);

  • 缓冲区溢出是指当计算机程序向缓冲区内填充的数据位数超过了缓冲区本身的容量,溢出的数据覆盖在合法数据上。
  • 操作系统所使用的缓冲区又被称为堆栈,在各个操作进程之间,指令被临时存储在堆栈当中,堆栈也会出现缓冲区溢出。
  • 缓冲区溢出是由编程错误引起的。如果缓冲区被写满,而程序没有去检查缓冲区边界,也没有停止接收数据,这时缓冲区溢出就会发生。
  • 缓冲区溢出主要出现在 C 和 C++ 中,因为这些语言不执行数组边界检查和类型安全检查。

当编写 C 和 C++ 代码时,应注意如何管理来自用户的数据。如果某个函数具有来自不可靠源的缓冲区,请遵循以下规则:
  • 要求代码传递缓冲区的长度并进行检查。
  • 探测内存。
  • 采取防范措施。

以下代码的问题在于函数不能判断 szName 的长度,这意味着将不能安全地复制数据。函数应知道 szName 的大小:

void Function(char *szName, DWORD cbName) { char szBuff[MAX_NAME];
// 复制并使用 szName
if (cbName < MAX_NAME) strncpy(szBuff,szName,MAX_NAME-1);
}
然而,您不能想当然地信任 cbName。攻击者可以设置该名称和缓冲区大小,因此必须进行检查!

void Function(char *szName, DWORD cbName) {
char szBuff[MAX_NAME];

#ifdef _DEBUG
// 探测
memset(szBuff, 0x42, cbName);
#endif

// 复制并使用 szName
if (cbName < MAX_NAME) strncpy(szBuff,szName,MAX_NAME-1);
}

注意:只能在调试版中这样做,以便在测试过程中捕获缓冲区溢出。

void Function(char *szName) {
char szBuff[MAX_NAME];

if(strlen(szName) >= MAX_NAME || strlen(szName)<0) { /* Do something appropriate, such as throw an error. */
}
else {
strncpy(szBuff,szName,MAX_NAME-1);
}

}


完成同样目的的更容易方式是使用 strncpy() 库例程:
strncpy(dst, src, dst_size-1);
dst[dst_size-1] = '0'; /* Always do this to be safe! */
如果 src 比 dst 大,则该函数不会抛出一个错误;当达到最
大尺寸时,它只是停止复制字符。注意上面调用 strncpy() 中的
-1。如果 src 比 dst 长,则那给我们留有空间,将一个空字符
放在 dst 数组的末尾。

Digg!