[SDBUG] Re: mkisofs vs cdparanoia? [from Aug-12-2003]

[Peter Leftwich]

On Tue, 12 Aug 2003, Jonathan Byrne wrote:
> On Tue, Aug 12, 2003 at 10:34:41PM -0400, Peter Leftwich wrote:
> >Can "dd" be used to take an exact image (replica) of an audio CD?  What
> >program would then be used (burncd?) to write that image to a CD-R?
>
> No, that's beyond the scope of dd, but the cdrecord man page has some
> info on using cdda2wav to copy audio CDs.  Search the man page
> for cdda2wav and you will get the arcana first (good background
> reading) and eventually wind up in the examples section, which
> gives you the quick and dirty info you need to get the job done.
> It can be done either with intermediate files or from a pipe.
> Your risk of coastering will be much lower when using intermediate
> files.
>
> All GUI burning programs that I've seen are simply frontends for
> the CLI tools like cdrecord, mkisofs, cdda2wav, cdrdao, etc.  AFAIK
> no one has coded a standalone graphical burning app. for *nix.
> There could be some such beast out there on proprietary systems
> such as Irix, but I've never seen free software that wasn't
> just a frontend.
>
> >Cool, what's gpg?
>
> < WARNING> anyone who doesn't want to read a long digression on
> PKI and why we should use it should just move on to the next
> mail now :-)
> </WARNING>
>
> Wow!  A security newbie! :-)
>
> You've made my day, though.  I'm sure there are a lot
> of people who see my .signature and have no idea what it means, but
> never ask.  That's a shame, because I believe everyone should know and
> care about it.
>
> GPG is Gnu Privacy Guard, a Free encryption program.  Like
> PGP, it uses PKI (Public Key Infrastructure) cryptography.
> My .signature tells anyone who is using any flavor of *nix and
> who has GPG installed how to get my public key anytime they are
> online.  With my public key, you can:

I never understood though - someone cannot send you an encrypted file
unless THEY have a public and private key.  Extra work!

> - Send me encrypted files or mail
> - Verify that mail that claims to be signed with my private
>   key was really signed with it.  If someone you trust has signed
>   my key, that increases your confidence that the key pair that
>   claims to belong to me does in fact belong to me and not to someone
>   pretending to be me.  This is what's known as the "web of trust,"
>   a key component of PKI.
>
> GPG has an excellent manual in HTML format that assumes no prior
> knowledge of either GPG in particular or PKI in general, and
> it should be available as a package on pretty much any Linux or
> *BSD system (along with GPG itself) and is also available online
> at the Gnu Privacy Guard website, http://www.gnupg.org/ if you
> just want to take a browse first.
>
> Why, you may ask, should everyone know about GPG?  There are many
> reasons.  The first is that digitally signed mail is (or should be)
> a valuable tool for businesses and any high-profile businesses.
> It makes it quite difficult to forge a mail purporting to be from
> someone if that person is known to always gpg-sign her/his mail.
> If you know that I always sign my mail and then one day you get
> some strange mail that claims to be from me but is either not signed
> or is signed but not with my key, you can automatically mistrust it
> before you've even looked at the headers.  If I never sign my mail,
> you would have no reason to even suspect a mail that says
> Jonathan Byrne <jonathan at yamame dot org> in the From: line.
>
> OK, so while forged email does happen, it doesn't happen every day
> and probably isn't a big concern to most people.
>
> There's a more practical reason, though.  A lot of people have
> confidential information of various kinds that needs to be sent
> across the Internet.  Financial information, passwords, and credit
> card or account numbers are all commonly sent.  Another important
> class of data that is sent across the Internet on a daily basis
> is company documents, including business plans and spreadsheets.
> Now, it is a well-known that anything that is emailed can be
> intercepted along the way on any host through which it passes.
> If it's going through a wireless medium at any point, it doesn't
> even need to be intercepted by a host, it can be picked out of the
> air.  Despite this, companies routinely email things that are, or
> ought to be, confidential.  Remember a few years ago when some
> European companies alleged that the US Government was passing
> sensitive business info picked off with Echelon to US companies,
> thus giving them an unfair competitive advantage?  Only the
> NSA knows for sure if that is true or not (I believe it's not),
> but nothing but ethics and the need to maintain secrecy around
> their capabilities would stop them from doing it.
>
> A greater risk is that of an unscrupulous admin on the path your
> mail takes,  who reroutes mail through one additional hop, scanning
> it for interesting files.  A still-greater risk is of someone
> cracking a company's mail server and remaining under the wire,
> sending copies of interesting mail to another host and selling
> valuable files or just exposing them for free.  This is an
> especially high risks in small to medium companies that have
> a mail server but don't have a regular sysadmin to keep it secure,
> up-to-date, and properly configured.  At such companies, your mail
> could be getting snooped for a very long period of time and no one
> would have any idea.
>
> How does a company protect itself against such a problem?
> PKI.  Let's say I have confidential business materials that I
> need to email to a client, business partner, my accountant, etc.
> I encrypt the file(s) with my recipient's public key, also encrypt the
> entire mail if necessary, and send it on its way.  Upon receipt,
> my recipient uses her private key plus her passphrase to decrypt
> the mail and the attached files.  In between, anyone who may have
> intercepted and copied the mail has nothing readable except
> the mail headers up to the point where it was intercepted.
>
> This sort of interception may or may not be a large problem (yet),
> quite probably it is not (yet).  However, probability of it happening
> is non-zero, and for anyone who does get burned that way, they
> probably look back and think that the time spent learning to
> use a PKI encryption program and use it faithfully would have been
> time very well spent.
>
> Finally, encryption enhances physical security at the workstation
> level.  It is not unusual for people to walk away from their
> workstations and leave the screen unlocked.  Also, the greatest
> common level of hardware-based security on a PC - needing a BIOS
> password to even boot - is usually easily circumvented by shorting
> the BIOS to factory defaults.  All you need is a little time.
> On PC hardware, physical access is everything.  One good way to
> get this physical access is for someone to just steal the whole
> machine.
>
> There are two cures for that: encrypt your sensitive files using
> PKI (and for extra security, don't keep your keyring on your
> computer; keep it on some removable storage such as a flash
> drive which you remove from the computer whenever you're not there),
> or encrypt your entire home directory (that's beyond the scope
> of this post, but the June, 2003 issue of SysAdmin and the August,
> 2003 issue of Linux Journal have articles on that.
>
> I guess I'll wrap this up here, and I hope I've piqued your
> curiosity enough to make you go read the GnuPG manual and
> subsequently install GPG and try it out.  Maybe we should have
> a keysigning at the next SDBUG meeting, too.  Since not everyone
> brings notebook machines to the event, I suggest keyslips[1] plus
> photo ID.
>
> [1]  A keyslip is a printout with your name, key ID, and key
>      fingerprint.  If you give me your keyslip and show me your
>      driver's license, passport, etc., I have confirmed your
>      identity and can, after I get home, download your public
>      key, verify the fingerprint, sign it, and submit it back to
>      the keyserver.  The more people who have signed your key,
>      the larger the web of trust for that key becomes.
>
> I hope this wasn't more than you really wanted to know :-)
> Jonathan
> --
> gpg --keyserver pgp.mit.edu --recv-keys ACC46EF9

Interesting theory there at the end.  I admit though, I do not have time to
read your whole write-up; I hope it is of benefit to other security newbies
on the SDBUG list or reading the archives.

Regarding the mkisofs/cdparanoia issue ~ it seems to me that there must be
a simple "dd" type of command to take an image of a CD.  Then couldn't
something like burncd be used -- regardless of whether the source CD was
"cdda" -- to clone the CD "disk image" to a CD-R?  I'm trying to stay away
from third-party or too many third-party solutions...  Thanks.

--
Peter Leftwich
President & Founder, Video2Video Services
Box 13692, La Jolla, CA, 92039 USA
http://Www.Video2Video.Com